I'm one of the (rare?) people who actually likes systemd. On Arch Linux, it is uniformly applied to the whole system and is actually a nice experience IMO. This contrasts with other distros that use a hodgepodge of sysv-init, upstart, and others. Even still, I think that systemd has discoverability and verbosity issues that should be addressed.
Not rare. The majority of Linux distros have switched to systemd because the majority of people who work with it like it better than what they were using before. It's just that no one ever made it to the front page of HN writing a blog post titled "This technology is generally decent."
I dunno about that, the majority of ops guys I work with (or have worked with over the last few years) dislike it... we’re mostly angry old greybeards though.
Greybeard here - I like systemd well enough. It's not perfect, but it's a lot better than rando SYSV init scripts. Journald and journalctl are loads better than /var/log.
Have you used openbsd for anything lately? Systemd is better than the horrible mess of upstart/sysv etc, although the one linux laptop I run is using void (and thus, runit) and you can type init 6 and it doesn’t randomly hang for 2 minutes while shutting down if you’re not using gnome/kde.. imagine! The future is here ;)
It's been a number of years - doesn't openbsd use just plain /etc/rc and /etc/rc.conf? I like that better than init.d just because it enforces some standards around the scripting at least.
I admin a number of ubuntu servers running systemd, and they all shut down/reboot pretty much instantaneously.
Why are they loads better btw? I think in composable commands, being able to cat my logs without first setting them up to pipe to a syslog is something I very much want...
Being able to view logs based on the name of the service instead of the name of the logfile. `journalctl -u <unit>` vs `less /var/log/service/something.log`
Being able to specify date ranges instead of grepping around multiple files. `journalctl -u <unit> -s <start> -e <end>` instead of horrid combinations of grep and gzcat.
"Okay," you say, "but that's all for logs on the host. Shouldn't you be using Splunk or an ELK stack?"
Journalctl can export logs in a json format that can be natively consumed by splunk for free metadata markup. I wrote some container sidecars to do exactly that, and it worked great.
The only thing I don't like about journalctl is that it doesn't line wrap by default.
It doesn't need one, but systemd-resolved works quite well and integrates nicely with other services. Systemd-resolved isn't mandatory, and you can still just use /etc/resolv.conf pointed to an external DNS server.
I spent the time to learn it and yeah, it's pretty nice when it's working.
The problem is of course when you need to do something that isn't supported by SystemD, in which case you're in for a world of hurt as the system constantly fights you.
For example, I had a requirement to make sure some machines randomized their MAC addresses when connecting to untrusted WiFi in Ubuntu 14. Turns out this functionality was broken in NetworkManager and trying to go around its back was a huge huge headache because the system was relentless in checking the MAC of the interface and setting it back to the physical one.
There are other times where it bites you in the ass too, like writing a raw image to a SD card. In the old days you would just dd the image onto the card, but you can't do that anymore because shortly after you write the filesystem header to the card SystemD will notice the new filesystem attempt to mount it, killing off your dd process.
I always try to work with SystemD now because it's so much harder to fight it.
> ... because shortly after you write the filesystem header to the card SystemD will notice the new filesystem attempt to mount it, killing off your dd process.
Could you elaborate on this? I develop an embedded OS which regularly flashes itself while running systemd (we support two methods: 1. write partition table to disk, write fs header to partitions, explicitly mount fs and write file content to fs; and 2. dd pre-built image) and I have never seen this happen. We have also flashed (via dd) our images onto cards from within Ubuntu 16.04 and 18.04 and never seen this.
Are you talking about systemd-networkd or Network Manager? Those are separate projects, and I agree that Network Manager is garbage. Still, you don't have to take systemd wholesale. You can still use ifupdown if that is your jam.
In your specific case, if you were using systemd-networkd you could specify MACAddressPolicy=random in your link file to achieve what you wanted.
To be fair, you can run systemd without NetworkManager or an automounter. For network access, you can run dhcpcd with systemd (on Arch anyway). I've never wanted an automounter on any system.
Likewise, systemd doesn't prevent you from running ALSA instead of PulseAudio. The flexibility is there. Better documentation/best practices would be helpful.
Same for me, in fact Arch was the impetus for me to actually dig into all the things systemd could do (which I guess is the point of Arch). That said, I have had the exact issues linked in the article, staring in puzzlement that there's no simple way to ship errors from systemd via email. I actually really love journalctl but there's a big market for more tooling around it (it also annoys me that I can't remap log levels of different units, for example).
