Comment 9 for bug 652221

On Mon, 04 Oct 2010 06:43:24 -0000, Steve Langasek <email address hidden> wrote:
> On Mon, Oct 04, 2010 at 03:39:14AM -0000, Michael Hudson-Doyle wrote:
> > It seems to be present, but possibly not starting for some reason? I
> > don't speak upstart well enough to understand the following:
>
> > root@localhost:~# status openvt
> > openvt start/pre-start, process 495
>
> If this is reproducible, next time you hit this can you please see what the
> PID listed as 'openvt start/pre-start' is doing?

root@localhost:~# status openvt
openvt start/pre-start, process 479
root@localhost:~# ps 479
  PID TTY STAT TIME COMMAND
  479 ? Ss 0:00 stop tty1

> This suggests that we've
> hung trying to run 'exec stop tty1',

Yeah, looks like it.

> which should be a trivial operation. Getting the 'ps' output, strace
> output,

root@localhost:~# strace -p 479
Process 479 attached - interrupt to quit
restart_syscall(<... resuming interrupted call ...>

(that doesn't look very illuminating!)

> and a backtrace would help.

Not really:

(gdb) bt
#0 0x4019c896 in ?? () from /lib/libc.so.6
#1 0x4021de70 in poll () from /lib/libc.so.6
#2 0x00000006 in ?? ()
#3 0x00000006 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

> On Mon, Oct 04, 2010 at 04:13:32AM -0000, Michael Hudson-Doyle wrote:
> > Hmm, again with the utter lack of upstart chops, I think this might be
> > some kind of race between the openvt and tty1 jobs. Maybe the openvt
> > job is being started and so 'stop tty1' is being called before the tty1
> > job fully starts up, or something.
>
> The intended behavior here is:
>
> - the start conditions for the tty1 job are met.
> - upstart sees that openvt is 'start on starting tty1' and processes it
> first.
> - the pre-start script runs and sets the tty1 job back to 'stopped' state
> with no further processing

This appears to be where we're failing.

> - the openvt exec line runs, and the openvt job is marked as
> 'start/running'
>
> Starting the openvt job manually does the same thing, except that 'exec stop
> tty1' is a no-op if tty1 is already stopped.

This seems a little strange:

root@localhost:~# status tty1
tty1 stop/starting

I'm attaching the syslog that resulted from adding --verbose to the bootargs.

Cheers,
mwh