Steve Litt - 11.05.24, 02:45:35 CEST:
> Sysvinit's process controller is, IMHO, inferior to runit and s6
> because it requires daemons to background themselves, and its init
> scripts are huuuuuuuge. Systemd advocates would also include as a
> disadvantage that sysvinit's process controller can't fork processes in
> parallel. I don't think that's a significant disadvantage unless a
> daemon is incredibly slow in starting, in which case, shame on the
> daemon or shame on the admin (if he botched reverse DNS, for instance).

I'd not consider something like

#!/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:          fio
# Required-Start:    $syslog
# Required-Stop:     $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Flexible I/O Tester as service
# Description:       Runs fio as a service to that fio clients can connect
#                    to it
### END INIT INFO

# Author: Martin Steigerwald […]

DESC="Flexible I/O Tester as service"
DAEMON=/usr/bin/fio
DAEMON_ARGS='--server --daemonize /run/fio.pid'
PIDFILE='/run/fio.pid'

particularly huge.

Granted, most of the logic is within init-d-script. Still there has been
potential for minimal init scripts.

I agree that runit and s6 are superior and more elegant in the end, but
I still find it important to give an accurate representation. Late SysVinit
within Debian at least is not as dumb as one might think.

The "BEGIN INIT INFO" is the block out of which insserv generates some
hidden ".depend*" files that startpar uses to run init scripts in parallel
where possible. AFAIK it uses a Makefile like approach.

Best,
--
Martin