Why writing init scripts was so scary and people needed systemd for?

recklessswing · 2025-08-15 22:55:14

When I see forums about why systemd is good, they say we don't need to write init scripts blah blah. Even chatgpt can write those just fine, even then it works well. Why people just get a cow(systemd) when you can instead buy a liter of milk? It doesn't seem hard, those scripts, they all look the same too? start stop blah blah something. I even got tailscale working well. My point is even those init scripts somehow be automated, it seems systemd solves problems that isn't there, it's overkill.

Just curious, do corporate environments use systemd a lot? Are there any corporates that use Devuan?

Last edited by recklessswing (2025-08-15 22:56:04)

EDX-0 · 2025-08-16 00:01:57

the madness of initscripts was/is that they allow for daemons to have subpar behaviour that is abstracted from the init system, and systemd was "sold" as the solution as it could handle some of those badly behaved daemons that needed complex initscripts which were "hard to debug", but developers managed to defeat that idea and re-invent initscripts in a worse language. here's an extract from a conversation i had on this a while ago, should probably put it in my github along other stuff from my vimwiki or use some static site generator to make a blog of sorts

in the unix world we have services and daemons, while many equate "services" with running a web server (or ftp server, or ssh server) of some sort, a "service" in the unix world is not a web server, but just a process that is managed, started, stopped and maybe even monitored by another process.
a daemon is a "long running process", could be one that runs for as long as a user is logged in or for a long as the computer is on, but in spite of daemons mostly being services, they aren't always services, and services aren't always necessarely daemons
there are 2 basic types of services from which all others are but variations of:

daemon: the most basic type of service as it is just a daemon that will run, it can run for multiple runlevels or it can run for as long as a user is logged in, it has a process identification digit (PID), a PID file, it runs with the priviledges of some user, the PID file can be used to monitor the service.

oneshot: a process that will be ran and not linger nor have a PID, it will run, do something and then terminate, maybe with an exit status, whatever command is ran to "start" the service can have a "stop" counterpart, or not.

the "traditional" manner to handle that madness was with initscripts, which are nothing more than just shell scripts that can accept the "start", "stop", "status", "restart" and optionally the "reload" and "force-reload" arguments, the init system needs not to know how the initscript handles those as whatever madness and witchcraft is needed to get the service running is done in the initscript
most inits use the initscript or a similar paradigm of abstracting the sorcery from the init system

systemd has the units system, the paradigm is that the madness is not necessary to abstract from systemd and can be thrown into the multiple options of the systemd unit so long as the systemd unit options can handle said madness... the main options are:
ExecStartPre=
ExecStart=
ExecStartPost=
ExecStopPre=
ExecStop=
ExecStopPost=
ExecReloadPre=
ExecReload=
ExecReloadPost=

now there is nothing bad with those, systemd allows you to just write commands in there and it will evaluate said commands to run them
and then ya got stuff like this, because systemd had to allow multi line commands in some way, and what better and more natural way than to do so with shell style line breaks
ExecReload=busctl call org.freedesktop.DBus \
/org/freedesktop/DBus org.freedesktop.DBus \
ReloadConfig
until now there is nothing bad in how units are defined
but that applies for simple commands
the problem starts when people start to abuse the systemd units and treat them like a fully fledged shell-like scripting language just because the documentation says you can throw some madness into the unit file
and you wound up with systemd unit files which are over 50 lines long where at least 40 of those lines are some Exec*Pre/Exec*Post command that juggles values to and from tmp files...

