:: Re: [DNG] init scripts
Top Page
Delete this message
Reply to this message
Author: Rainer Weikusat
Date:  
To: dng
Subject: Re: [DNG] init scripts

[...]

> Rainer Weikusat via Dng - 02.08.23, 16:39:01 CEST:
>> Martin Steigerwald <martin@???> writes:
>> > karl@??? - 01.08.23, 20:36:05 CEST:
>> >> > I just don't understand why it should take hundreds of
>> >> > lines of shellscript to run a simple command.
>> >>
>> >> For busybox I just use a handwritten /etc/rcS to do everything,
>> >> about 112 lines on my personal box, makes life very simple tough
>> >> not automatic.
>> >
>> > Some init scripts of SysVInit in Debian use a wrapper that can lead
>> > to init scripts as simple as:
>> >
>> > % cat /etc/init.d/fio
>> > #!/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'
>>
>> In this case, the mess has been pushed into something else. A typical
>> init script I'm using looks like this:


[...]

> Regarding your example:
>
>> ,----
>>
>> | case "$1" in
>> | 
>> |     start)
>> |     
>> |         systemd-dance "$0" && exit 0

>
> What is this? If not putting logic elsewhere?
>
> The other commands could be some of the software you use here, I don't
> know. But the "systemd-dance" command or script appears to be exactly
> what you criticize below:


What I was criticizing is creating spurious 'frameworks' out of
something that's actually very simple, ie, less than two dozen lines of
code. Abstraction isn't free. Nobody looking at your script example can
tell what will actually happen when the script being run (as that's in a
different file). This is only worthwile it saves a significant amount of
code.

systemd-dance is a (source) 40 line C program which checks if the script
is being run by init ('pid1' in Poetterlingo) and if not, executes the
systemctl command to start the systemd unit corresponding with the
script. That's the necessary minimum for making a more traditional
start/stop-script coexist peacefully with the systemd framework.

[...]

>> The historically accumulated mess in Linux init.d scripts is/ was
>> indeed fairly gruesome. But that's just an example of poor
>> programming/ software design and in not way tied to the arrangement
>> used for running such scripts at certain times. Thus, the main
>> argument of the Poetterclown was that "Look what a mess you've made
>> of the stuff you've put into your old shelf! You absolutely need my
>> New And Very Much Improved Shelf[tm] because of this!"


[...]

> That written, I still do not agree with the sentiment that every idea
> and every part of Systemd is bad.


If there's something in systemd that's not bad, both by design and
implementation, it's probably a bug which will eventually be fixed once
someone finds it.

:->

[...]

> Just remember: When go you in with something like "your stuff is all
> shit" then that probably won't trigger the cooperative response you
> probably would like to see. A detailed feedback, in actionable pieces,
> best with offer to help would surely give better results.


This (system initialisation/ server startup) is a topic that's of some
interest to me and I've done quite a bit of work on it in the last 20
years (all proprietary, though). Hence, I'm - within reasonable limits -
interested in discussing it. Discussing also includes criticizing. If
this triggers a reasonable response, eg, something like "I think you're
wrong because ...", that's fine. If not, I can also live with that.