149

I am relatively new to systemd and am learning its architecture.

Right now, I'm trying to figure out how to cause a custom shell script to run. This script needs to run after the networking layer has started up.

I'm running Arch, using systemd as well as netctl.

To test, I wrote a simple script that simply executes ip addr list > /tmp/ip.txt. I created the following service file for this script.

(/etc/systemd/system/test.service)
[Unit]
Description=test service

[Service]
ExecStart=/root/test.script

[Install]
WantedBy=multi-user.target

I then enabled the script with,

systemctl enable test

Upon restarting, the script does indeed run, but it runs prior to the network being started. In other words, the output in ip.txt displays no IPv4 address assigned to the primary interface. By the time I login, the IPv4 address has indeed been assigned and networking is up.

I'm guessing I could alter the point at which the script runs by messing with the WantedBy parameter, but I'm not sure how to do that.

Could someone point me in the right direction?

Improve this question
2
  • You can also use networkd-dispatcher
    – Tek
    Commented Mar 11, 2020 at 10:07
  • Is /etc/systemd/system/test.service the filename, or part of the file?
    – ctrl-alt-delor
    Commented Mar 9, 2022 at 9:57

7 Answers 7

Reset to default
191

On systemd network configuration dependencies

It is very easy to affect systemd's unit ordering. On the other hand you need to be careful about what a completed unit guarantees.

Configure your service

On current systems, ordering after network.target just guarantees that the network service has been started, not that there's some actual configuration. You need to order after network-online.target and pull it in to achieve that.

[Unit]
Wants=network-online.target
After=network-online.target

For compatibility with older systems, you may need to order after network.target as well.

[Unit]
Wants=network-online.target
After=network.target network-online.target

That's for the unit file of your service and for systemd.

Implementation in current versions of software

Now you need to make sure that network-online.target works as expected (or that you at least can use network.target).

The current version of NetworkManager offers the NetworkManager-wait-online.service which gets pulled in by network-online.target and thus by your service. This special service ensures that your service will wait until all connections configured to be started automatically succeed, fail, or time out.

