[SOLVED]udev rules are not working

lucifier13 · 2021-05-20 12:37:17

I have stated a rule in /etc/udev/rules.d, named 33-penconnect.rules

SUBSYSTEMS=="usb", DRIVERS=="usb", ATTRS{idProduct}=="1643", ATTRS{idVendor}=="0951", RUN+="/pen.sh"

and when running attribute-walk

udevadm info --attribute-walk --name=/dev/sdb

 looking at parent device '/devices/pci0000:00/0000:00:14.0/usb1':
    KERNELS=="usb1"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"[/b]
    ATTRS{idProduct}=="1643"
    ATTRS{idVendor}=="0951"

than i ran

udevadm control --reload
udevadm trigger

my /pen.sh looks like this:

#!/bin/bash
notify-send "This seems to work"

but it is not sending any notification, i don't know what is happening
i tried to test it and found that this rule is actually read by the udevadm. Is this has something to do with the current user. or i am doing something else wrong

Last edited by lucifier13 (2021-05-21 09:38:35)

V1del · 2021-05-20 13:09:28

udev rules do not run in your user context. That notify-send will just go into nothingness, even if the rule is interpreted and ran.

You'll need to set the DBUS_SESSION_BUS_ADDRESS to the active one of your current user at the very least. To find out what the relevant variables are you can hijack a process you know is available and started in your user's session context, see this script for how this could be done: https://gist.github.com/AladW/de1c5676d93d05a5a0e1

lucifier13 · 2021-05-20 13:41:06

V1del wrote:

udev rules do not run in your user context. That notify-send will just go into nothingness, even if the rule is interpreted and ran.
You'll need to set the DBUS_SESSION_BUS_ADDRESS to the active one of your current user at the very least. To find out what the relevant variables are you can hijack a process you know is available and started in your user's session context, see this script for how this could be done: https://gist.github.com/AladW/de1c5676d93d05a5a0e1

Can you please elaborate as i don't know much of this stuff. I am still on my learning path

seth · 2021-05-20 14:12:39

notify-send uses dbus to talk to whatever your notification daemon is.
Since the dbus context of your session doesn't exist in the context of udev, the signal is going nowhere.
You need to either export the proper dbus environment (and switch the user) or, if you just want to log the event like eg.

echo "This seems to work" >> /tmp/penconnect.test

lucifier13 · 2021-05-20 14:15:18

i checked the systemlog and there it is visible that script just ran:

May 20 19:40:59 archlinux systemd-udevd[181569]: 1:0:0:0: Running command "/pen.sh"
May 20 19:40:59 archlinux systemd-udevd[181569]: 1:0:0:0: Starting '/pen.sh'
May 20 19:40:59 archlinux systemd-udevd[181569]: Successfully forked off '(spawn)' as PID 181633.
May 20 19:40:59 archlinux systemd-udevd[181569]: 1:0:0:0: Process '/pen.sh' succeeded.

but it didin't showed anything. I tried using echo to append to a file but that too didn't worked. I was expecting that to work after reading the sys log

seth · 2021-05-20 14:20:48

"didn't work" is not a usable problem description.

Please post

stat /pen.sh
cat /pen.sh

lucifier13 · 2021-05-20 14:25:19

seth wrote:

"didn't work" is not a usable problem description.
Please post
stat /pen.sh
cat /pen.sh

sorry. i meant there was no file created
This is my modified rule

SUBSYSTEMS=="usb",DRIVERS=="usb",ATTRS{idProduct}=="1643",ATTRS{idVendor}=="0951",RUN+="echo Worked >> /tmp/connected"

but when i connected my drive after reloading the rules and checked tmp dir there was no file by name connected

seth · 2021-05-20 14:28:19

Put "echo "This seems to work" >> /tmp/penconnect.test" into /pen.sh and run that.
You can't just use random bash syntax in a udev rule.

lucifier13 · 2021-05-20 14:31:26

seth wrote:

"didn't work" is not a usable problem description.
Please post
stat /pen.sh
cat /pen.sh

