Anyone Familiar with UDEV rules?

mediamogul

I'm trying to write a udev rule that will launch a script every time my controller is plugged in, but it's not working. Can anyone perhaps spot what I'm doing wrong here?

ACTION=="add", ENV{ID_FOR_SEAT}=="input-platform-3f980000_usb-usb-0_1_2_1_0", ENV{ID_MODEL}=="Logitech_RumblePad_2_USB", RUN+="sudo /home/pi/RetroPie/retropiemenu/main_joystick_mode.sh"

bazmonkey

Perhaps try removing the ID_FOR_SEAT bit... but I don't know if/why you need that.

I'd issue a "udevadm control --log-priority=info" so that your syslog gets udev event logging (if it isn't already), and plug/un-plug your controller. Scrutinize the log and ensure that during add events, ID_FOR_SEAT and ID_MODEL are included and correct.

mediamogul

@bazmonkey

The ID_FOR_SEATshould specify the USB port. Ideally I need this as I'm trying to delineate two identical controllers by the port they're plugged into. I had already enabled udevadm control --log-priority=info and was reading the output as you posted. It reads:

Aug 15 21:17:48 retropie systemd-udevd[1472]: failed to execute '/lib/udev/sudo' 'sudo /bin/bash /home/pi/RetroPie/retropiemenu/main_joystick_mode.sh': No such file or directory

This is my first attempt at launching a script this way, but it looks like the problem is with '/lib/udev/sudo' right?. Do I even seed to specify sudo in the command?

bazmonkey

@mediamogul Yeah, you don't need sudo. I believe the no-such-file bit, though, is because $PATH isn't set. Inside the bash script it's ok, because that triggers a bashrc, but I think you need /usr/bin/sudo (it should work, even if it's redundant) instead.

It's a good sign that it's recognizing and happening!

mediamogul

@bazmonkey

Well, udev is now loading at startup without any errors but the intended script function still isn't happening, so I guess the problem is now in the script somewhere. It's been a long day, so I'm going to chalk this up as a win for now. You were a big help and I really appreciate it. I'll report back as I proceed so as not to leave this undocumented for anyone else this might help in the future. With that in mind and assuming the udev rule is now functional, it currently reads as:

ACTION=="add", ENV{ID_FOR_SEAT}=="input-platform-3f980000_usb-usb-0_1_2_1_0", ENV{ID_MODEL}=="Logitech_RumblePad_2_USB", RUN+="/usr/bin/sudo /home/pi/RetroPie/retropiemenu/main_joystick_mode.sh"

bazmonkey

@mediamogul can we see the script? What are you trying to do?

mediamogul

@bazmonkey

I'm at a loss. I've tested the script that the udev rule will launch and it runs fine on it's own. Also, because udev is no longer throwing up an error that it can't launch anything, I am left with a squeaky clean system log that doesn't tell me anything about why it's not working. Is there any other way to troubleshoot a problem like this?

Edit:

can we see the script? What are you trying to do?

Sure, the script is as afollows:

#!/bin/sh

sudo /opt/retropie/supplementary/xboxdrv/bin/xboxdrv \
	--evdev /dev/input/by-path/platform-3f980000.usb-usb-0:1.2:1.0-event-joystick \
	--detach-kernel-driver \
	--force-feedback \
	--dpad-as-button \
	--trigger-as-button \
	--deadzone-trigger 15% \
	--deadzone 4000 \
	--device-name "Logitech Rumblepad 2 (xboxdrv)" \
	--silent \
	--axismap -Y1=Y1,-Y2=Y2 \
	--evdev-absmap ABS_X=x1,ABS_Y=y1,ABS_Z=x2,ABS_RZ=y2,ABS_HAT0X=dpad_x,ABS_HAT0Y=dpad_y \
	--evdev-keymap BTN_THUMB2=a,BTN_THUMB=b,BTN_TOP=x,BTN_TRIGGER=y,BTN_BASE3=back,BTN_BASE4=start,BTN_TOP2=lb,BTN_PINKIE=rb,BTN_BASE5=tl,BTN_BASE6=tr,BTN_BASE=lt,BTN_BASE2=rt \
	--ui-axismap lt+x1=REL_X:10,lt+y1=REL_Y:10 \
	--ui-buttonmap guide=void,lt+lb=BTN_LEFT,lt+rb=BTN_RIGHT \
	&

mediamogul

@bazmonkey

The idea is of course that when the RumblePad is plugged in, the script will launch and map the controller. If I can ever get it to work, I will also have an almost identical script that breaks xboxdrv down when the controller is removed.

mediamogul

I can't even get it to launch simple scripts or executables. If I intentionally get the path the wrong to the script or executable, I get a systemd-udevd[1472]: failed to execute... No such file or directory warning during startup every time. I guess that means the rule is working and the item is trying to launch, but when the path is correct, nothing launches and I can't seem to track down an error explaining why.

PaulCheffus

@mediamogul

Hi

What happens if you remove the --silent line from the script? This is usually used to prevent messages being displayed so could be suppressing your error(s).

Cheers

Paul

gizmo98

I had problems with raspbian jessie, udev rules and scripts. It seems file system is not ready when the udev rule is triggered. The only way to solve this problem was to run this script with a daemon, rc.local or bashrc.

If you add your device at runtime the script runs because file system is ready.

mediamogul

@PaulCheffus

That particular instance silences xboxdrv while it's running and unfortunately it never actually gets that far. I might still give it a try to see if it manages to briefly launch and sputter something out.

@gizmo98

I was afraid it might be something like that. I half-way ruled it out because I was under the impression that I could at least plug my controller in after the system fully boots and see results. Shouldn't the rule operate at that point?

gizmo98

After the system is started the rule should work.

mediamogul

@gizmo98

That's what everyone seems to think. I've tried reformatting the rule a hundred different ways and I can't get it to launch anything at any time under any circumstances. Perhaps this function is simply broken on Raspbian.

mediamogul

@gizmo98

OK, despite numerous current postings to the contrary on this subject, the udevRUN+="/path/to/executable" function has been deprecated at some point in favor of other, more reliable methods.

http://blog.fraggod.net/2012/06/16/proper-ish-way-to-start-long-running-systemd-service-on-udev-event-device-hotplug.html

http://blog.fraggod.net/2015/01/12/starting-systemd-service-instance-for-device-from-udev.html

Both techniques make use of a daemon as you mentioned, but they can still be controlled with a modified udev rule that will launch the daemon when a specified device is added or removed. They require a little more work, but hopefully at least one of them will bear fruit.