The current version of systemd-networkd blocks your service until all devices are configured as requested. It is easier in that it currently only supports configurations that are applied at boot time (more specifically the startup time of `systemd-networkd.service).

For the sake of completeness, the /etc/init.d/network service in Fedora, as interpreted by the current versions of systemd, blocks network.target and thus indirectly blocks network-online.target and your service. It's an example of a script based implementation.

If your implementation, whether daemon based or script based, behaves as one of the network management services above, it will delay the start of your service until network configuration is either successfully completed, failed for a good reason, or timed out after a reasonable time frame to complete.

You may want to check whether netctl works the same way and that information would be a valuable addition to this answer.

Implementations in older versions of software

I don't think you will see a sufficiently old version of systemd where this wouldn't work well. But you can check that at least network-online.target exists and that it gets ordered after network.target.

Previously NetworkManager only guaranteed that at least one connection would get applied. And even for that to work, you would have to enable the NetworkManager-wait-online.service explicitly. This has been long fixed in Fedora but was only recently applied upstream.

systemctl enable NetworkManager-wait-online.service

Notes on network.target and network-online.target implementations

You shouldn't ever need to make your software depend on NetworkManager.service or NetworkManager-wait-online.service nor any other specific services. Instead, all network management services should order themselves before network.target and optionally network-online.target.

A simple script based network management service should finish network configuration before exiting and should order itself before network.target and thus indirectly before network-online.target.

[Unit]
Before=network.target

[Service]
Type=oneshot
ExecStart=...
RemainAfterExit=yes

A daemon based network management service should also order itself before network.target even though it's not very useful.

[Unit]
Before=network.target

[Service]
Type=simple
ExecStart=...

A service that waits for the daemon to finish should order itself after the specific service and before network-online.target. It should use Requisite on the daemon service so that it fails immediately if the respective network management service isn't being used.

[Unit]
Requisite=...
After=...
Before=network-online.target

[Service]
Type=oneshot
ExecStart=...
RemainAfterExit=yes

The package should install a symlink to the waiting service in the wants directory for network-online.target so that it gets pulled in by services that want to wait for configured network.

ln -s /usr/lib/systemd/system/... /usr/lib/systemd/system/network-online.target.wants/

Related documentation

Final notes

I hope I not only helped to answer your question at the time you asked it, but also contributed to improving the situation in upstream and Linux distributions, so that I can now give a better answer than was possible at the time of writing the original one.

Improve this answer
10
  • Do you mean the autoconnect option by "wait until all connections configured to be started automatically succeed"? Can I leverage this when I set no-auto-default=* but I have autoconnect=yes on one of my connections? And last question - I don't understand --wait-for-startup option of the nm-online and manual page does not help much. Thanks for this writeup, highly appreciated!
    – lzap
    Commented Nov 11, 2015 at 12:33
  • As far as I know, nm-online doesn't care about no-auto-default, only auto. Do you have any specific question? In my opinion the nm-online manpage states clearly that with -s it waits for all auto connections to be attempted, i.e. connected or failed.
    – Pavel Šimerda
    Commented Nov 11, 2015 at 14:39
  • After messing with this crap for an hour, I found the solution: apt-get install sysv-init. :-) The complexity systemd adds as a replacement for a few shell scripts is mind boggling.
    – Mantriur
    Commented Mar 6, 2016 at 22:17
  • @Someone I'm afraid that initscripts are not an answer in this case. If you're using NetworkManager or any other dynamic configuration tool, initscripts can't order themselves after a fully configured network. You can get a limited dynamic configuration using /etc/init.d/network or similar but that doesn't work universally.
    – Pavel Šimerda
    Commented Mar 23, 2016 at 21:30
  • @Pavel Šimerda Init executes serially, and a proper init script will not return until it has finished doing what subsequent scripts need to rely on. For networking that would mean having all applicable adapters up and ready. Unless it was just lucky timing, NM behaves well within that context. The real problem of course is NM reinventing network handling instead of building on existing simple and tried and tested structures. Desktop people seem to have no concept of the dangers of complexity. ;-)
    – Mantriur
    Commented Mar 24, 2016 at 15:21
10

If your service provides a server, which can wait passively for someone to connect to it, use this:

[Unit]
After=network.target

Your service should bind on the wildcard interface. If it uses socket activation (recommended), or if it is local-only, you can ignore network targets entirely.

If your service acts as a client, or is peer to peer, this is more appropriate:

[Unit]
After=network-online.target
Requires=network-online.target

Prior to systemd 213, network-online.target needs the workaround Pavel mentioned (you need to manually enable a service that will wait for the network to be up). As of systemd 213 this is done by default. systemd-networkd-wait-online will wait for at least one address (either routable or link-local) to be configured on a non-loopback interface.

Configuring systemd-networkd, NetworkManager or equivalent is an independent task. DHCP (for IPv4) and NDP (for IPv6) tend to work out of the box, but you should configure them so that your precise definition of “the network is up” is what triggers network-online.target.

Documentation:

Improve this answer
3
  • Just curious why a new answer and not just small improvements to the existing and (hopefully) well structured answer.
    – Pavel Šimerda
    Commented Dec 26, 2014 at 22:33
  • The first two Documentation links are currently defunct.
    – Peter Hansen
    Commented Mar 2, 2015 at 22:55
  • 2
    Why use Requires instead of Want?
    – Karl Morrison
    Commented Aug 9, 2017 at 10:58
9

You can use After in [Unit] section to define a service that should be started before your service starts. For example if you are using NetworkManager, you can make your service start after NetworkManager is started.

[Unit]
Description=test service
After=NetworkManager.service
Improve this answer
5
  • BindsTo is not so appropriate here since the service is a one-off event and not a persistent service (unless it also includes an ExecStop feature to fire when networking goes down).
    – goldilocks
    Commented Apr 22, 2014 at 18:23
  • removed BindsTo
    – ek9
    Commented Apr 22, 2014 at 18:24
  • You could add something to replace BindsTo, though, e.g., Requires, if you only want the service to run if NetworkManager does. After doesn't actually do that -- it just means if NM is also running, then run this afterward. If NM isn't going to be run, the service will be run at an arbitrary point.
    – goldilocks
    Commented Apr 22, 2014 at 18:25
  • 4
    After=network.target is better than After=NetworkManager.service as it's more generic.
    – Pavel Šimerda
    Commented Apr 23, 2014 at 15:32
  • 8
    Notice that specifying After=foo will not cause the foo unit to start if it is not already started, it will only tell systemd how to order the units if they are both started at the same time. Using both After=foo as well as Wants=foo or Requires=foo will have the effect of pulling in foo if it's not started, and also making systemd order the units correctly.
    – Emil Lundberg
    Commented Aug 12, 2014 at 7:19
4

I'm guessing I could alter the point at which the script runs by messing with the WantedBy parameter

That will have the opposite effect of what you want. From man systemd.unit:

WantedBy=, RequiredBy=

[...] A symbolic link is created in the .wants/ or .requires/ directory of each of the listed units when this unit is installed by systemctl enable. This has the effect that a dependency of type Wants= or Requires= is added from the listed unit to the current unit.

Based on this, we can see the proper unit option is "Wants" or "Requires"; based on the description of those, "Requires" is probably correct, with the addition of "After" to ensure not only that the networking service be run, but that it run before this unit.

None of the unit options, AFAIK, can include the stipulation that a started perquisite must have completed, or reached a certain point (networking is probably a daemon service), only that it start first. With this in mind, you may want to make your script Type=forking and throw in a healthy delay (say 30 seconds), or some kind of an exit-on-success loop including a delay, to make sure that you have a DHCP lease first.

Improve this answer
3
  • 1
    Neither WantedBy nor RequiredBy affect ordering.
    – Pavel Šimerda
    Commented Apr 23, 2014 at 15:31
  • 1
    @PavelŠimerda : Nobody here claimed they did. Ordering is why I explicitly mentioned After in conjunction with Requires "to ensure not only that the networking service be run, but that it run before this unit".
    – goldilocks
    Commented Apr 24, 2014 at 12:45
  • 1
    Yes, After works together with Wants or Requires that way. On the other hand explicit delays are a bad habit in dependency based tools, especially when there is an explicit way to wait until network is configured specified by systemd documentation, so I have to insist on the downvote.
    – Pavel Šimerda
    Commented Dec 16, 2014 at 12:07
3

Use After in the [Unit] section to specify what should be started before your own service. (This much of the previous answer is correct.)

To start your service after the network is up, use the network target, which should apply whether you use NetworkManager, the conf.d/netctl system in Arch, or some other service that systemd is aware of.

[Unit]
#.....
After=network.target

A brief look will confirm that every other service on your system that relies on network connectivity contains this directive.

It is also portable to any distribution which uses systemd. Your unit file will be the same for Arch, Fedora, RHEL 7, future versions of Debian...

Services which start a network connection, such as Arch's scripts or your own, should specify so in their own unit files.

[Unit]
Wants=network.target
Before=network.target
Improve this answer
3
  • I don't entirely like the Wants part because it has side effects on other packages. Look at my answer, please.
    – Pavel Šimerda
    Commented Apr 23, 2014 at 15:41
  • Just realized that Wants on network.target is a good idea here.
    – Pavel Šimerda
    Commented Apr 23, 2014 at 15:52
  • you really want to use network-online.target. ref
    – Alex Jones
    Commented Oct 31, 2015 at 15:31
1

I wanted to add a point to this article. Currently (summer 2015) in RHEL7/CentOS 7, network-online.target is incorrectly set before IPv6 networking is up, so daemons that have

Wants=network-online.target
After=network-online.target

in their service definition that also explicitly bind to IPv6 addresses will probably be started before IPv6 is up and running, causing them to fail.

Improve this answer
1
  • I guess this is the case only with kernel based IPv6 automatic configuration which is flawed anyway. If you want to properly order after IPv6, you should definitely use NetworkManager instead of /etc/init.d/network. If you get the same issue even with NM, then it would be a good reason to file a feature request. I haven't checked with RHEL/CentOS, I can help you with the details if you're interested.
    – Pavel Šimerda
    Commented Apr 18, 2016 at 18:21
0 
[Unit]
After=systemd-networkd.service

works for me.

Improve this answer
1
  • Not sure if it works in some special cases but it is wrong for a couple of reasons. One of them is that networkd provides its own /wait-online/ service. Pulling in and ordering after network-online.target is the right way to go with any service that supports that.
    – Pavel Šimerda
    Commented Apr 18, 2016 at 18:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .