[Solved] SystemD, how to start a service after network is up.

TheSaint · 2013-07-13 01:50:42

Hello,
I'm recently involved to set up a daemon which should be ready after boot (aria2). Then it fails, as it fails minidlna as well.
The reason is that they try to come up but there's no host to talk to. See this page.
For my purposes, it should be good when the daemons find the necessary to stay alive (even they won't have a network fully ready, that may happen in less than a minute later). For minidlna is needed a valid IP which could be 127.0.0.1 or localhost, for aria2 it may be same or just looking for a RPC binding.
This what the logs are telling me.
I was trying to set more dependencies in the service, but even to set

After=wpa_supplicant.service

it doesn't have effect.
I don't find a solution, as far as my knowledge spans. Another chance would take to set a systemD timer and when that will be gone to start the daemon. Sorry but I don't know much about that.
Looking for someone here to guide to right direction.

TIA

Last edited by TheSaint (2013-07-15 03:12:37)

WonderWoofy · 2013-07-13 01:59:37

It depends on what network management utility you use and therefore also how you connect. If you are using an ethernet connection, you could just use dhcpcd@<interface>.service. This is a very simple service, and the network.target will not be reached until the IP address and connectivity is established.

If you are using wireless, the only two real solutions would be to use netctl@<profile>.service, which too won't reach the network.target until a conplete connection is made. The problem with the others (wicd, connman, even netctl-auto) is that they are meant to be dynamic, meaning that they don't always expect to have a network connection. So they report the network.target as being reached when the binary is simply launched. NetworkManager gets around this by implementing an additional service called (unimaginatively) NetworkManager-wait-online.service, which is pulled in automatically when you enable NetowrkManager.service.

You probably also want to use Requisite=aria2c.service on the minidnla.service as well. This too means that it will be started after aria2c, but that it will not start at all if it is not running or fails.

Additionally, you could try using the Requisite configuration on the minidnla, while setting the aria2c to restart itself on failure. So that it will keep trying, and once it does, then minidnla will start.

Of course, those last methods I have not actually tried because I do not use minidnla... or aria2c. Oh yeah, and this assumes that you are running aria2c as a systemd service as well.

Edit: Also, it is not SystemD. It is systemd (like other "daemon" binaries in *nix).

Last edited by WonderWoofy (2013-07-13 02:00:27)

ngoonee · 2013-07-13 05:10:33

Considered this issue as well but haven't got around to it. I guess if there's an 'After=network.target' but its not enabled then it wouldn't start, right?

WonderWoofy · 2013-07-13 05:34:38

The network.target gets pulled in by the network management utility. So it will typically reach the network.target after whatever you use has started. But in the case of wicd and netctl-auto (and connman) it is a dynamic connection, so it only reports the netowrk.target as being reached at the poitn at which the service starts, not when the network actually connects. The network.target isn't like multi-user.target or graphical.target which has to be enabled. It is more there to handle dependency resolution.

TheSaint · 2013-07-13 06:51:12

WonderWoofy wrote:

It depends on what network management utility you use and therefore also how you connect. If you are using an ethernet connection, you could just use dhcpcd@<interface>.service. This is a very simple service, and the network.target will not be reached until the IP address and connectivity is established.

Meanwhile some good suggestion (like yours) came up, I've tried a couple of recipes. But dhcpcd.service didn't get it right. Maybe dhcpcd@<interface>.service, would work, I'll see later.

I got this working:

[Unit]
Description=aria2 Service
Requires=network.target
After=dhcpcd.service

[Service]
Type=forking
User=aria2
Group=aria2
EnvironmentFile=/etc/conf.d/aria2.conf
WorkingDirectory=/var/aria2
ExecStart=/usr/bin/aria2c $ARIACMD
ExecReload=/usr/bin/kill -HUP $MAINPID
RestartSec=1min
Restart=on-failure

[Install]
WantedBy=multi-user.target

You may note the After=dhcpcd.service, but it doesn't work. I found RestartSec=1min ,Restart=on-failure more effective and perhaps less blocking to wait for the network to be ready. As a server this should be a small issue, very seldom compared with the running time. We (family members) can accept a little wait for the service to be on.
Exactly I don't know which of the two is the right solution, maybe the delay is the right one.
I was doing a cron scheduled job, before using systemd boot, which was kicking minidlna every 5 minutes, since it was dieing often. I didn't discover what was the reason.
I think I'll have to study another recipe which sets up a timer and keep an eye on these two services, for the long term service. But even cron would suffice, I think.

WonderWoofy wrote:

if you are using wireless, the only two real solutions would be to use netctl@<profile>.service, which too won't reach the network.target until a conplete connection is made

Yes I'm on wireless network and the interface plugged on USB . My intent should go beyond any particular configuration. Maybe because I'd like to show a working setup, which may fit for all configuration (90 % )
I have to admit that the actual solution do not care much whether the network is found, so I hope to get a smarter setup that counts on the necessary tools before try something. However it's proved that they fail when no connection to the router is done. But I'm preferring that they succeed.

WonderWoofy wrote:

NetworkManager gets around this by implementing an additional service called (unimaginatively) NetworkManager-wait-online.service, which is pulled in automatically when you enable NetowrkManager.service.

As I stated above I'm expecting a solution that won't pull in so much dependencies. Even NM is my connection manager, on the server.

WonderWoofy wrote:

You probably also want to use Requisite=aria2c.service on the minidlna.service as well. This too means that it will be started after aria2c, but that it will not start at all if it is not running or fails.
Additionally, you could try using the Requisite configuration on the minidnla, while setting the aria2c to restart itself on failure. So that it will keep trying, and once it does, then minidlna will start.

looks like a dog biting the tail . It's much preferable a separated failure, just in case.

WonderWoofy wrote:

Edit: Also, it is not SystemD. It is systemd (like other "daemon" binaries in *nix).

I'm quite sure I saw it somewhere, none of my inventions

Last edited by TheSaint (2013-07-13 07:10:33)

TheSaint · 2013-07-15 03:10:50

Final
I've found a mere solution than re-kick the daemons 1 or 2 minutes later. More details here. A light and unsure solution.
Different solution should add some signal in /etc/tmpfiles/ or looking for /run/dhcpcd.pid in order to guarantee a successful connection with the outside world.
EVEN dhcpcd.service doesn't ensure that connection is established, therefore a different approach should need a ping to the network, only then the service may be started. This is for whom usen't Network Manager.

Last edited by TheSaint (2013-07-15 03:23:02)

Arch Linux

#1 2013-07-13 01:50:42

[Solved] SystemD, how to start a service after network is up.

#2 2013-07-13 01:59:37

Re: [Solved] SystemD, how to start a service after network is up.

#3 2013-07-13 05:10:33

Re: [Solved] SystemD, how to start a service after network is up.

#4 2013-07-13 05:34:38

Re: [Solved] SystemD, how to start a service after network is up.

#5 2013-07-13 06:51:12

Re: [Solved] SystemD, how to start a service after network is up.

#6 2013-07-15 03:10:50

Re: [Solved] SystemD, how to start a service after network is up.

Board footer