Bug 140257 - writing to /proc/acpi/sleep closes shell
writing to /proc/acpi/sleep closes shell
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2004-11-21 15:27 EST by Ben Liblit
Modified: 2015-01-04 17:12 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-12-27 22:12:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Linux Kernel 4532 None None None Never

  None (edit)
Description Ben Liblit 2004-11-21 15:27:02 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20040922 Epiphany/1.2.7

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

How reproducible:

Steps to Reproduce:
Two choices:
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.

Additional info:
Comment 1 Dave Jones 2005-04-16 00:51:04 EDT
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.

Thank you.
Comment 2 Ben Liblit 2005-04-17 20:20:48 EDT
The bug still occurs exactly as originally described using Fedora Core 3 and
Comment 3 Warren Togami 2005-04-17 22:57:38 EDT
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.
Comment 4 Ben Liblit 2005-04-22 18:47:36 EDT
I see no oops in dmesg after resume.

Among new dmesg output after resume, I do see the the following seemingly
input-related messages:

    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.
Comment 5 Ben Liblit 2005-04-22 18:55:32 EDT
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.
Comment 6 Warren Togami 2005-04-22 18:57:59 EDT
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.
Comment 7 Ben Liblit 2005-04-22 19:30:17 EDT
Reported to upstream Linux Kernel Bugzilla as requested:
Comment 8 Dave Jones 2005-07-15 14:48:32 EDT
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'.

Thank you.
Comment 9 Ben Liblit 2005-07-17 13:13:42 EDT
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
yet again.

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
X server.

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.
Comment 10 Dave Jones 2005-09-30 03:05:37 EDT
Mass update to all FC4 bugs:

An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel ( 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.

Comment 11 Ben Liblit 2005-10-06 19:33:29 EDT
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."
Comment 12 Dave Jones 2005-11-10 15:11:40 EST
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.

Thank you.
Comment 13 Dave Jones 2005-12-27 22:12:13 EST
Patch is merged in current updates. Assuming fixed.

Note You need to log in before you can comment on or make changes to this bug.