1

I use a udev rule to recognize when a specific USB stick is plugged. When it's plugged in, a bash script is started which mounts some devices. That works very well after I did some changes to the systemd-udev service as described here.

However, one of the mounts fail. It is a fuse-mergerfs mount. The command itself seems to succeed, but when doing an ls on the mount folder I get a strange output and I cannot access the folder:

d?????????  ? ?    ?       ?            ? mountpoint

But if I run the mount command manually from the terminal everything is fine.

It also doesn't matter if the stick is plugged in during boot or if I plug it in after the system has already started. Mounting the fuse-mergerfs device does not work when mount is called by the udev script.

Do you have any ideas?

Biggie
  • 243

1 Answers1

2

[Using RUN in udev rules] is only suitable for short-lived scripts, as they will be killed if they are stil running after a timeout period.

I.e. the FUSE background process that implements your filesystem gets killed.

One alternative that comes to mind: if you have the systemd-mount command, you could try using that in place of your mount command. It will create a transient .mount unit (as opposed to a .service unit), and run the mount program inside that unit.

The source I am quoting tries to provide a more general solution for long-running processes:

https://yakking.branchable.com/posts/systemd-2-udevd/

If you need a longer-running service, then you should integrate it with a systemd unit, by defining the unit like:

cat >/etc/systemd/system/my-service@.service <<'EOF'
[Unit]
Description=My Service
[Service]
Type=simple
ExecStart=/path/to/your/script %I
EOF

And add ENV{SYSTEMD_WANTS}="my-service@%k.service" to the udev rule.

This will run /path/to/your/script and pass it the path to the device that has just appeared.

Unfortunately the above instructions are not correct for your case.

Your problem is not that your script itself took too long before returning. The problem is that your script returns after starting a "background process"; the process that implements your FUSE filesystem. When the script finishes, systemd thinks it needs to clean up, and kill all the left-over processes which were started by the script.

This case is very similar to a legacy sysvinit script. So we can use the same solution they do:

When you write a systemd service to mount a FUSE filesystem, do not use Type=simple or Type=oneshot. Use Type=forking instead.

sourcejedi
  • 50,249
  • It doesn't look like it's killed. E.g. if I add a sleep to the script, the PC hangs for that amount of time during boot. So, the timeout seems to be high enough.However, I tried it with a systemd service. It executes my script, too. And again, all mounts work, except for the fuse.mergerfs mount. This time, no weird "????" are shown, but the device is mounted neither. – Biggie Jan 29 '19 at 16:34
  • @Biggie regarding the second part only: only FUSE mounts require a long-running process. If none of the other mounts are FUSE mounts, that would explain the difference. – sourcejedi Jan 29 '19 at 16:44
  • I do not get any error message. The mount command succeeds with exit code 0 :) – Biggie Jan 29 '19 at 16:56
  • "I cannot access the folder". What error message do you get when you try to access the folder? – sourcejedi Jan 29 '19 at 16:57
  • It shows "Der Socket ist nicht verbunden". In english something like: "Socket ist not connected" or maybe "Transport endpoint" instead of socket ;) – Biggie Jan 29 '19 at 17:01
  • However, this happens only when using RUN. When using a systemd service I can enter the folder. It's empty. Running mount shows that nothing is mounted there – Biggie Jan 29 '19 at 17:02
  • Ahh :-). I believe that's the same error yes, although Google doesn't know much about it. It did find one likely example of the problem my current answer describes (ntfs-3g is implemented as a FUSE filesystem): https://bbs.archlinux.org/viewtopic.php?id=163175 Anyway, I'm trying to think about why your service doesn't do anything, but it is very mysterious :-). I take it the script works to mount the device when you run the script manually, and not from the systemd service. – sourcejedi Jan 29 '19 at 17:08
  • Yep, running the script manually works without any problems. – Biggie Jan 29 '19 at 17:20
  • You made my day :) It works! Thank you so much! Maybe add this to your answer-text above ;) – Biggie Jan 29 '19 at 17:43
  • Great :-). I've edited the answer to show the working solution. – sourcejedi Jan 29 '19 at 17:56