| 24 Jun 2021 |
|  U changed their display name from U Kuro to U. | 04:10:35 |
| U left the room. | 04:39:45 |
 kraftnix | So I never managed to solve the issue. However while browsing the systemd repo, I did find a newly merged dependency feature for units (actually 3 new ones) in this PR https://github.com/systemd/systemd/pull/19322
If I am not misunderstood from reading the man entry, I think Upholds or OnSuccess may be able to handle dependencies after boot / at runtime. So it may be relevant for the acme / unbound issue as well.
| 12:55:57 |
| kraftnix | although right now it seems that you can't specify the reverse dependency UpheldBy yourself ☹️ | 12:58:59 |
 gdamjan | kraftnix: you can always configure a sys-devices-virtual-net-wb\x2dabpmm.device.wants directory and a symlink to your nspawn service | 13:05:04 |
| kraftnix | so the ordering I need is sys-devices-virtual-net-wb\x2dabpmm.device must be active before the nspawn service trys to start. this works fine on reboot, but when I switch to a new configuration that adds network interfaces to the systemd nspawn service, the systemd nspawn service attempts to restart before the devices have been added, here is an example of the output from a deploy
⭐ ❓ [activate] [DEBUG] Running activation script
stopping the following units: systemd-networkd.service, systemd-networkd.socket
setting up /etc...
activating the configuration...
removing obsolete symlink ‘/etc/systemd/network/20-abpmm94c-tcon3.network’...
removing obsolete symlink ‘/etc/systemd/network/20-abpmm94h-tcon3.netdev’...
removing obsolete symlink ‘/etc/systemd/network/20-wb-abpmm94.netdev’...
removing obsolete symlink ‘/etc/systemd/network/20-wb-abpmm94.network’...
removing obsolete symlink ‘/etc/systemd/network/20-abpmm94h-tcon3.network’...
reloading user units for operator...
setting up tmpfiles
restarting the following units: systemd-nspawn@tcon3.service
Job for systemd-nspawn@tcon3.service failed because the control process exited with error code.
See "systemctl status systemd-nspawn@tcon3.service" and "journalctl -xe" for details.
starting the following units: systemd-networkd.socket, systemd-nspawn@tcon3.service, systemd-nspawn@tcon4.service, systemd-nspawn@tcon5.service, systemd-nspawn@test1con.service, systemd-nspawn@test2con.service
the following new units were started: sys-devices-virtual-net-abpmm94c\x2dtcon3.device, sys-devices-virtual-net-abpmm95h\x2dtcon3.device, sys-devices-virtual-net-wb\x2dabpmm95.device, sys-subsystem-net-devices-abpmm94c\x2dtcon3.device, sys-subsystem-net-devices-abpmm95h\x2dtcon3.device, sys-subsystem-net-devices-wb\x2dabpmm95.device, systemd-hostnamed.service
as you can see, the nspawn service systemd-nspawn@tcon3.service does a restart, even though it has a new interface (specified currently by requires and after).
it then fails (due to the interface not being up)
then systemd-networkd is started with the new interfaces + other services 😕
| 13:13:43 |
| kraftnix | * so the ordering I need is sys-devices-virtual-net-wb\x2dabpmm.device must be active before the nspawn service trys to start. this works fine on reboot, but when I switch to a new configuration that adds network interfaces to the systemd nspawn service, the systemd nspawn service attempts to restart before the devices have been added, here is an example of the output from a deploy
⭐ ❓ [activate] [DEBUG] Running activation script
stopping the following units: systemd-networkd.service, systemd-networkd.socket
setting up /etc...
activating the configuration...
removing obsolete symlink ‘/etc/systemd/network/20-abpmm94c-tcon3.network’...
removing obsolete symlink ‘/etc/systemd/network/20-abpmm94h-tcon3.netdev’...
removing obsolete symlink ‘/etc/systemd/network/20-wb-abpmm94.netdev’...
removing obsolete symlink ‘/etc/systemd/network/20-wb-abpmm94.network’...
removing obsolete symlink ‘/etc/systemd/network/20-abpmm94h-tcon3.network’...
reloading user units for operator...
setting up tmpfiles
restarting the following units: systemd-nspawn@tcon3.service
Job for systemd-nspawn@tcon3.service failed because the control process exited with error code.
See "systemctl status systemd-nspawn@tcon3.service" and "journalctl -xe" for details.
starting the following units: systemd-networkd.socket, systemd-nspawn@tcon3.service, systemd-nspawn@tcon4.service, systemd-nspawn@tcon5.service, systemd-nspawn@test1con.service, systemd-nspawn@test2con.service
the following new units were started: sys-devices-virtual-net-abpmm94c\x2dtcon3.device, sys-devices-virtual-net-abpmm95h\x2dtcon3.device, sys-devices-virtual-net-wb\x2dabpmm95.device, sys-subsystem-net-devices-abpmm94c\x2dtcon3.device, sys-subsystem-net-devices-abpmm95h\x2dtcon3.device, sys-subsystem-net-devices-wb\x2dabpmm95.device, systemd-hostnamed.service
as you can see, the nspawn service systemd-nspawn@tcon3.service does a restart, even though it has a new interface (specified currently by requires and after).
it then fails (due to the interface not being up)
then systemd-networkd is started with the new interfaces + other services 😕
Sorry for the bad naming, the only way to test this is to change the bridge/interface name everytime I try to test the dependency (otherwise the interface already exists)
| 13:15:01 |
 Arian | So an After=blah.device Requires=blah.device did not work? | 13:26:22 |
