Systemctl start transmission-daemon timeout

cbrace · December 13, 2024, 10:51am

Hi all,

I have a VPS that I use mainly for a private Nextcloud server. Earlier this week I upgraded it from v22.04 LTS to 24.04 LTS. Am happy to report the upgrade was pretty painless!

One minor issue: I can no longer use systemctl to start the transmission daemon:

$ sudo systemctl start transmission-daemon
Job for transmission-daemon.service failed because a timeout was exceeded.
See "systemctl status transmission-daemon.service" and "journalctl -xeu transmission-daemon.service" for details.

If I look for details, all I see is this:

$ sudo syssudo systemctl status transmission-daemon.service
× transmission-daemon.service - Transmission BitTorrent Daemon
     Loaded: loaded (/usr/lib/systemd/system/transmission-daemon.service; enabled; preset: enabled)
    Drop-In: /etc/systemd/system/transmission-daemon.service.d
             └─override.conf
     Active: failed (Result: timeout) since Fri 2024-12-13 11:44:50 CET; 7s ago
    Process: 59530 ExecStart=/usr/bin/transmission-daemon -f --log-level=error (code=exited, status=0/SUCCESS)
   Main PID: 59530 (code=exited, status=0/SUCCESS)
        CPU: 996ms

Dec 13 11:43:20 xxx.xx  systemd[1]: Starting transmission-daemon.service - Transmission BitTorrent Daemon...
Dec 13 11:44:50 xxx.xx  systemd[1]: transmission-daemon.service: start operation timed out. Terminating.
Dec 13 11:44:50 xxx.xx transmission-daemon[59530]: Closing transmission session... done.
Dec 13 11:44:50 xxx.xx systemd[1]: transmission-daemon.service: Failed with result 'timeout'.
Dec 13 11:44:50 xxx.xx systemd[1]: Failed to start transmission-daemon.service - Transmission BitTorrent Daemon.

If simply type

$ transmission-daemon &

It starts fine. I can easily manage this with a @reboot cronjob, no big deal. Just wondering though if anyone has any ideas why systemctl cannot start this daemon.

TIA

popey · December 13, 2024, 12:05pm

Hello Colin, and welcome!

Let’s get more detailed logs. Since transmission-daemon is set to log-level=error in the systemd service file, we should

Get transmission-daemon logs

Check the transmission-daemon specific logs:

tail -f /var/log/transmission/transmission.log   # If it exists

Get more verbose system logs:

journalctl -u transmission-daemon -n 100 --no-pager

Run the daemon in foreground mode with increased verbosity to see what’s happening:

sudo transmission-daemon -f --log-level=debug

There’s also something interesting in the status output - there’s a drop-in configuration file at /etc/systemd/system/transmission-daemon.service.d/override.conf. Maybe check what’s in this file as it might be causing the timeout:

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

The fact that it works when run directly but fails under systemd suggests there might be:

A permission issue (systemd runs it as a different user)
A path/environment issue
A dependency that’s not ready when systemd tries to start it
A configuration in the override.conf that’s causing problems

ahasenack · December 13, 2024, 1:50pm

Is there an apparmor DENIED message by any chance in the dmesg -T output? I’ve seen this before with services that were configured to use systemd notification to signal systemd when they were ready, but access to that socked was blocked by apparmor.

cbrace · December 13, 2024, 3:59pm

Thanks for the friendly welcome and the helpful ideas. The override, which I’d forgotten about, simply sets the daemon to run under my username so it can access files in my home dir:

[Service]
User=
User=colin
Group=
Group=colin

Will keep looking…

cbrace · December 13, 2024, 4:09pm

I don’t see a DENIED message, but I do see four instances of this line after trying to start the daemon using systemctl:

[Fri Dec 13 17:02:15 2024] audit: type=1400 audit(1734105740.293:2740): apparmor="ALLOWED" operation="sendmsg" class="file" info="Failed name lookup - disconnected path" error=-13 profile="transmission-daemon" name="run/systemd/notify" pid=64635 comm="transmission-da" requested_mask="w" denied_mask="w" fsuid=1000 ouid=0

This caught my eye because one hiccup I did encounter after the upgrade was that DNS lookup stopped working. After some investigation I ended up adding the IP address of DNS server of the hosting service to /etc/systemd/resolved.conf and restarting the resolved service. DNS lookups then worked again. Perhaps there is some vestigial issue?

ahasenack · December 13, 2024, 4:53pm

It does say ALLOWED, but I wonder if this specific error (disconnected path) is perhaps treated differently, even if the profile is in complain mode.

That being said, I can’t find an apparmor profile in the transmission-daemon package, do you know where it’s coming from? Does this return any results: grep transmission-daemon -r /etc/apparmor.d ?

UPDATE: found it, it’s in the apparmor package, in /etc/apparmor.d/transmission. I also reproduced the problem, and indeed it’s the disconnected path, even though the profile is in complain mode.

If you make this change, it should work:

--- /etc/apparmor.d/transmission.orig	2024-12-13 17:03:43.022484872 +0000
+++ /etc/apparmor.d/transmission	2024-12-13 17:03:48.479472153 +0000
@@ -5,7 +5,7 @@
 
 include <tunables/global>
 
-profile transmission-daemon /usr/bin/transmission-daemon flags=(complain) {
+profile transmission-daemon /usr/bin/transmission-daemon flags=(complain,attach_disconnected) {
   # Don't use abstractions/transmission-common here, as the
   # access needed is narrower than the user applications
   include <abstractions/base>

Please also file a bug here: https://bugs.launchpad.net/ubuntu/+source/transmission/+filebug

Feel free to link to this thread.

cbrace · December 13, 2024, 5:21pm

Thanks. I made that change, but still the timeout and the disconnected path error. Perhaps an additional setting somewhere in apparmor?

[Fri Dec 13 17:02:16 2024] audit: type=1400 audit(1734105741.293:2741): apparmor="ALLOWED" operation="sendmsg" class="file" info="Failed name lookup - disconnected path" error=-13 profile="transmission-daemon" name="run/systemd/notify" pid=64635 comm="transmission-da" requested_mask="w" denied_mask="w" fsuid=1000 ouid=0

ahasenack · December 13, 2024, 6:14pm

Oh, so sorry, I forgot to tell you to reload the profile:

sudo apparmor_parser -r -W -T /etc/apparmor.d/transmission

cbrace · December 13, 2024, 9:21pm

Bingo! Now working. Many thanks.

I would like to do my bit by opening a bug report as you suggest above. Can you suggest a suitable title for me? I don’t really know how to describe this fix.

ahasenack · December 17, 2024, 12:57pm

Something like:

transmission fails to start due to apparmor blocking systemd notification socket

cbrace · December 23, 2024, 7:02pm

Sorry to bother you with this again, but a quick question: I installed a new kernel and rebooted. Transmission wouldn’t start. So I re-ran the command below, and it worked as previously. Is there a way to make this change stick across reboots? Or should I simply run it every time at boot time?
TIA