stat /pen.sh
File: /pen.sh
  Size: 138             Blocks: 8          IO Block: 4096   regular file
Device: 10302h/66306d   Inode: 1303        Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2021-05-20 19:20:04.265241593 +0530
Modify: 2021-05-20 19:19:59.141908174 +0530
Change: 2021-05-20 19:19:59.141908174 +0530
 Birth: 2021-05-20 19:19:59.141908174 +0530

cat /pen.sh
#!/bin/bash
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus"
DISPLAY=":0"
notify-send "This seems to work"

lucifier13 · 2021-05-20 14:38:20

seth wrote:

Put "echo "This seems to work" >> /tmp/penconnect.test" into /pen.sh and run that.
You can't just use random bash syntax in a udev rule.

Yes thanks it did worked but how can i make notify-send work with udev.
I treid adding DBUS path, display number and user in my pen.sh. What i am missing here

seth · 2021-05-20 14:38:53

As for your altered pen.sh: you still want to "export" those variables and most likely will have to switch the UID as well (su/sudo)

lucifier13 · 2021-05-20 15:01:16

Sorry for the delay, but i didn't understand your mean by switching UID. If it means to run as root user with sudo, than it is not working there is no error in syslog or in terminal after running the command. Sorry for acting dumb

seth · 2021-05-20 15:39:01

udev runs as root, but you want to run notify send as your user.
Try

sudo -u lucifier13 env DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" DISPLAY=":0" notify-send "This seems to work"

Obviously use the username for the user you're running on your system.

lucifier13 · 2021-05-20 16:13:15

The script is working fine, but with udev it is not showing any notification and in syslog it is showing process failed with exit code 1

seth · 2021-05-20 19:26:55

Please post the updated script and the output of

loginctl session-status

lucifier13 · 2021-05-21 03:37:31

seth wrote:

Please post the updated script and the output of
loginctl session-status

it didn't worked with sudo but by using su it worked pretty fine

su username -c "notify-send \"New device connected\""

There are few things i want to understand now:

Previously my notify-send was sending notifications to my root user when user was not defined in my command?
Should a normal notify-send will work if i login as a root user?
BTW Thanks for your help.

V1del · 2021-05-21 06:31:31

sudo doesn't keep the environment so your exports will have disappeared if you didn't define them like seth's example.

udev does not run in your session context, you'd still need to import/export the variables but yes you could run notify send without the user switch, but don't even think about logging into a graphical session as root. There's a lot that can go wrong and a lot of GUI software has active measures to prevent running as root due to the security risks that would entail.

If this is [SOLVED] please mark it as such by editing the title in your first post

Last edited by V1del (2021-05-21 06:35:02)

lucifier13 · 2021-05-21 08:40:01

V1del wrote:

sudo doesn't keep the environment so your exports will have disappeared if you didn't define them like seth's example.
udev does not run in your session context, you'd still need to import/export the variables but yes you could run notify send without the user switch, but don't even think about logging into a graphical session as root. There's a lot that can go wrong and a lot of GUI software has active measures to prevent running as root due to the security risks that would entail.
If this is [SOLVED] please mark it as such by editing the title in your first post

so if i run sudo -i cmd how will that affect, I am not sure but i have heard that sudo -i can be used if you need env variables

and 1 more thing i want to ask is that how could i play a sound using udev, i am trying it similarly as i was doing notify-send

su username -c "/usr/bin/aplay $HOME/scripts/sounds/iphone_notification.wav"

I have my root user in audio group which i don't think has any affects. But when i am running this in a script i have been warned by system that pulseaudio session is only started for myuser not for root user, but in the end it is playing sound.
does it has something to do with pulse audio or i have to export another variable for audio

V1del · 2021-05-21 08:59:13

That would invoke a login shell, which will parse the variables of the respective login user, but which also wouldn't really help you in this case since DBUS_SESSION_BUS_ADDRESS is not defined directly in your .profile files.

If you just want to keep them as exported in the script you'd use sudo -E

