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
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 oftransmission.service
. – Andreas May 05 '18 at 13:18/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 May 06 '18 at 01:00.service
file to the question, for completeness. – Andreas May 06 '18 at 01:04systemctl 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" – Ingo May 06 '18 at 07:56systemctl enable transmission.service
, does it create a new symlink under a directorymedia-Elements.mount.wants/
? That's what should start this unit once the USB disk is mounted... Let us know whether that symlink is there... – filbranden May 06 '18 at 20:48etc/systemd/system
after running the command. – Andreas May 06 '18 at 22:07.mount
for any of my volumes anywhere, that I can find. Should there be? From docs: "Along with a unit file foo.service, the directory foo.service.wants/ may exist" -- not sure if it's required? From what I read on the subject some time ago I was under the impression that there were some transient objects created when mounting volumes that were not described in fstab. Or perhaps none at all. I'm not sure since I don't exactly know the systemd architecture by heart :) but back then the seemingly simple thing I wanted to do sounded much more complicated than expected. – Andreas May 06 '18 at 22:22[Install]
section doesn't seem to work in overrides file and thatRequiresMountsFor=
seems to work only for fstab mounts... So I updated the answer with manual symlinks (for the first part) and usingConditionPathIsMountPoint=
for the second part. I hope that works for you, please check it out! – filbranden May 09 '18 at 05:12.service
file? – Andreas May 09 '18 at 17:34/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 May 09 '18 at 18:43[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. – filbranden May 09 '18 at 18:44journalctl -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. – Andreas May 09 '18 at 22:10[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. https://lists.freedesktop.org/archives/systemd-devel/2018-May/040806.html – filbranden Jun 01 '18 at 16:51