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