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