Ubuntu

Bug #642555
Comment #8

Comment 8 for bug 642555

Revision history for this message

Colin Watson (cjwatson) wrote on 2010-11-22:

It would help to try to narrow this down somewhat. While using /dev/null as a fallback if opening the real console fails is suboptimal (and I'd like to try to figure out a better fix for that, although it is tricky), it should certainly have resolved any failures to start services that were due to not having a console fd. At the very least we should now be seeing some other problem that was perhaps previously masked. As such, we should narrow that down rather than simply saying that bug 554172 has recurred, which may not quite be the case - all we know is that this bug shows similar *symptoms*, not that it has the same *cause*. I realise that if your system isn't booting properly then the distinction may not matter very much, but it does matter for us trying to figure out a solution.

One situation in which having /dev/null as the console may genuinely impede starting services would be if the service is trying to read from the console, and refusing to proceed until it gets an answer. To those affected by this bug: do you know if your system, when working correctly, would ordinarily prompt for input on the console? For example, since nginx was mentioned, an nginx configuration involving a passworded SSL private key would probably result in such a prompt.

It is unfortunate that using --verbose tends to perturb the timing such that we can't reproduce this any more. One alternative possibility might be to put 'initctl log-priority info' in /etc/init/rc-sysinit.conf, just above the 'telinit "${DEFAULT_RUNLEVEL}"' command; perhaps effectively using --verbose for a fragment of the boot sequence rather than all of it will make this bug reproducible with debugging information.

If you can reproduce this bug either with --verbose or with 'initctl log-priority info', then please attach /var/log/syslog to this bug report. The point of those options is not to work around the bug, but to generate debugging information so that we can figure out what's going on.

It would help to try to narrow this down somewhat.  While using /dev/null as a fallback if opening the real console fails is suboptimal (and I'd like to try to figure out a better fix for that, although it is tricky), it should certainly have resolved any failures to start services that were due to not having a console fd.  At the very least we should now be seeing some other problem that was perhaps previously masked.  As such, we should narrow that down rather than simply saying that bug 554172 has recurred, which may not quite be the case - all we know is that this bug shows similar *symptoms*, not that it has the same *cause*.  I realise that if your system isn't booting properly then the distinction may not matter very much, but it does matter for us trying to figure out a solution.

One situation in which having /dev/null as the console may genuinely impede starting services would be if the service is trying to read from the console, and refusing to proceed until it gets an answer.  To those affected by this bug: do you know if your system, when working correctly, would ordinarily prompt for input on the console?  For example, since nginx was mentioned, an nginx configuration involving a passworded SSL private key would probably result in such a prompt.

It is unfortunate that using --verbose tends to perturb the timing such that we can't reproduce this any more.  One alternative possibility might be to put 'initctl log-priority info' in /etc/init/rc-sysinit.conf, just above the 'telinit "${DEFAULT_RUNLEVEL}"' command; perhaps effectively using --verbose for a fragment of the boot sequence rather than all of it will make this bug reproducible with debugging information.