Wait to start Transmission daemon until after USB drive has mounted?

Question

I'm running transmission-daemon as a systemd service on OSMC. When opening its remote control web interface after a reboot all transfers are almost always halted with the message "Error: No data found! Ensure your drives are connected [...]".

I'm assuming this is because Transmission starts before the download path exists -- in this case on an USB drive that gets automatically mounted by the system to /media/Elements/[...] without any manual configuration made from me. I have not edited fstab.

After trying this answer without success, I'm wondering if there's some other way to solve this? What I did according to that answer was to add the following in an override.conf:

cat /etc/systemd/system/transmission.service.d/override.conf

[Unit]
After=media-Elements.mount
After=media-Vault\x2013.mount
After=media-Black\x20Mesa.mount

The service file:

$ cat /lib/systemd/system/transmission.service

[Unit]
Description=Transmission BitTorrent Daemon
After=udisks-glue.service

[Service]
User=osmc
Group=osmc
Type=notify
ExecStartPre=/bin/sleep 10
ExecStart=/usr/bin/transmission-daemon -f --log-error --allowed *.*.*.*

[Install]
WantedBy=multi-user.target

Systemd status:

$ systemctl status transmission

● transmission.service - Transmission BitTorrent Daemon
   Loaded: loaded (/lib/systemd/system/transmission.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/transmission.service.d
           └─override.conf
[...]

Worth mentioning is that I get Warning: transmission.service changed on disk. Run 'systemctl daemon-reload' to reload units. when checking the status of transmission after every reboot. daemon-reload silences it until the next reboot.

This question is related, but has to do with fstab mounts. I would prefer to solve it without fstab if possible, since I don't want to treat the USB drive as permanently attached.

---

After trying the initial answer:

$ systemctl cat --no-pager transmission.service
# Warning: transmission.service changed on disk, the version systemd has loaded is outdated.
# This output shows the current version of the unit's original fragment and drop-in files.
# If fragments or drop-ins were added or removed, they are not properly reflected in this output.
# Run 'systemctl daemon-reload' to reload units.
# /lib/systemd/system/transmission.service
[Unit]
Description=Transmission BitTorrent Daemon
After=udisks-glue.service

[Service]
User=osmc
Group=osmc
Type=notify
ExecStartPre=/bin/sleep 10
ExecStart=/usr/bin/transmission-daemon -f --log-error --allowed *.*.*.*

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/transmission.service.d/override.conf

[Unit]
RequiresMountsFor=/media/Elements

[Install]
WantedBy=media-Elements.mount

Solution

EDIT: It turns out my first approach didn't work as expected. An [Install] section on an overrides file doesn't really work and RequiresMountsFor= seems to only work for mounts which are declared in fstab. Therefore, I'm proposing an alternative that will accomplish the same effects, but using different directives.

In order to prevent the unit from starting unless the /media/Elements volume is mounted, use the ConditionPathIsMountPoint= directive which will check that and prevent the unit from starting unless that directory is mounted.

# /etc/systemd/system/transmission.service.d/override.conf

[Unit]
ConditionPathIsMountPoint=/media/Elements

(NOTE: You can use the systemctl edit transmission.service command to open an editor on this overrides file.)

In order to trigger the start of transmission.service whenever the USB gets mounted, you need to add a symlink to it to a .wants/ directory for the mount unit. (Ideally, this would be taken care by an [Install] section, but it doesn't seem to work from an overrides file.)

Create it manually with these two commands:

$ sudo mkdir -p /etc/systemd/system/media-Elements.mount.wants/
$ sudo ln -sf /lib/systemd/system/transmission.service /etc/systemd/system/media-Elements.mount.wants/

After that's in place, mount /media/Elements and see Transmission get started...

---

Original answer below...

So, the After= directive only afects ordering, if both units are queued to be started, then this one will be started after the other one completes, but it doesn't trigger the start of the other one. You need Requires= for that.

But for mounts, there's a nice shortcut in RequiresMountsFor=, which can take the mounts as paths.

You also probably want to set this up so that this unit is started when the USB drive is mounted. You can trigger that by using WantedBy= (in the [Install] section) and referring to the .mount unit from here. After setting that up and using systemctl enable to create the "Wanted" relationship, the start of this unit will be (also) triggered when the USB drive is mounted (if that is done later and not during boot up.)

Putting it all together:

# /etc/systemd/system/transmission.service.d/override.conf

[Unit]
RequiresMountsFor=/media/Elements "/media/Vault 13" "/media/Black Mesa"

[Install]
WantedBy=media-Elements.mount
WantedBy=media-Vault\x2013.mount
WantedBy=media-Black\x20Mesa.mount

And then enable this unit, which will create symlinks under the *.mount.wants/ directories (the exact symlink names will be printed in systemctl enable output):

# systemctl enable transmission.service

This should take care of it.

It's unclear to me why you're listing the three mounts, since in the text of the question you suggest only /media/Elements is used to store Transmission downloads... If that's indeed the case, you could probably remove the other two and keep only the references to the "Elements" one.

(NOTE: I haven't tested this all before posting, but I'm fairly confident this will work. If for some reason it doesn't, leave me a comment with more details, I'm happy to work with you to figure this out.)

Comments

[Andreas]

Hey, thanks for the answer and the thorough explanation! I haven't had opportunity to test it yet but I can at least assure you that the Transmission service starts already, so if I understand correctly that means that the After directives I wrote just don't work. Or that my assumption is wrong of slow auto mount being the problem. I will try your solution and additionally post the contents of transmission.service.

[Andreas]

You're right about the two other mounts. I listed them only for the sake of being transparent with what I actually did. I simplified your example and used only /media/Elements, but unfortunately it did not make a difference -- the issue remains. I restarted transmission.service manually after boot and can once again confirm that the problem goes away by doing that, so it seems that I'm at least trying to solve the right problem.

[Andreas]

I added the contents of the .service file to the question, for completeness.

[Ingo]

@Andreas can you please look at the output from systemctl cat transmission.service? I'm interested if it is showing the runtime unit with drop-in. systemctl --help | grep "^ cat" says "cat PATTERN... Show files and drop-ins of one or more units"

[Andreas]

I added the output at the end of the Q. Unfortunately I was unable to format it in app.

[filbranden]

@Andreas When you run systemctl enable transmission.service, does it create a new symlink under a directory media-Elements.mount.wants/? That's what should start this unit once the USB disk is mounted... Let us know whether that symlink is there...

[Andreas]

I'm sorry, I'm not very systemd literate at the moment. Where should it appear? I see no such directory in etc/systemd/system after running the command.

[filbranden]

Hi @Andreas, I noticed some problems with my initial approach. I found that [Install] section doesn't seem to work in overrides file and that RequiresMountsFor= seems to work only for fstab mounts... So I updated the answer with manual symlinks (for the first part) and using ConditionPathIsMountPoint= for the second part. I hope that works for you, please check it out!

[Andreas]

Thanks for the update! I'll try it out tonight. Is there a particular reason you don't just ask me to edit the install section directly in the .service file?

[filbranden]

@Andreas the .service file is under /lib so I assume it's shipped by your distribution. Typically you don't want to edit it, since the distribution might overwrite your changes (for example, through a package update.)

[filbranden]

@Andreas I'll try to check whether [Install] doesn't work on overrides on latest systemd... If I can reproduce that, I'll post a bug report, since ideally this should work. But for now, the manual symlink isn't too painful way to work around it.

[Andreas]

I can confirm that it works now. Using journalctl -fu transmission.service I was able to see the service start after plugging in the USB cable. Really cool! I'll give your answer a few days to get some more upvotes before accepting it.

[filbranden]

@Andreas Awesome! I'm glad we figured it out! :-)

[Andreas]

Yes, thanks a lot for the help. I'm inspired to delve deeper with systemd after having solved this.

[Andreas]

Also, feel free to keep us posted on what you find out about install sections in override files. It sounds worth knowing.

[filbranden]

@Andreas The issue of [Install] sections in override files came up recently on the systemd mailing list. It seems there was a bug in systemd versions v236 through v238, but v235 works and a fix is already in, so when v239 is released it will contain the fix. lists.freedesktop.org/archives/systemd-devel/2018-May/…