at that point it is just re-inventing initscripts but with a way worse "scripting" language that only got support for a form of conditionals in version 243...
and then someone comes in with some sense to put all that madness of pre and post exec commands inside scripts...
which was what the paradigm that systemd was trying to prevent from happening in the first place because "initscripts are hard to debug" (if you don't know bash)

so the proper way would be to split the initscript to multiple scripts handling start, stop, restart etc. respectively and the define then unit using these scripts?

not really, the "proper" way would be that services should not need much wizardry to be started and stopped, but since that ain't happening... then the less bad way would be to have a (or multiple) script(s) to handle the madness needed by the service and then let both .service unit files and initscripts for whatever init needs them be "dumb" files that deal only with an abstracted and simple interface with a predictable behaviour

GlennW · 2025-08-16 01:09:49

wow! That helps to explain a few things, Thanks EDX-0.

EDX-0 · 2025-08-16 04:19:45

worth noting tho, that my critcism in that post is to the way that service definition is implemented in systemd, there's a huge lot to pick on about systemd and criticize the ideas and execution, however the IDEA of defining a service in a simple key=val file that contains commands, arguments and other config parameters for starting a daemon is not inherently bad, and is a simple paradigm so long as there's a layer that can guarantee good abstraction and provide a system by which the service definition can be tweaked

and fun as it turns out, a similar paradigm not only exists, but was rolled out before systemd and as it happens it was based on shell script and works better than the systemd units paradigm

enter the "init-d-script" a generic initscript framework that tackles the most common service type, the daemon, you can check it now in /lib/init/init-d-script and not only does it have the mechanisms to handle bad behaved daemons (daemons that do not background themselves, do not create a pidfile and/or do not delete their pidfile upon termination) but even provides the ability to add overrides for the start, stop and status commands, allowing for supporting not just daemons but also oneshot services

and all that while still maintaining full compatibility with the lsb spec and keeping the script easy to debug

not to mention that a minimal init-d-script can look like this:

#!/bin/sh

# kFreeBSD do not accept scripts as interpreters, using #!/bin/sh and sourcing.
if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then
    set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script
fi

### BEGIN INIT INFO
# Provides:       acpufreq
# Required-Start: $remote_fs
# Required-Stop:  $remote_fs
# Default-Start:  2 3 4 5
# Default-Stop:   0 1 6
# Description:    acpufreq - Auto CPU Frequency Daemon
### END INIT INFO

DESC="acpufreq"
DAEMON=/usr/local/sbin/afreq
PIDFILE=/var/run/acpufreq.pid
START_ARGS="--user root --chuid root --background --pidfile ${PIDFILE} --make-pidfile"
STOP_ARGS="--user root --pidfile ${PIDFILE} --remove-pidfile"

which at a high level comes out not any more complex than a sytemd unit file...

but oh the horrors of shell script like this were too many and systemd had to save the world from the opressive tyranny of shell...

trinidad · 2025-08-16 15:58:19

at that point it is just re-inventing initscripts but with a way worse "scripting" language

Modern development in Linux is like a runaway train that people keep trying to attach cars to as it flies by. What many desktop users don't realize is that systemd and wayland are contingencies in preparation for the actual future of corporate Linux ... the immutable core system with AI in user space.
Conceptually informative post.

TC

Last edited by trinidad (2025-08-16 15:59:04)

Altoid · 2025-08-16 16:21:41

Hello:

trinidad wrote:

... systemd and wayland are contingencies in preparation for the actual future of corporate Linux ...

Quite so.
And then, Devuan (and every other distribution built on it) will be toast.

I once wrote:

Debian (fundamentally, the ecosystem* behind it) knows this because it is, for the most part, the path / timeline they have traced from the start.
Eventually, Debian (at least as we know it today) will also cease to exist and be replaced with whatever it is they eventually come up with.
* MS, RH, IBM, Alphabet, etc.
The next step, already in motion, is this cross-distro unification idea.
And when that has become the norm, the question they will be asking will be "why do we have so many distributions?", the answer being quite obvious:
Why not have just The One OS for everyone, much easier to maintain.
And control.
Imagine, even a simple AI will be able to do it. 8^°
It is not a prophecy or any such thing, the writing has been on the wall for the longest time.
Way before Poettering's 2010 screed.

Best,

A.

Last edited by Altoid (2025-08-16 16:28:08)

EDX-0 · 2025-08-17 04:28:41

if you don't like where linux is headed then write software to help prevent that path or at the very least keep the existing path running

Camtaf · 2025-08-17 09:13:09

I keep my hand in with the BSDs, just in case Linux really does 'go bad', & also keep an eye on other operating systems such as Haiku....

(Debian's uptake of pulseaudio & systemd were the deciding factor for abandoning pure Debian for me.)

Last edited by Camtaf (2025-08-17 09:15:17)

chris2be8 · 2025-08-17 16:16:02

OpenSolaris and it's fork OpenIndiana are also worth keeping an eye on.

EDX-0 · 2025-08-18 08:25:03

defeatism much?

greenjeans · 2025-08-18 17:00:38

No defeat here, my plan is to eventually fork all the things, fork 'em hard and often.

"but greenjeans, all muh apps...they all roll with the gnome/redhat protocols"

MAKE NEW APPS THAT DON'T.

Hell even I can make new stuff, and apparently i'm a lower form of life, lol. If I can do it, anybody can.

Spend less time reading the ragebait and re-posting it folks, use that time to do something about it.

ruenoak · Yesterday 00:43:32

I speak with no authority on the subject but from what I have read and heard, the hard coding of systemd into applications is mostly unnecessary. I don't know what benefits to that application it enhances other than enforcing systemd

I could be completely wrong here though.

The officially official Devuan Forum!

#1 2025-08-15 22:55:14

Why writing init scripts was so scary and people needed systemd for?

#2 2025-08-16 00:01:57

Re: Why writing init scripts was so scary and people needed systemd for?

#3 2025-08-16 01:09:49

Re: Why writing init scripts was so scary and people needed systemd for?

#4 2025-08-16 04:19:45

Re: Why writing init scripts was so scary and people needed systemd for?

#5 2025-08-16 15:58:19

Re: Why writing init scripts was so scary and people needed systemd for?

#6 2025-08-16 16:21:41

Re: Why writing init scripts was so scary and people needed systemd for?

#7 2025-08-17 04:28:41

Re: Why writing init scripts was so scary and people needed systemd for?

#8 2025-08-17 09:13:09

Re: Why writing init scripts was so scary and people needed systemd for?

#9 2025-08-17 16:16:02

Re: Why writing init scripts was so scary and people needed systemd for?

#10 2025-08-18 08:25:03

Re: Why writing init scripts was so scary and people needed systemd for?

#11 2025-08-18 17:00:38

Re: Why writing init scripts was so scary and people needed systemd for?

#12 Yesterday 00:43:32

Re: Why writing init scripts was so scary and people needed systemd for?

Board footer