Re: [Cooker] Improving robustness of startup/shutdown scripts
Michael Brown wrote:
I have come across a few badly-behaved startup scripts (such as for
vncserver) which can, under some circumstances, expect user input when
called as /etc/rc.d/init.d/whatever start|stop. During system startup,
stdout does not appear, so the user never sees the prompt - it just looks
as though the machine has hung partway through starting up the service.
A fix for this problem could be to patch the definition of action in
/etc/rc.d/init.d/functions, so that the init.d scripts are always run with
stdin redirected to /dev/null. Something like
action() {
...
initlog $INITLOG_ARGS -c $GPRINTF_REST /dev/null success ...
...
Is this a reasonable idea?
Michael
Would it affect the operation of kudzu? That seems to have no problems
hijacking the startup when it finds new or removed hardware.
RE: [Cooker] Improving robustness of startup/shutdown scripts
Michael Brown wrote:
I have come across a few badly-behaved startup scripts (such as for
vncserver) which can, under some circumstances, expect user input when
called as /etc/rc.d/init.d/whatever start|stop. During system startup,
stdout does not appear, so the user never sees the prompt - it
just looks
as though the machine has hung partway through starting up the service.
A fix for this problem could be to patch the definition of action in
/etc/rc.d/init.d/functions, so that the init.d scripts are
always run with
stdin redirected to /dev/null. Something like
action() {
...
initlog $INITLOG_ARGS -c $GPRINTF_REST /dev/null success ...
...
Is this a reasonable idea?
Michael
Would it affect the operation of kudzu? That seems to have no problems
hijacking the startup when it finds new or removed hardware.
Except when you use Aurora in which case the above may be useful.
-andrej
