Bug 372551

Summary:	sys-apps/openrc: rc.c:read_key() hangs waiting for input at Interactive? prompt (termios problem)
Product:	Gentoo Hosted Projects	Reporter:	Chris Wilson <chris+gentoo>
Component:	OpenRC	Assignee:	OpenRC Team <openrc>
Status:	UNCONFIRMED ---
Severity:	critical	CC:	chris+gentoo, duaneg
Priority:	Normal
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---

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. 2.6.22.19 with vserver patch 2.2.0.7.

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).