Joachim Breitner's Homepage

The fact that hooks are missing from this design is scary and it spells the end of system administration as we know it. I have also been trying to find ways to do stuff on my system e.g. when I press certain keys or close the lid, and unless systemd provides the behaviour you want, you are out of luck.

And it confirms my theory: systemd sends Unix down the line of Windows: we know the best way to do things, and you don’t need any hooks.

It looks like networkd has no support for hooks. However, the systemd-networkd code contains some interesting comments:

   /* Always create the directories people can create inotify
     * watches in. */
    r = mkdir_safe_label("/run/systemd/netif", 0755, uid, gid);
    if (r < 0)
            log_error("Could not create runtime directory: %s",
                      strerror(-r));

    r = mkdir_safe_label("/run/systemd/netif/links", 0755, uid, gid);
    if (r < 0)
            log_error("Could not create runtime directory 'links': %s",
                      strerror(-r));

    r = mkdir_safe_label("/run/systemd/netif/leases", 0755, uid, gid);
    if (r < 0)
            log_error("Could not create runtime directory 'leases': %s",
                      strerror(-r));

In particular, there is /run/systemd/netif/state, which contains something like:

# This is private data. Do not parse.
 OPER_STATE=routable

Now, you can always ignore the warning about parsing and add a small hack by setting up an inotify watch (or a path-activated unit) and trigger actions whenever your network transitions to routable.

The intention is to expose the network state per link via the files in /run that you found. However, the official API will be a C library (sd-network), rather than the files themselves (which allows us some liberty in changing the implementation later on).

The library has not been exposed yet (still need to go through another round of review I think), but you can find the headers in src/systemd/sd-network.h if you want to have a look. It exposes change events (internally over inotify) and introspection of the files.

This is a very late comment, but /etc/resolv.conf was constantly misspelled in the blog post. But I guess that wasn’t part of the problem?

No, I do not think it was. But thanks for the notice, I fixed the blog post :-)

You can use your modem in combination with systemd-networkd like that:

# First, mask NetworkManager (if not done already)
systemctl mask NetworkManager

# Unmask, enable and start ModemManager
systemctl unmask ModemManager
systemctl enable ModemManager
systemctl start ModemManager

# Add a .network file for your modem network interface:
cat /etc/systemd/network/wwp0s20u6c2i12.network:

[Match]
Name=wwp0s20u6c2i12
[Network]
DHCP=both

# restart systemd-networkd:
systemctl restart systemd-networkd


# Scripts to enable and disable the modem and the corresponding network
# interface:

cat /usr/local/bin/modem-connect:

#!/bin/sh
mmcli -m 0 --simple-connect="apn=APN_HERE"
# also enter ,pin= if needed
ifconfig wwp0s20u6c2i12 up


cat /usr/local/bin/modem-disconnect:

#!/bin/sh
ifconfig wwp0s20u6c2i12 down
mmcli -m 0 --simple-disconnect

It would also make sense to adjust the RouteMetric parameter in the [DHCP] section of the .network file so that the modem connection is not used when other default routes are present. However, this didn’t work for me yet.

I was following that blog and discovered that wpa_supplicant service file is now present in Debian wpa_supplicant package (wpa_supplicant@.service). Maybe worth mentioning in the blog.