[wibble10]

I tend to approach such tasks by just copying and editing a unit that shipped with the os (e.g sshd) — the example the post gives as being problematic is using some timer feature instead of cron and I suppose my question is really: who is doing that anyway?

I know you can rig up systemd to act like inetd or cron, but perhaps you would be better with an actual service (how hard is quartz?) than baking your jobs into systemd units..

That said, I only use Linux in prod for enterprise stuff that depends on it, everything else is on bsd so you can probably guess my opinion on systemd ;)

[Skunkleton]

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.

[oconnor663]

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."

[wibble10]

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.

[bashinator]

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.

[wibble10]

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 ;)

[bashinator]

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.

[pmoriarty]

I have to give a second endorsement to runit. I really wish more distros would use it.

[wibble10]

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...

[bashinator]

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.

[stefan_]

I'm sure it's a nice init program, and god knows sysvinit is garbage, but I'm much less clear why systemd needs to be my fucking DNS resolver, too.

[vetinari]

It doesn't. Systemd-resolverd is a separate application, completely optional and only Ubuntu uses it by default.

Not that it is bad, but you don't have to use it.

[Skunkleton]

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.

[jandrese]

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.

[pritambaral]

> ... 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.

[Skunkleton]

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.

[loudmax]

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.

[Twirrim]

Ubuntu 14 doesn't use systemd. It was the last LTS prior to the systemd switch.

[jandrese]

Ack, I misspoke. Ubuntu 16 was the one with the busted MAC randomization. It worked in 14, but was broken in 16 due to the SystemD deployment.

https://bugs.launchpad.net/ubuntu/+source/network-manager/+b...

[rob-olmos]

What was the solution for the SD card imaging?

[jandrese]

Download a bloated electron app to do the imaging, like you're on Windows.

https://www.balena.io/etcher/

[wibble10]

Eurgh. What have we done? :(

[1996]

Count me too. I love systemd and use it extensively to manage programs that can crash or randomly fail.

It can monitor many things including ram usage, and manages dependencies. Also it is everywhere by default - one less moving part I have to manage.

[thom]

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).

[kpU8efre7r]

I thought most people like systemd but those who do not are very loud.

[paulddraper]

The reason for using timers is that you can make them dependent on sockets, files, file systems, etc.

Love it or hate it, the whole idea of systemd is to centralize all task-ish management, whether one-offs, long-running, periodically-running, static resources, logs, etc.