Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 372551 - sys-apps/openrc: rc.c:read_key() hangs waiting for input at Interactive? prompt (termios problem)
Summary: sys-apps/openrc: rc.c:read_key() hangs waiting for input at Interactive? prom...
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: OpenRC (show other bugs)
Hardware: All Linux
: Normal critical (vote)
Assignee: OpenRC Team
Depends on:
Reported: 2011-06-22 08:44 UTC by Chris Wilson
Modified: 2012-02-15 12:49 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Chris Wilson 2011-06-22 08:44:45 UTC
System does not boot completely (not even enough to start sshd) after upgrade to latest baselayout (from a very old system) and openrc 0.8.2.

Strace shows that "rc default" is blocked on read(0). I built a version of rc with debugging symbols, and a backtrace on the running rc shows it's waiting on read() in read_key(false).

The termios are set for nonblocking, I checked the VSIZE and VMIN values in termios.c_cc and both are zero, but it still blocks. Pressing a key at the console allows the next service to start, and then it blocks again. So the system won't boot without hand-holding.

I added a (missing) check for an error return fromn tcsetattr in rc.c:234, but that's not the problem. read() is simply ignoring the termios. I don't understand why that might be - kernel bug? glibc bug? Mismatched headers? Some other process changing the terminal settings?

I added a "return 0" in non-blocking mode and the system now boots, but of course I have to be super careful to put the hack back in if I ever upgrade openrc again.

This is a custom kernel with vserver support, and "too old for udev/hotplug" apparently. with vserver patch

Reproducible: Always

Steps to Reproduce:
1. Boot system
2. Wait until you get bored waiting for service to start
3. Switch to another console (that you prepared earlier), log in and strace rc, see that it's hung on read()
4. Press a key and watch boot continue
Actual Results:  
Boot hangs waiting for a keypress

Expected Results:  
System should boot unattended
Comment 1 Duane Griffin 2012-02-15 12:05:19 UTC
I am seeing the same bug here.

Some more information:
1) I am NOT running vserver, just a standard bare-metal install.
2) I am running an up-to-date custom-compiled vanilla kernel (3.2.4).
3) I am using dracut with root on LVM.
4) The bug only shows up with rc_interactive="YES".
5) CONFIG_DEVTMPFS is enabled in my kernel (the CONFIG_DEVTMPFS_MOUNT setting doesn't make a difference, as expected when booting from an initramfs).