Hacker News Reader

Comment by Karunamon | Hacker News Reader

In all honesty I've never yet administered a system where the addition of systemd solved a problem I actually had. I would gladly go back to Upstart (or hell, even sysv) in a heartbeat.

Put another way, as a couple of anecdotes at $day_job, the boot time benefits (the one thing people always seem to bring up in defense of this ever-growing behemoth) were eaten up months ago in time troubleshooting, transitioning, and working around its corner cases.

More humorously, the words "fucking" and "goddamn" used to be followed by the name of some internal program known for being clunky. After getting up to Ubuntu 16 and Cent 7 in the whole environment, those words tend to be followed by "systemd".

View on HN

Counter-anecdote - since switching to operating systems using systemd, I haven’t had a single bug or issue with the init system or writing startup scripts, because finally they use incredibly obvious files that I can write myself.

For me it’s basically magic that I can now write a simple declarative file that describes how to run an application, and from there it works with all of the expected features.

Systemd didn't introduce this, though; many alternative init systems already had declarative configurations.

Yes. However, systemd did this part certainly right --- the service files and their dependencies are much easier to understand compared to e.g. its counterpart in upstart.

I have found that systemd solves many problems. I couldn't care less about boot times, especially on servers. The service startup with dependencies is very nice and easy compared to sysv. You write like 10 lines and it just works. You get status output of the service without having to grep through the log file. Sometimes you don't need a logfile, which makes this even better, as you don't need to use screen/tmux workarounds. You see if a service is running or has exited.

Same for timers. Debugging not running cronjobs is a pain in comparison.

Writing sysv init scripts is so fucking shit, people started to dump everything in /etc/rc.local, especially for earlier RPi versions of Debian.

I used to make sailors blush with the intensity of expletives about various sysvinit scripts.

Do you know about Kafka, Spark, and Jenkins? They're all Java but they each have their batshit fucking insane quirks on starting up.

One of them runs in foreground. One of them runs in background.

Jenkins (actually as Hudson) had it's own fucking Unix daemon-isation inbuilt. For a Java program!

Nuts!

Thankfully pretty much popular Java server has a systemd unit file written for it which avoids any shell and Exec's Java directly.

I can't fathom why it's so popular for Java programs to ship a slew of poorly-tested shell scripts that read environment variables and config files, and transform these into -D arguments to the java command. Why on earth don't they just o that with Java!?

Enjoy the House of Horror.

* http://jdebp.info./FGA/systemd-house-of-horror/

Indeed, I have referred to your web site many times over the years while unpicking various horrific daemon control shell scripts in order to run them under sane init systems... :)

We used Upstart until just a couple of years ago, and it was still losing service processes regularly (as in, you start a service, then you stop it, but the process keeps running, despite Upstart telling you it's stopped).

I don't know if systemd is better (I've never managed a server fleet with it), but Upstart certainly wasn't good enough.

Reply on news.ycombinator.com