Scott was kind enough to provide some background on this bug in the #upstart channel:
<Keybuk> in Linux, we have consoles <Keybuk> but really we mean Virtual Terminals (VTs) <Keybuk> and we have TTYs too <Keybuk> not to mention Pseudo-Terminals <Keybuk> (PTYs) <Keybuk> it's all a bit of the kind of jumble sale you get after 40 years of different solutions to different problems <Keybuk> we can lump them together under the description "terminals" for the next bit <Keybuk> we also have processes <Keybuk> now, processes have a lot of odd little details <Keybuk> they have a parent <Keybuk> they have a session <Keybuk> and a session has a foreground process group <Keybuk> and a background process group <Keybuk> now Stevens devotes an entire chapter for this <Keybuk> and nobody but me apparently understands it ;) <Keybuk> (and hopefully the guy who maintains the kernel side) <Keybuk> but it works something like that <Keybuk> each process is part of a session <Keybuk> a process may begin a new session by calling setsid() <Keybuk> every process that init creates is in its own session <Keybuk> the process is also then the leader of the foreground process group of that session <Keybuk> new processes are also in that session <Keybuk> and in that process group <Keybuk> unless otherwise placed into a new process group <Keybuk> (setpgrp) <Keybuk> any new process group is a background process group <Keybuk> so now, you have a bunch of sessions <Keybuk> each session has a bunch of process groups, one of which is the foreground process group <Keybuk> each process group has a bunch of processes, one of which is the leader <Keybuk> so this all has to do, fundamentally, with terminals <Keybuk> and who gets the signals <Keybuk> when the leader of the foreground process group of a session opens a terminal device (without O_NOCTTY) that becomes the CONTROLLING TERMINAL of that process group <Keybuk> (in fact of that session) <Keybuk> the terminal and the session become bound to each other <Keybuk> you can fake this another way by opening a terminal device without O_NOCTTY (or having one passed to you) and then calling the TIOCSCTTY ioctl <Keybuk> ok <Keybuk> so <Keybuk> terminals, controlling terminals and processes <Keybuk> here's where this gets fun <Keybuk> if the controlling terminal is hung up, SIGHUP is sent to the foreground process group <Keybuk> if ^C is pressed on the controlling terminal, SIGINT is sent to the foreground process group <Keybuk> if ^Z is pressed on the controlling terminal, SIGTSTP is sent to the foreground process group <Keybuk> (you're getting the idea here I guess) <Keybuk> so this is how the relationship between magic key presses and signals gets established <Keybuk> shells care about this a lot <Keybuk> (and yes, when you use & that becomes a background process group :p) <Keybuk> (and when you use | they are all in the same process group) <Keybuk> now <Keybuk> this controlling terminal business applies to all terminals <Keybuk> whether they be true terminals (which linux doesn't have) <Keybuk> or virtual terminals <Keybuk> or pseudo terminals <Keybuk> so this is as true for your ssh login as VT1 <Keybuk> you can always access your *controlling terminal* using /dev/tty <Keybuk> it's a badly named device node <Keybuk> it may also be called /dev/ttyS0 or /dev/pts/4 etc. <Keybuk> so right <Keybuk> Linux has a bunch of virtual terminals <Keybuk> these are the things we think of when we say "console" but we're using that wrong <Keybuk> virtual terminals behave just like ordinary terminals <Keybuk> they can be the controlling terminal for a process group <Keybuk> but, unfortunately, stacked on top is the linux vt API <Keybuk> (they didn't think to make it separate) <Keybuk> so the stuff to set fonts <Keybuk> to place it in raw or graphics mode <Keybuk> to create new vts <Keybuk> to switch vts <Keybuk> etc. <Keybuk> is all loaded into the tty api <Keybuk> so, in order for X to function, it needs a VT <Keybuk> and it needs access to that VT in interesting and familiar ways to place it into raw and graphics mode <Keybuk> and so on <Keybuk> it also needs to know if the *current VT* is switched <Keybuk> so it opens the VT device it wants (/dev/tty7) <Keybuk> and that becomes its controlling terminal <Keybuk> so if you were to delete VT7, X would get SIGHUP :) <Keybuk> now, on VT1-6 you have getty <Keybuk> on VT8 you have usplash <Keybuk> and so on <Keybuk> this is all fine and dandy <Keybuk> except there's this last mystical piece <Keybuk> /dev/console <Keybuk> /dev/console is, like /dev/tty, a fake device <Keybuk> it points at the currently active VT <Keybuk> whatever that is <Keybuk> but it *behaves* like a terminal in its own right <Keybuk> (whereas /dev/tty just behaves as a proxy for the underlying terminal) <Keybuk> now, Upstart has a few knobs to customise the standard input, output & error file descriptors <Keybuk> normally it just starts all jobs with them as /dev/null <Keybuk> but for *emulation of sysvinit* it has two other options <Keybuk> 1. set them to /dev/console <Keybuk> 2. set them to /dev/console and issue the TIOCSCTTY ioctl() <Keybuk> (console output, console owner) <Keybuk> now, if your current VT is 7 (X) <Keybuk> and you start a job that has console owner in it <Keybuk> the new process will *take the terminal away from X* <Keybuk> X gets SIGHUP <Keybuk> and either hits 100% CPU or crashes Solving this problem for good requires jobs that need user input to be rewritten: <Keybuk> so this is clearly BAD <Keybuk> the problem really is that things need a "console" at all <Keybuk> jobs that require interaction should DO IT THEMSELVES <Keybuk> they should open a VT, switch to it, and ask there <Keybuk> or they should use usplash to do it <Keybuk> or they should use X -- [karmic] Xorg 100% CPU utilization -- only after first login https://bugs.launchpad.net/bugs/439138 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
