Miles Fidelman <mfidel...@meetinghouse.net> writes:
> Rainer Weikusat wrote:
[...]
>> Also, to re-iterate this: What an init script needs to do is really only
>> 'start a process'/ 'stop a process'. Most of the other code which crept
>> in there during the last 15 - 20 years will fall into one of two
>> categories
>>
>> 1) Never did anything useful
>> 2) Should never have been implemented in this way.
>
> It can be a bit more than that, for example, the sympa mailing list
> package consists of multiple programs that are started in order, and
> includes
> - start (all 4)
> - stop (all 4)
> - restart (stop, in order; start in order)
> - status
>
> Most server scripts do some setup and cleanup. There's also typically
> a reload config files option.
I'm aware how existing init scripts look like but that's just another
example of 'coral reef' coding: Some code is needed (or believed to be
needed). Where's the most convenient place it can be added? The init
script, obviously! It's just a shell script and thus, easy to
modify. For simple modifications, this is even a good idea, because
after all, the intent is not to create a statue but to make something
work. This gets problematic when there are, say, 5 different people who
always work in this way whose small hacks keep piling up over the course
of a few years (I have some specific code in mind): The inevitable
result is a horrendous mess which doesn't work almost all of the time
and nobody can still tell which parts of it are doing what and how they
all interact.
For the example you're using, if these 4 programs really belong to the
same package, the obvious idea would be to write a script starting them
and a script stopping them and let the init script execute
these. Restart can be implemented as stop followed by start but that's
already a convenience compromise. The others have no business in the
init script as they're not about starting or stopping programs.
Dito for setup and cleanup: For as long as these are simple, limited
task, eg, something like this
CONFIG=/etc/config-file
. $CONFIG
: ${DEBUG:=3}
putting it into the init script makes sense. But not five such blocks in
a row, possibly even with some conditionals around them to execute or
not execute them in various combinations.
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
