:: Re: [DNG] Init scripts in packages
トップ ページ
このメッセージを削除
このメッセージに返信
著者: Rainer Weikusat
日付:  
To: dng
題目: Re: [DNG] Init scripts in packages
"tilt!" <tilt@???> writes:
> On 08/06/2015 11:28 AM, Rainer Weikusat wrote:
>> [...]
>> But a bare-bones init script does really only three things:
>>
>> 1. Execute a command to start something.
>> 2. Execute a command which stops it again.
>> 3. Execute 2) then 1) for a restart.
>
> There are additional actions required by [LSB]; out of these
> I appreciate a "status" action the most - the use of the others
> is debatable if not questionable, but "status" I find really
> important.


Even the restart is already an example of 'cat -v programming' (or
'coral reef design' -- $stuff growing on $other_stuff because $other_stuff
already exists) and 'status' is worse as the semantics are also muddy: What
ever the output happens to be, it contains information which happened to
be accurate at some random point in time in the past and it's neither
known if it's still accurate nor when it was accurate for the last
time. Further, what precisely comprises a useful bit of "status
information" is very program dependent. Eg, the status of a Java
application running on top of JBoss might be 'the JVM got started and
deployment worked, however, because of a typo in some named query,
Hibernate couldn't make sense of it so it isn't really working at the
moment', the status of a ssh server might be "everything's fine but can
we disconnect China as the IPs could be put to a better use than for
scripts trying to break into the system", the status of a long runnning
computation might be "still running, n% completed" and some other task
might just wait for something to do.

Insofar a particular task involves a idempotent process with indefinite
lifetime ('idempotent' here supposed to mean that 'restart in case of
unexpected termination' make sense), "did it terminate despite it wasn't
asked to" would be a useful piece of generic status information but
that's primarily interesting to a program supposed to manage 'daemon
processes' and that's beyond the scope of an start/stop script which
knows nothing about the effects/ purpose of the tasks it's employed to
start or stop.