Hacker News Reader

Comment by kalenx | Hacker News Reader

As are most Bash init files with InitV... At some point we should consider that the init system as a whole (including the configuration scripts for each daemon) _is_ complicated and often confusing. In this regard, writing something like SystemD to elegantly handle most of the usecases is actually a good idea.

View on HN

Many comments seem to only compare systemd with SysV init. But there is a whole world of process supervisors out there, particularly in the daemontools[1] family.

systemd is a process supervisor plus additional features; sysv init is not a process supervisor (though the "init" program as configured in /etc/inittab is a supervisor). At a minimum, a process supervisor starts processes and restarts them should they exit.

Some modern daemontools-family systems with additional features beyond basic supervision that put them in the same category as systemd are nosh[2] and s6-rc[3]. These two systems (and all the daemontools family), in contrast to systemd, are not monolithic, but composed of multiple smaller programs.

Notably, they depend on the shell (any script or executable, but traditionally small shell scripts) to perform actions like setting up environment variables, switching to a less privileged user, redirecting output, etc. while systemd has created a large and growing set of directives[4] to accomplish these. This set of directives is one of my annoyances with systemd. As someone familiar with the shell, I find it annoying to learn yet another language (systemd directives) for expressing the same thing, though I recognize not everyone is familiar with shell.

[1] http://cr.yp.to/daemontools.html

[2] http://jdebp.info./Softwares/nosh/

[3] http://skarnet.org/software/s6-rc/

[4] https://www.freedesktop.org/software/systemd/man/systemd.dir...

Binary logs, hex logs, there's enough stupidity to go around!

Bash init files may not be particularly feature rich, but they are hardly "complicated".

90% of every file is boilerplate built around: stop, start, status (after all restart is just stop+start).

Proponents of SystemD can make some good points, but trying to claim init.d is complicated comes across as desperate.

And 90% of that 90% has that tiny modification that is a nightmare to debug.

What he wanted to say: you can debug since context is very local. (not taking sides)

Use `set -x` or `bash -x script.sh` to trace shell script execution. Shell scripts are easy to debug.

I call this to drop into an immediate repl at the point of invocation in a language that doesn't hate me (Ruby):

     require 'pry'; binding.pry

This is, in fact, 2017. One might call it the current year. The stone knives and bearskins of shell scripting have not kept apace with, like...anything else in our industry. You might be comfortable with them, but that doesn't make it easy, it means you have frayed countless synapses learning it.

You forget that sysvinit also required fun extras like supervisord to run simple executables because it relied on applications demonizing themselves.

Writing systemd unit files for my applications is a breeze compared to the shit I had to do for sysvinit - especially when I factor in apps I DIDN'T write that I need unit files for (teamcity, etc) and there's less surprise with SELinux policy transitions (and unlike most setenforce 0 is not the first thing I run on a server, I work in healthcare and a solid MAC layer is important to me).

> Bash init files may not be particularly feature rich, but they are hardly "complicated".

Are you trying to make the argument that shell scripts are simple, easy to read, and maintainable?

Permit me to disagree.

Yep, they are. Shell is lingua franca for system administrators for whole history of UNIX.

Which one? ash? csh? tcsh? ksh?

I don't think you have as much experience with Unix as you would like us to think you do.

What do you mean which one? It's /bin/sh. /bin/sh has always been the shell used, because it's the only one guaranteed to be on all unixen. No system ships their init scripts written in ash, csh, tcsh, ksh, or anything besides /bin/sh (except Linux, which may have used /bin/bash, since /bin/sh was symlinked to /bin/bash)

You might have made your personal init scripts in some other shell (until you learned about design failures of csh), but I'm willing to bet your Unix distributor did not.

I rarely see a bash script more than five lines long which doesn't have at least one bug.

If you disagree with me then post an example and I'll show you the bug in it.

Also, it's not the 90% that matters; it's the 9% that is difficult and the 1% that is crap.

There's this example for your approval: https://news.ycombinator.com/item?id=13388322

The reply from bazurbat covered it well.

What about runit?

Unlike all of the above, runit isn't complicated. You write a tiny, often one-line script and it executes, if it exits, it waits a reasonable amount of time and restarts it.

Not only is it not complicated, but it runs beautifully on top of an existing init system. So now wherever I go I have one tiny script that will start my python based web services and similar. I run the same basic script on freebsd rc, ubuntu upstart and arch systemd boxes.

Watch the special case directives grow until you can use systemd to implement Conway's Game of Life...

Reply on news.ycombinator.com