Opened 9 years ago

Closed 7 years ago

Last modified 7 years ago

#5421 closed Bug (fixed)

Transmission systemd service should start only network in initialized

Reported by: anatolik Owned by:
Priority: Normal Milestone: None Set
Component: Daemon Version: 2.81
Severity: Normal Keywords: systemd network.target
Cc: anatol.pomozov@…

Description

Hi,

This is a followup for Linux Arch bug https://bugs.archlinux.org/task/31478

systemd file should contain:

[Unit]
After=network.target

So when we enabled the service then it starts only after the network is initialized. Otherwise transmission web UI won't start.

Change History (12)

comment:1 Changed 9 years ago by jordan

  • Component changed from Transmission to Daemon
  • Milestone changed from None Set to 2.81
  • Resolution set to fixed
  • Status changed from new to closed

Added in r14122.

Though I should point out, the people who drafted the .service file in 2.80 felt that "After=network.target" wasn't necessary (see bug #4503 comments 4 and 5). So if you could confirm that this resolves the problem on Arch, I'd appreciate it...

comment:2 Changed 9 years ago by anatolik

Comment 4 from that ticket says:

and there is no point in waiting for network.target because the daemon works just fine even if the network isn't up yet.

And it is not true. At least for Web UI. Web interface requires network up otherwise it does not start.

comment:3 Changed 9 years ago by mus

I was the one who said not to add network.target. I admit I was wrong there, I was probably just lucky on my system because the network is up very early.

Anyway, adding After=network.target is strictly speaking not the proper fix. The transmission-daemon simply shouldn't expect the network to be up when it starts and set up the web interface port either way (it does open the port for bittorrent either way, so I don't see why it can't set up the web interface port as well. Although I admit that my understanding of setting up network ports from a programmer's point of view is limited).

Even if you add After=network.target you can't be sure that the network is actually up at this point. For example NetworkManager?.service pulls in network.target way before the connection is actually up. This is because, for example, it can't be sure whether there actually will be a connection (no W-LAN available etc.). Modern daemons are expected to deal with the fact that the state of the network can change at any time.

This may be nitpicky and probably wouldn't affect many people, but I just wanted to point it out.

comment:4 Changed 9 years ago by anatolik

I am neither systemd guru, but adding After=network.target solves the problem for me.

And here is the journald log in case if transmissions starts before the network:

Jul 19 20:38:56 arch transmission-daemon[199]: sendto: Network is unreachable
Jul 19 20:38:56 arch transmission-daemon[199]: [20:38:49.073] UDP Failed to set receive buffer: requested 4194304, got 425984 (tr-udp.c:78)
Jul 19 20:38:56 arch transmission-daemon[199]: [20:38:49.073] UDP Failed to set send buffer: requested 1048576, got 425984 (tr-udp.c:89)
Jul 19 20:38:56 arch network[200]: Starting network profile 'ethernet'...
Jul 19 20:39:03 arch network[200]: Started network profile 'ethernet'
Jul 19 20:39:03 arch systemd[1]: Reached target Network.

You can simulate the same situation by bringing network down and then starting transmission-daemon.

comment:5 Changed 8 years ago by SplitFire

  • Keywords network.target added
  • Milestone changed from 2.81 to None Set
  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Version changed from 2.80 to 2.81

"After=network.target" BREAKS my installation! That i have:

  1. Transmission daemon shutdowns VERY long. Actually, systemd stopping it by time out.
  2. After full cleaning (/var/lib/transmission/.config/transmission-daemon), daemon doesn't start at all.

Removing "After=network.target" solves my issue.

Archlinux i686 (fully updated).

comment:6 Changed 8 years ago by anatolik

Please provide more information. Why exactly transmission is stuck? Logs/stacktraces are welcome.

comment:7 Changed 8 years ago by SplitFire

Ok, I updated my Arch (systemd 208). Also I deleted /var/lib/transmission folder.

Now I start transmission.service and get transmission.service - Transmission BitTorrent? Daemon

Loaded: loaded (/usr/lib/systemd/system/transmission.service; disabled) Active: failed (Result: core-dump) since Р’СЃ 2013-10-06 14:40:50 NOVT; 1s ago

Process: 928 ExecStart?=/usr/bin/transmission-daemon -f --log-error (code=dumped, signal=SEGV)

Main PID: 928 (code=dumped, signal=SEGV)

РѕРєС‚ 06 14:40:50 systemd[1]: transmission.service: main process exited, code=dumped, status=11/SEGV РѕРєС‚ 06 14:40:50 systemd[1]: Failed to start Transmission BitTorrent? Daemon. РѕРєС‚ 06 14:40:50 systemd[1]: Unit transmission.service entered failed state.

What information you are interesting in?

comment:8 Changed 8 years ago by SplitFire

I have made some tests and results are:

  1. When I started transmission for the first time, it fails. Because it cannot create transmission dir and place pid file.
  2. After creating transmission dir with transmission:transmission access restrictions, transmission starts and finishes incredibly fast.
  3. But when I restart my PC, I cannot login through web ui, but transmission is working. After "systemctl restart transmission.service" everything works fine.

comment:9 Changed 8 years ago by anatolik

  • Resolution set to fixed
  • Status changed from reopened to closed

But when I restart my PC, I cannot login through web ui, but transmission is working.

More information? Logs? Ypu cannot login or webui does not start at all? If WebUI does not start at all then it sounds like the issue this ticket tries to solve. Add

[Unit]
After=network.target

back.

Based on information you provided you have completely screwed transmission installation that does not allow to start and stop it. I would suggest to do clean reinstall of the package.

Transmission daemon shutdowns VERY long. Actually, systemd stopping it by time out.

That is not systemd fault. Please figure out what is wrong with your transmission installation. It seems the problem not the systemd config but something else that prevents shutdown.

comment:10 Changed 7 years ago by starquake

  • Resolution fixed deleted
  • Status changed from closed to reopened

I'm sorry to have to reopen this ticket but I have the exact same problem (described in the initial report) and would like to help. I run ArchLinux?. I have had this problem on multiple installations. I first thought it was related to the download directory being on a USB disk. This is not the case anymore. My unit file contains After=network.target. This is what's in the logs:

Sep 22 22:29:34 mediamonkey transmission-daemon[5201]: Closing transmission session... done. -- Reboot -- Sep 22 22:30:30 mediamonkey transmission-daemon[1942]: sendto: Network is unreachable

Torrents seem to be working. It looks like only the Web UI isn't working.

If I do a systemctl restart transmission everthing works as expected.

Transmission is set up to run as a different user. My settings.json says "rpc-bind-address": "0.0.0.0"

My machine gets it ip address with DHCP.

Any ideas where to look for any solutions? Can I provide more logs?

comment:11 Changed 7 years ago by starquake

  • Resolution set to fixed
  • Status changed from reopened to closed

This fixed it for me: sudo systemctl dhcpcd@…

Instead of enabling dhcpd for all devices.

Got the solution from https://wiki.archlinux.org/index.php/Transmission#Autostart_at_boot

comment:12 Changed 7 years ago by anatolik

If you have issues with systemd service please do not reopen this ticket. Use transmissionbt forum instead (Arch forum might be useful as well). Thanks.

Note: See TracTickets for help on using tickets.