Red Hat Bugzilla – Bug 140257
writing to /proc/acpi/sleep closes shell
Last modified: 2015-01-04 17:12:47 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Description of problem:
With ACPI enabled, I can put my ThinkPad X24 laptop to sleep (S3) and
wake it back up again. However, if I used the very simple "echo 3
>/proc/acpi/sleep" technique to sleep, my root shell is closed by the
time the laptop resumes. It appears that several newlines and an EOF
are arriving on my pseudo-TTY from ... well ... from I have no idea where.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Log in to the text console as root. Or if you prefer, start a
terminal window and "su" to root.
2. Type "echo 3 >/proc/acpi/sleep".
3. Wake the computer back up.
Actual Results: If you had logged in to the text console as root, you
are no longer logged in. You're simply back to the "login:" prompt.
Furthermore, a NULL control character ("^@") is visible as though it
had been typed in at the "login:" prompt.
If you had used "su" to become root, your root shell is no longer
running. There are several blank lines below the "echo" command you
typed, and then several blank prompts in the shell from which you
typed "su". It appears as though the terminal window received (as
input) a number of newlines with an EOF stuck in the middle somewhere.
Expected Results: Sleeping and waking up should not generate any
"phantom" input. The shell that did the write should come back in
exactly the state we left it: still logged in, or still su'ed to root.
Fedora Core 2 has now reached end of life, and no further updates will be
provided by Red Hat. The Fedora legacy project will be producing further kernel
updates for security problems only.
If this bug has not been fixed in the latest Fedora Core 2 update kernel, please
try to reproduce it under Fedora Core 3, and reopen if necessary, changing the
product version accordingly.
The bug still occurs exactly as originally described using Fedora Core 3 and
After you resume, do you see any oops in dmesg?
Please search upstream bugzilla.kernel.org for anything similar, if nothing
exists file your own bug there and report here the URL.
I see no oops in dmesg after resume.
Among new dmesg output after resume, I do see the the following seemingly
atkbd.c: Unknown key pressed (translated set 2, code 0x63 on isa0060/serio0).
atkbd.c: Use 'setkeycodes 63 <keycode>' to make it known.
Not sure if that's relevant. In any case, no oops.
Although I see no oops, I do see kernel diagnostic output about a "sleeping
function called from invalid context". That issue has already been reported as
bug 140254. See
<https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140254#c2> for the
complete diagnostic output.
Note that this output includes syscall_call() which in turn calls sys_write().
Could this be the write system call being run by the "echo" command? Since
"echo" is a shell built-in, if hte kernel decided to kill the process doing the
write, that would actually kill the entire shell.
Warren, do you think bug 140254 is sufficient to explain the shell-closing
problem reported here? If so, we can mark this as a duplicate. If not, then
I'll go ahead and report this as a distinct issue in the upstream kernel
bugzilla as you originally requested.
Bug 140254 is not sufficient to explain this, because exactly that happens to me
on my IBM Thinkpad T41 and nothing happens to my shell after resume.
Reported to upstream Linux Kernel Bugzilla as requested:
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem. Please update to this new kernel, and
report whether or not it fixes your problem.
If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.
The problem still occurs using the latest 2.6.12-1.1398_FC4 kernel on my
ThinkPad X40. I do have a minor additional clue, though:
The shell only closes when using "zsh" as root's shell. If I change to "sh"
first, the shell does not close. However, the shell does react as though an
additional newline had been typed. I.e.:
sh-3.00# echo 3 >/proc/acpi/sleep
The second blank prompt there suggests that the shell thinks someone pressed
<Enter> again after the echo command.
At least once while testing this, though, the shell got into a bad loop where it
would wake up and almost immediately go back to sleep again. I could even see
extra "echo 3 >/proc/acpi/sleep" commands at the shell prompt each time. So
this time it was as though the shell were repeatedly seeing <Up> followed by
<Enter>, where <Up> was bringing the echo command back from the shell's command
history and <Enter> was running the command again.
The only way I could break out of this sleep loop was to race against the system
to close root's shell (<Control>-D) before the echo command could be received
Also, on just one occasion, when I pressed <Control> in order to start typing
<Control>-D, the terminal window displayed its popup menu as though I'd pressed
the right mouse button or perhaps some keycode which is mapped to <Menu> by the
This is all consistent with the general idea that junk is appearing in the input
stream. I guess different shells with different command line editing setups
react differently to that junk.
Mass update to all FC4 bugs:
An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel (188.8.131.52). As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.
Please retest with this update, and update this bug if necessary.
Bug still manifests as originally described. However, the good news is that the
upstream kernel bug (http://bugzilla.kernel.org/show_bug.cgi?id=4532) is marked
RESOLVED/CODE_FIX, meaning that "A patch has been created and is awaiting
approval by the appropriate kernel maintainer or Linus Torvalds."
2.6.14-1.1637_FC4 has been released as an update for FC4.
Please retest with this update, as a large amount of code has been changed in
this release, which may have fixed your problem.
Patch is merged in current updates. Assuming fixed.