| 6 Jun 2023 |
 oddlama | So if I understand correctly having e.g. sshd.service enabled would suffice because it has After=network.target, and network.target in turn has After=network-pre.target | 13:46:54 |
 ElvishJerricco | No. You're missing Wants=network-pre.target | 13:47:27 |
| ElvishJerricco | After != Wants | 13:47:34 |
| oddlama | Ah my bad, damn terminology | 13:47:55 |
| ElvishJerricco | After and Before just creating runtime ordering requirements in the event that both units are in the transaction. Wants, Requires, and BindsTo cause units to be pulled into the transaction | 13:48:20 |
| ElvishJerricco | * After and Before just create runtime ordering requirements in the event that both units are in the transaction. Wants, Requires, and BindsTo cause units to be pulled into the transaction | 13:48:28 |
| oddlama | True, I remember now. So the issue could be that nothing wants network-pre which means network is never started? | 13:49:04 |
| ElvishJerricco | No | 13:49:11 |
| oddlama | Im so lost 😂 sorry | 13:49:29 |
| ElvishJerricco | You only need to want network.target to start the network, and that is pulled in by multi-user.target | 13:49:35 |
| ElvishJerricco | network-pre.target is an optional target in case you need to create a unit that runs before networking is started | 13:50:05 |
| ElvishJerricco | But you have to pull it in with Wants to have that work | 13:50:16 |
| oddlama | Ahh. Since I just blindly copied the check-flush service from the existing test, why would wanting network-pre not apply to the existing test case? | 13:51:35 |
| ElvishJerricco | That probably is a mistake in the existing code :P Until I looked into this yesterday, I assumed network-pre.target was wanted by multi-user.target or network.target or something like that, but that appears not to be the case | 13:53:06 |
| oddlama | Okay that's fair. I just assumed it was something specific to my test that would require that. | 13:53:33 |
| ElvishJerricco | It's listed as a "passive" unit in man systemd.special, which I'm pretty sure means it's expected to be wanted explicitly by anything that needs it | 13:54:25 |
| oddlama | Okay the first noticeable difference between the two systems is in systemctl status systemd-networkd.socket.
broken system:
● systemd-networkd.socket - Network Service Netlink Socket
Loaded: loaded (/etc/systemd/system/systemd-networkd.socket; enabled; preset: enabled)
Drop-In: /nix/store/8wz1d5jpc0wnjlvl2fy6ap7cdfd8s5d8-system-units/systemd-networkd.socket.d
└─overrides.conf
Active: active (listening) since Tue 2023-06-06 15:53:04 CEST; 28min ago
Triggers: ● systemd-networkd.service
Docs: man:systemd-networkd.service(8)
man:rtnetlink(7)
Listen: route 1361 (Netlink)
CGroup: /system.slice/systemd-networkd.socket
Jun 06 15:53:04 sentinel systemd[1]: systemd-networkd.socket: Installed new job systemd-networkd.socket/start as 274
working system:
● systemd-networkd.socket - Network Service Netlink Socket
Loaded: loaded (/etc/systemd/system/systemd-networkd.socket; enabled; preset: enabled)
Drop-In: /nix/store/vmjrc7h55f6vvms0xa91bb0v5skc8yfp-system-units/systemd-networkd.socket.d
└─overrides.conf
Active: active (running) since Tue 2023-06-06 16:11:42 CEST; 8min ago
Triggers: ● systemd-networkd.service
Docs: man:systemd-networkd.service(8)
man:rtnetlink(7)
Listen: route 1361 (Netlink)
CGroup: /system.slice/systemd-networkd.socket
Jun 06 16:11:42 ward systemd[1]: systemd-networkd.socket: Installed new job systemd-networkd.socket/start as 287
Jun 06 16:11:44 ward systemd[1]: systemd-networkd.socket: Incoming traffic
Jun 06 16:11:44 ward systemd[1]: systemd-networkd.socket: Changed listening -> running
| 14:25:35 |
| oddlama | This is also pretty much the last thing related to networkd printed in the debug logs on the non-functioning system. The working system starts networkd afterwards so there's of course more. | 14:27:13 |
| ElvishJerricco | I don't even remember what exactly systemd-networkd.socket is for... | 14:28:04 |
| ElvishJerricco | like normally, when someone tries to read or write a systemd socket, the corresponding service is started | 14:29:00 |
| ElvishJerricco | but like shouldn't systemd-networkd be actively started? Rather than in response to something else opening the socket? | 14:29:20 |
| oddlama | That's what I would have thought too | 14:29:52 |
| oddlama | But on the working system it is definitely the socket service which starts networkd | 14:30:08 |
| oddlama | Which could be wrong and just lead to a working system by accident | 14:30:28 |
| ElvishJerricco | I wonder what creates the incoming traffic | 14:30:28 |
| oddlama | Probably mdns | 14:30:33 |
| oddlama | The working server is in my home network | 14:30:46 |
| oddlama | The non working one is a hetzner server with a public ipv4 and no other machines on the network | 14:31:04 |
| ElvishJerricco | Hm, something tells me that the reference to man:rtnetlink(7) in the docs section of that unit is relevant | 14:32:43 |
| ElvishJerricco | hmm: ListenNetlink=route 1361 | 14:36:25 |
