If one creates an alternate init state (say state 5 ("windows")) and change from the default state to the windows state the state change "hangs" waiting for console input. Reproducible: Always Steps to Reproduce: 1.Create an alternate state (e.g. a windows directory in /etc/runlevels) and configure it like the default state with additional init files, e.g. cupsd, hplip, speechd, xdm (or gdm). (xdm is probably sufficient). These additional init files should not be present in the default runlevel directory. 2. Modify /etc/inittab such that one has "l5:5:wait:/sbin/rc windows" 3. /sbin/telinit 5 Actual Results: System fails to change state. If one is on the console (tty1), one discovers that the tty modes have changed (noecho). One fails to see the "OK" messages indicating that the additional programs are started *unless* one hits return multiple times on the console. There seems to roughly be a one-to-one correlation, e.g. each return results in one package being started and one OK message appearing. A "stty sane" is required to return tty1 to "normal". Expected Results: Init managed programs should start/stop normally without changing the console tty settings or requiring input from the console. I believe this is a bug in the Gentoo message system involving the console messages displayed when programs are started/stopped via init state changes.
Robert, if you are still reading this bug, I have a couple of questions. - Is this an issue still with OpenRC-0.20.4? - Why not use "openrc windows" to switch the runlevel? If you use that, does it still have the same issue?
I'm was testing this, and I think that it is not a OpenRC bug. Init and telinit, by default send its output to tty, if you run telinit windows in outside a tty you can't see output, you should switch to tty1 for example to view all messages.