So pretty much the popular kids (distros) are all using systemd. As a user who only started using linux two years ago, only familiar with systemd, and it's esay to administrate. I would like to know what could be the downside of switching OpenWrt's init system from SysVinit to systemd.
Well, to my knowledge the actual init / process manager in OpenWrt is procd, an OpenWrt specific tool...
Architecture in
2 Likes
Aside from OpenWrt not using sysvinit in the first place (as detailed by hnyman already), did you check the installed size of systemd and its dependencies - relative to the typical flash sizes supported by OpenWrt (8-16 MB spi-nor, but even 'high-end' modern routers with NAND rarely have more than ~20-64 MB usable)?
--
While I'd be very interested in looking at a proof-of-concept build with systemd, systemd-networkd and iwd myself, it just wouldn't really be reasonable for anything but x86_64 (and even there systemd-networkd[0] and iwd[1] tend to show their deficiencies in production). It would be really interesting to compare what works and what doesn't (maybe even as proof case for systemd upstream), how far the rabbit hole goes.
[0] upgrade systemd in place restarts systemd-networkd (and all active network connections), which in turn stalls the ssh session doing the upgrade. journal full, needs cycling, which in turn respawns systemd-networkd and -you guessed it- kills off all active network connections…
[1] it's by far not as battle proven as hostapd, so anything beyond the basics on well-behaving participants may- or might not work, toss a coin.
2 Likes
Thanks for the informative replies, now how do I delete this thread
Just mark one of the responses as solution, which will close the thread after ten days.
2 Likes
No, this is not true. I assume this is based on old/outdated bug reports. But as someone who runs his main gateway/firewall on Debian with systemd and systemd-networkd (and nftables), I can assure you that neither upgrading systemd nor restarting systemd-networkd interrupts my ssh sessions or network connections, at least on a somewhat recent system. In fact, I just did a full distro upgrade last week over SSH and even that didn't cause my SSH session to be interrupted or any other network disruption (I was prepared with a serial cable and backup, however, just in case, as Debian does not recommend distro upgrades over SSH).
Now, that doesn't mean that networkd doesn't have shortcomings. Just to give one example: While networkd allows to configure traffic shapers on interfaces, the options it offers are quite limited. It doesn't support all the options I use for my cake SQM setup (which isn't that special and quite close to the way cake get's set up on OpenWrt), so I still have to do that manually or outside of networkd. But overall, networkd does still offer me enough advantages that I prefer it over Debian's ifupdown, for example.
That being said, I don't think systemd would be a good match for a distribution such as OpenWrt that supports so many devices with very limited storage and memory.
Regarding iwd: I don't think it was designed to replace hostapd rather than wpasupplicant. The access point configuration is very limited and more targeted towards simple hotspot/tethering setups. To my knowledge, it can't do multiple SSIDs, for example. And you can't specify which authentication/encryption standard is used either (heck, the man page doesn't even tell you what is being used by default).
1 Like
It is based on personal experience, running Debian/unstable for (~25) years on dozens of systems and last observed as recently as less than two weeks ago with systemd v254-1 (upgrade) and ~6-8 weeks ago with the journal cycling (systemd v252). This is noticeable with long running servers, which are upgraded via ssh (but all other long running connections are lost at the same time as well, slow downloads, IRC clients, etc. pp.).
It doesn't always happen, but it happens very often - exactly at the time the systemd packages are upgraded, with the corresponding log entries. Again, I'm (intentionally) running unstable, on many systems, so I see very frequent upgrades - and while I like networkd (despite its lack of some features), this long standing issue is a major one.
Case in point:
[101905.186315] systemd[1]: systemd 254~rc3-3 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)
[...]
[449414.449024] systemd[1]: systemd 254-1 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)
[449414.449455] systemd[1]: Detected architecture x86-64.
[449415.473939] br-lan: port 2(tap-br-lan0) entered blocking state
[449415.473951] br-lan: port 2(tap-br-lan0) entered forwarding state
[449415.476950] br-lan: port 3(tap-br-lan1) entered blocking state
[449415.476961] br-lan: port 3(tap-br-lan1) entered forwarding state
[449415.486631] br-lan: port 4(tap-br-lan2) entered blocking state
[449415.486642] br-lan: port 4(tap-br-lan2) entered forwarding state
[449415.489534] br-lan: port 5(tap-br-lan3) entered blocking state
[449415.489544] br-lan: port 5(tap-br-lan3) entered forwarding state
[449415.492664] br-lan: port 6(tap-br-lan4) entered blocking state
[449415.492675] br-lan: port 6(tap-br-lan4) entered forwarding state
[449415.495097] br-lan: port 7(tap-br-lan5) entered blocking state
[449415.495107] br-lan: port 7(tap-br-lan5) entered forwarding state
[449415.497711] br-lan: port 8(tap-br-lan6) entered blocking state
[449415.497722] br-lan: port 8(tap-br-lan6) entered forwarding state
[449415.500477] br-lan: port 9(tap-br-lan7) entered blocking state
[449415.500487] br-lan: port 9(tap-br-lan7) entered forwarding state
[449415.617312] systemd-journald[299498]: Received SIGTERM from PID 1 (systemd).
[449415.617730] systemd[1]: Stopping systemd-journald.service - Journal Service...
[449415.662004] systemd[1]: systemd-journald.service: Deactivated successfully.
[449415.662588] systemd[1]: Stopped systemd-journald.service - Journal Service.
[449415.662765] systemd[1]: systemd-journald.service: Consumed 18.659s CPU time.
[449415.679839] systemd[1]: Starting systemd-journald.service - Journal Service...
[449415.716399] systemd-journald[1296689]: Collecting audit messages is disabled.
[449415.734769] systemd[1]: Starting systemd-hostnamed.service - Hostname Service...
[449415.736358] systemd[1]: Finished systemd-networkd-wait-online.service - Wait for Network to be Configured.
[449415.897892] systemd[1]: Started systemd-hostnamed.service - Hostname Service.
[449416.513550] br-lan: port 2(tap-br-lan0) entered disabled state
[449416.513853] br-lan: port 3(tap-br-lan1) entered disabled state
[449416.513991] br-lan: port 4(tap-br-lan2) entered disabled state
[449416.514108] br-lan: port 5(tap-br-lan3) entered disabled state
[449416.514234] br-lan: port 6(tap-br-lan4) entered disabled state
[449416.514349] br-lan: port 7(tap-br-lan5) entered disabled state
[449416.514461] br-lan: port 8(tap-br-lan6) entered disabled state
[449416.514574] br-lan: port 9(tap-br-lan7) entered disabled state
[449417.512970] systemd[1]: Started systemd-journald.service - Journal Service.
(and no, this is not specific to systems with complex networking setups, plain systems with a single wired NIC, no bridges, no tap interfaces, nothing special, are affected just alike).
1 Like
Huh, interesting. Is there a bug report somewhere for this? I'm still wondering whether this only happens under certain circumstances, since I haven't seen this on any of my Debian machines (and I just grepped through the logs of two machines to be sure) that all use networkd and also have mixed configurations (most are single interface, but there are also two machines with two interfaces, and my main gateway with a bunch of interfaces). Not even a manual restart of networkd would cause the interfaces to enter blocking state.
I also don't experience anything like that. I've been running a Debian based router since before Debian used systemd. I've upgraded systemd multiple times, it induces a short lag in the ssh session, then comes back. So if this happens to you it's probably something specific to the kinds of configs you have. I'm not saying it doesn't happen, just that it doesn't happen to me.
Given that my configurations span from extremely simple (single wired interface without anything special) to rather complex and cover a variety of vastly different systems, I do doubt that (and I have seen similar upstream bugs about it in the past, although I've lost hope for this getting fixed).
But lets not veer further beyond the topic.
Sorry I didn't RTFM and see /etc/init.d and automatically assume it was sysvinit 
My reputation is ruined and I'm gonna delete myself from the internet 
1 Like
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.