Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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?

share|improve this question

4 Answers 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.

share|improve this answer
    
Neither WantedBy nor RequiredBy affect ordering. –  Pavel Šimerda Apr 23 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 Apr 24 at 12:45

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
share|improve this answer
    
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 Apr 22 at 18:23
    
removed BindsTo –  edvinas.me Apr 22 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 Apr 22 at 18:25
1  
After=network.target is better than After=NetworkManager.service as it's more generic. –  Pavel Šimerda Apr 23 at 15:32
1  
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 Aug 12 at 7:19

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
share|improve this answer
    
I don't entirely like the Wants part because it has side effects on other packages. Look at my answer, please. –  Pavel Šimerda Apr 23 at 15:41
    
Just realized that Wants on network.target is a good idea here. –  Pavel Šimerda Apr 23 at 15:52

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. On current systems, NetworkManager.service, network.target and network-online.target by default only guarantee that NetworkManager has been started and it doesn't say anything about network configuration.

You need to enable NetworkManager-wait-online.service in order to make network.target and network-online.target wait for the first successful connection configured in NetworkManager. It's not perfect but it works, more or less.

For boot time ordering, I advise you to have the following in your unit:

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

You shouldn't need to add any Requires or Wants on NetworkManager-wait-online. Instead, the currently supported way is to just enable the wait online service:

systemctl enable NetworkManager-wait-online.service

A similar problem has been reported for the Fedora aiccu package:

I recently started a bugzilla ticket for NetworkManager upstream:

You may want to check whether netctl works the same way.

More resources:

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.