[01:17] <Md> Keybuk: did you find a solution to the multiple consoles problem? (I mean, standard init only outputs to /dev/console which can be either the monitor *or* the serial console but not both)
[11:11] <Keybuk> Md: "the multiple consoles problem" ?
[11:19] <Md> Keybuk: in practice you cannot use at the same time a serial console and a normal monitor
[11:20] <Md> this tends to limit the usefulness of configuring a serial console in some environments, so I wonder if this is something which could be solved in upstart...
[11:24] <Keybuk> well, you'll still have the basic problem that the kernel only recognises one console at a time
[12:16] <keesj> Keybuk: it can and does output to different consoles at the same time, but only one (the first one I think) is interactive
[12:17] <keesj> mu upstart "service_console" does some cat /proc/cmdline magic to reuse the same serial as given
[12:28] <Keybuk> keesj: how do you mean?
[12:32] <Md> keesj: the last one, which is the one which connects to /dev/console
[12:32] <Md> so I wonder if it would be practical to make upstart listen for input on all configured consoles
[12:32] <Md> s/connects to/becomes/
[12:36] <Keybuk> upstart doesn't "listen for input" ?
[12:37] <Md> Keybuk: think about single user mode, when there is no getty
[13:08] <Keybuk> Md: yes, but getty can only be attached to one pty at a time
[13:09] <Keybuk> there's no pty multiplexer inside the kernel :)
[13:09] <Keybuk> there is one in userspace
[13:09] <Keybuk> called "screen" :)
[13:09] <Keybuk> I've non-jokingly suggested before that on servers we should start screen on the consoles
[13:09] <Keybuk> but not sure what happens to consoles at all with KMS yet
[13:24] <Md> Keybuk: the problem is not gettys, but everything before that
[13:24] <Md> you can already start as many gettys as you need
[13:29] <Keybuk> I'm clearly not following ;)
[13:30] <Md> stdin/out/err of init is normally connected to /dev/console
[13:30] <Md> and /dev/console can be only one of the consoles configured on the kernel command line
[13:31] <Keybuk> right
[13:32] <Md> so it would be very useful if init could multiplex its input and output on all existing consoles. OTOH, it may be argued that this should be fixed in the kernel
[13:33] <Md> the use case is that if you configure the serial console e.g. for the IPMI netconsole then an attached monitor and keyboard are useless
[13:33] <Keybuk> but it's not that simple
[13:33] <Keybuk> what if the different consoles are different sizes?
[13:33] <Keybuk> what if they have different terminal types (esp. relevant to serial console)
[13:33] <Keybuk> or different speeds?
[13:34] <Keybuk> multiplexing ptys is not a simple job
[13:35] <Md> I do not think that there is much expectation of curses applications working before a getty is started anyway
[13:35] <Keybuk> one of the most run things from single-user mode surely is apt? :p
[13:35] <Keybuk> which implies aptitude
[13:35] <Keybuk> or debconf
[13:35] <Keybuk> they're all curses
[13:36] <Keybuk> hell
[13:36] <Keybuk> in Ubuntu we don't just drop to bash in single user mode
[13:36] <Keybuk> but we display a curses menu of common fixes
[13:36] <Keybuk> one of which is "give me a root shell"
[13:37] <Keybuk> we often get away with justifying why single user mode exists on the basis that "you're at the physical console, so you could take away the machine"
[13:37] <Keybuk> opening that up to foreign consoles could be implied to be a bug
[13:38] <Keybuk> I'm not disagreeing that it would be nice
[13:38] <Keybuk> but I think that Upstart is not the appropriate place to do it
[13:38] <Keybuk> or even in the kernel
[13:38] <Keybuk> but reconfiguring single user mode to run screen, connected to the listed consoles, then running things in that
[13:38] <Keybuk> screen in single user mode is a win anyway, since then you can spawn additional shells ;)
[13:39] <Md> I see that doing this in init is complex, but it's not just single user mode but the messages of the init scripts as well
[13:41] <Keybuk> oh, I fully plan to get rid of those ;)
[13:41] <Keybuk> they shouldn't be on the console anyway unless !quiet
[13:42] <Md> not even if a script failes?
[13:42] <Md> fails, even
[13:42] <Keybuk> the console is not a very useful place to put those
[13:43] <Keybuk> I'm thinking more of the cron model
[13:43] <Keybuk> logging the error messages, e-mailing them, putting them in the syslog, etc.
[13:43] <Keybuk> it should be trivial to write a program that when you login tells you there were errors during boot
[13:43] <Keybuk> and you should be able to look through those errors
[13:44] <Keybuk> and it should encourage people *not* to do things like >/dev/null 2>&1 || true in their jobs
[13:44] <Md> what about fsck prompts?
[13:44] <Keybuk> prompts are better handled in other ways