0

Hi I have an UDEV rule that calls a systemd Service that umounts my USB Drive when it is removed.

ACTION=="remove", KERNEL=="sd*" SUBSYSTEMS=="usb", SUBSYSTEM=="block", ATTRS{idVendor}=="XXXX", ATTRS{idProduct}=="XXXX", ENV{SYSTEMD_WANTS}="umount_extern_backup.service"

The problem is that the systemd service gets not executed if I physically unplug my USB Drive.

If I use the same UDEV rule

ACTION=="remove", KERNEL=="sd*" SUBSYSTEMS=="usb", SUBSYSTEM=="block", ATTRS{idVendor}=="XXXX", ATTRS{idProduct}=="XXXX", RUN+="/bin/umount -l /extern-backup"

to directly execute /bin/umount -l /extern-backup the command gets executed but I receive an error: udevd[10181]: Process '/bin/umount -l /extern-backup' failed with exit code 32. That is why I try to execute a systemd service because then the umount command works.

If I change the UDEV rule to execute a shell script it works:

ACTION=="remove", KERNEL=="sd*" SUBSYSTEMS=="usb", SUBSYSTEM=="block", ATTRS{idVendor}=="XXXX", ATTRS{idProduct}=="XXXX", RUN+="/usr/local/sbin/test.sh"

The test.sh gets executed. But I cannot directly use a shell script called by UDEV to execute the umount command because it gives me the same error as executing /bin/umount -l /extern-backup directly from UDEV.

If I call systemctl start umount_extern_backup.service manually the service also works.

To add the Icing on the cake if I replace ACTION=="remove" with ACTION=="add", for the UDEV rule then the systemd service gets executed and tries to umount when I connect my USB device.

Here is my systemd service:

[Unit]
Description=umount lazy /extern-backup service

[Service]
Type=oneshot
RemainAfterExit=no
ExecStart=/bin/umount -l /extern-backup

[Install]
WantedBy=multi-user.target
  • 1
    What happens when you configure your UDEV rule with RUN+="/usr/bin/systemctl umount_extern_backup.service" ? – Raman Sailopal Dec 14 '17 at 11:14
2

RUN+="/usr/bin/systemctl umount_extern_backup.service" as mentioned in a comment above works.

I checked SYSTEMD_WANTS device property here and they write:

Note that systemd will only act on Wants dependencies when a device first becomes active. It will not act on them if they are added to devices that are already active

This explains why the add rule triggered the systemd service and the remove rule not.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.