| 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) | 01:17 |
|---|---|---|
| Keybuk | Md: "the multiple consoles problem" ? | 11:11 |
| Md | Keybuk: in practice you cannot use at the same time a serial console and a normal monitor | 11:19 |
| 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:20 |
| Keybuk | well, you'll still have the basic problem that the kernel only recognises one console at a time | 11:24 |
| 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:16 |
| keesj | mu upstart "service_console" does some cat /proc/cmdline magic to reuse the same serial as given | 12:17 |
| Keybuk | keesj: how do you mean? | 12:28 |
| 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:32 |
| Keybuk | upstart doesn't "listen for input" ? | 12:36 |
| Md | Keybuk: think about single user mode, when there is no getty | 12:37 |
| Keybuk | Md: yes, but getty can only be attached to one pty at a time | 13:08 |
| 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:09 |
| 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:24 |
| Keybuk | I'm clearly not following ;) | 13:29 |
| 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:30 |
| Keybuk | right | 13:31 |
| 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:32 |
| 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:33 |
| Keybuk | multiplexing ptys is not a simple job | 13:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| Keybuk | oh, I fully plan to get rid of those ;) | 13:41 |
| Keybuk | they shouldn't be on the console anyway unless !quiet | 13:41 |
| 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:42 |
| 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:43 |
| 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 | 13:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!