| Arian | I would expect in that case blah.device to be added to the transaction, and that should block until the udev event is fired | 13:26:45 |
| Arian | kraftnix: I thought systemd-nspawn creates the bridge interface itself so these things are never an issue. Are you managing it outside of nspawn? | 13:29:34 |
| kraftnix | In reply to @gdamjan:spodeli.org
kraftnix: you can always configure a sys-devices-virtual-net-wb\x2dabpmm.device.wants directory and a symlink to your nspawn service Yeah so setting the wants.target doesnt work | 13:41:19 |
| kraftnix | In reply to @arianvp:matrix.org
So an After=blah.device Requires=blah.device did not work? no :( | 13:41:24 |
| kraftnix | In reply to @arianvp:matrix.org
kraftnix: I thought systemd-nspawn creates the bridge interface itself so these things are never an issue. Are you managing it outside of nspawn? I am managing bridges outside of nspawn, as nspawn doesn't let you add more than 1 bridge | 13:41:50 |
| gdamjan | kraftnix: what is wants.target? | 13:41:53 |
| gdamjan | what did you do? | 13:42:03 |
| kraftnix | to be mroe specific systemd.targets."sys-subsystem-net-devices-${escapeSystemdPath "wb-newtest"}.device".wants = ["systemd-nspawn@tcon3.service"]; | 13:42:18 |
| gdamjan | well it's not a target | 13:42:48 |
| gdamjan | not sure if nix supports it | 13:43:31 |
| kraftnix | yeah I don't see options for systemd devices | 13:43:46 |
| gdamjan | write your own :) | 13:44:17 |
| gdamjan | basically you want a /etc/systemd/system/xyz-abc.device.wants/ directory, and a symlink to your service | 13:45:49 |
| gdamjan | or, the same can be done with a udev rule, and ENV{SYSTEMD_WANTS} | 13:46:08 |
| kraftnix | by symlink to my service do you mean the /etc/systemd/nspawn/tcon3.nspawn file? | 13:46:57 |
| gdamjan | no, systemd-nspawn@tcon3.service | 13:47:22 |
| gdamjan | well, that's the name of the symlink. the target is just systemd-nspawn@.service | 13:48:17 |
| kraftnix | i'm a bit confused on how to symlink directly to a service, do I create a symlink? or does the device.wants/ directory just need to have a file named after the service? | 13:50:33 |
| gdamjan | same as xyz.target.wants has | 13:50:56 |
| kraftnix | so something like systemd.services."sys-subsystem-net-devices-${escapeSystemdPath "bridge"}.device".wants = ["systemd-nspawn@tcon3.service"]; | 13:53:12 |
| kraftnix | * so something like systemd.services."sys-subsystem-net-devices-${escapeSystemdPath "bridge"}.device".wants = ["systemd-nspawn@tcon3.service"]; ? | 13:53:19 |
| gdamjan | kraftnix: well not sure if systemd.sercvices will do the right thing. | 13:54:11 |
