3 ms·
Networkd is fine if you don't need vlans, bonding, and a bunch of semi-esoteric stuff. /e/n/i does fine there. Journald is too monolithic IMO. Direct access to
by dmwilcox 2y ago
Networkd is fine if you don't need vlans, bonding, and a bunch of semi-esoteric stuff. /e/n/i does fine there.
Journald is too monolithic IMO. Direct access to the files in a text format is standard Unix stuff. Forcing everyone through the journalctl tool is rough, performance being just one issue. The binary format has a habit of changing too, having written a journald log tailer.
Overall, like I said, systemd is work software for me. It's fine for the complexity in a company (where you have to balance time and business value), but for my own use I wouldn't choose it.
Hence, please don't touch Alpine ;). I was on KISS previously but got tired of compiling my own packages (and Firefox is nigh impossible to compile in a 'ragged' version package system)
- 3np 2y ago> Networkd is fine if you don't need vlans, bonding, and a bunch of semi-esoteric stuff. networkd does support vlans, bonding, bridges, and whatnot since quite some time now. https://wiki.archlinux.org/title/VLAN#systemd-networkd https://wiki.archlinux.org/title/VLAN#systemd-networkd https://wiki.archlinux.org/title/Systemd-networkd#Bonding_a_wired_and_wireless_interface https://wiki.archlinux.org/title/Systemd-networkd#Bonding_a_... What more semi-esoteric stuff would you be missing? > Hence, please don't touch Alpine I'm with you here though: I too appreciate Alpine being on OpenRC rather than systemd. And hope a musl port does not change the calculation there. You may also appreciate https://chimera-linux.org/ https://chimera-linux.org/ if you haven't checked it out already.
- eep_social 2y agoI recently found that systemd-networkd isn’t generating “up” events (or something similar, not posting from work) for bonded interfaces set up by cloud init which causes the network wait job to spin until it times out, adding about 60s to boot time for any debian-based box we run in our medium sized deploy, so maybe a few 1000. I noticed because my dev box took forever to come back after a kernel update and I was sweating that I’d broken something. Unfortunately I was unable to allocate the time to figure out systemd at the layer where the event is expected but not generated to file a coherent bug. I ended up working around it several layers up by hard coding “bond0” as an argument in some config and moved on. I don’t think openrc is perfect and I find broken shit in Alpine constantly but when I do it’s a whole lot easier to figure out what broke when you don’t have to dig through several layers of dbus event generators and consumers before figuring out what even happened.
- 3np 2y agoI think I may be facing the exact same issue with bonded interfaces not being brought up properly (unrelated to cloud-init) and was hesitating if I should mention it as a caveat in the previous comment but maybe to your point I'm not 100% confident we're not missing anything in the configuration (: For now an `ip link set up` hook has been a passable workaround here.
- eep_social 2y agoYeah, the cloud init bit was from memory and might not even be right. What I found was that the dbus event doesn’t get generated for the bonded interface when it comes up. This person blogged a bit and the details and fix don’t match my situation but the broad strokes do: https://www.thomas-krenn.com/en/wiki/Job_systemd-networkd-wait-online.service_start_running https://www.thomas-krenn.com/en/wiki/Job_systemd-networkd-wa...
- egberts1 2y agoNetworks is also fine if you like your PID 1 opening a network socket ... every ... time.