Pulseaudio needs many of the same variables, potentially XDG_RUNTIME_DIR as well (... which will be /run/user/1000 in your case) and to play to the pulseaudio of your user you'd probably want to use

su username -c "/usr/bin/paplay $HOME/scripts/sounds/iphone_notification.wav"

lucifier13 · 2021-05-21 09:03:10

OHH replacing $HOME with full path worked here for sound.
and sudo -i is also working with commands which requires env variables without defining it in command itself
and maybe there were some typos i made in command which seth suggest. sorry for that. But finally it is working fine
Thanks a lot everyone for helping me and giving your precious time to my problem

lucifier13 · 2021-05-21 09:04:02

V1del wrote:

That would invoke a login shell, which will parse the variables of the respective login user, but which also wouldn't really help you in this case since DBUS_SESSION_BUS_ADDRESS is not defined directly in your .profile files.
If you just want to keep them as exported in the script you'd use sudo -E
Pulseaudio needs many of the same variables, potentially XDG_RUNTIME_DIR as well (... which will be /run/user/1000 in your case) and to play to the pulseaudio of your user you'd probably want to use
su username -c "/usr/bin/paplay $HOME/scripts/sounds/iphone_notification.wav"

I will try that too. Thanks ones again
I wasn't aware of paplay i thought that is a different package but i came to know many new things in this thread

Last edited by lucifier13 (2021-05-21 09:06:57)

lucifier13 · 2021-05-21 09:15:46

final thing sometimes udev rules are resetting my touchpad settings, which i searched for and found that sometimes udev reset (i don't remember precisely) x11 settings. Is there a solution for that instead of running my configuration script for touchpad with udevscripts

seth · 2021-05-21 11:19:37

Please open a new thread, specify which "touchpad settings" and how you configure them.
Also which "udev rules"
But if you configure them w/ xorg.conf.d configlets, random "udev rules" should™ not reset them because even if the device is re-added, X11 will pick it up and apply the present configuration.

But again: new thread, please.

Arch Linux

#1 2021-05-20 12:37:17

[SOLVED]udev rules are not working

#2 2021-05-20 13:09:28

Re: [SOLVED]udev rules are not working

#3 2021-05-20 13:41:06

Re: [SOLVED]udev rules are not working

#4 2021-05-20 14:12:39

Re: [SOLVED]udev rules are not working

#5 2021-05-20 14:15:18

Re: [SOLVED]udev rules are not working

#6 2021-05-20 14:20:48

Re: [SOLVED]udev rules are not working

#7 2021-05-20 14:25:19

Re: [SOLVED]udev rules are not working

#8 2021-05-20 14:28:19

Re: [SOLVED]udev rules are not working

#9 2021-05-20 14:31:26

Re: [SOLVED]udev rules are not working

#10 2021-05-20 14:38:20

Re: [SOLVED]udev rules are not working

#11 2021-05-20 14:38:53

Re: [SOLVED]udev rules are not working

#12 2021-05-20 15:01:16

Re: [SOLVED]udev rules are not working

#13 2021-05-20 15:39:01

Re: [SOLVED]udev rules are not working

#14 2021-05-20 16:13:15

Re: [SOLVED]udev rules are not working

#15 2021-05-20 19:26:55

Re: [SOLVED]udev rules are not working

#16 2021-05-21 03:37:31

Re: [SOLVED]udev rules are not working

#17 2021-05-21 06:31:31

Re: [SOLVED]udev rules are not working

#18 2021-05-21 08:40:01

Re: [SOLVED]udev rules are not working

#19 2021-05-21 08:59:13

Re: [SOLVED]udev rules are not working

#20 2021-05-21 09:03:10

Re: [SOLVED]udev rules are not working

#21 2021-05-21 09:04:02

Re: [SOLVED]udev rules are not working

#22 2021-05-21 09:15:46

Re: [SOLVED]udev rules are not working

#23 2021-05-21 11:19:37

Re: [SOLVED]udev rules are not working

Board footer