The kernel can handle multiple console (via kernel cmdline "console=ttyS0 console=tty0") while OpenRC doesn't. OpenRC always uses /dev/console only - thus only the last one specified in the kernel cmdline will be used. I think we should add support for multiple consoles.
I've recently run into this and it makes keeping both a serial console and kvm rather hard to reconcile. Not seeing the entirety of the openrc boot on kvm because it's all going out over serial can be pretty scary (not to mention it being a pita for when I don't physically have a serial cable hooked to a machine with a ttyS0 console). It'd be quite nice if this "feature," which the lack of is a bug, were added.
i would say this is correct behavior. it's how it has always worked, and from what i've seen of other init systems, they all behave this way as well. i'm pretty sure what you're talking about is non-trivial. when openrc runs an init.d script, it's reading/writing to stdout/stderr -- a single fd. but what you're asking for is openrc to transparently insert itself into the pipeline so that it broadcasts all output to an arbitrary number of fd's. further, we can only have 1 ctty. so while we could in theory output to multiple consoles, only one of those would be able to interact with openrc in terms of the ctty. and for stdin, we'd also have to change all the call points to select() on an arbitrary number of inputs (and then broadcast the result to all the others ?). so while it might seem like a nifty idea at first blush, i don't think the implementation requirements justify it.
(In reply to comment #2) > i would say this is correct behavior. it's how it has always worked, and from > what i've seen of other init systems, they all behave this way as well. ... > so while it might seem like a nifty idea at first blush, i don't think the > implementation requirements justify it. Agreed; I am closing this as wontfix.
