[systemd-bugs] [Bug 90793] New: A hanging shell process remains after exiting rescue mode with suggested `systemctl default'

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Sun May 31 07:28:54 PDT 2015


https://bugs.freedesktop.org/show_bug.cgi?id=90793

            Bug ID: 90793
           Summary: A hanging shell process remains after exiting rescue
                    mode with suggested `systemctl default'
           Product: systemd
           Version: unspecified
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: general
          Assignee: systemd-bugs at lists.freedesktop.org
          Reporter: rootlexx at mail.ru
        QA Contact: systemd-bugs at lists.freedesktop.org

Created attachment 116188
  --> https://bugs.freedesktop.org/attachment.cgi?id=116188&action=edit
Interactive shell bash (618) strace output

When entering the rescue mode, the welcome message suggests using `systemctl
default' to enter default mode. However, though it indeed proceeds with normal
bootup, it results in a hanging interactive rescue shell process remaining,
grabbing the tty and thus preventing the login prompt from appearing. One has
to hit SAK to kill it.

The reason seems to be the KillMode=process directive used in rescue.service.
Here is its' status when active:

--------------------------------- >8 ---------------------------------
* rescue.service - Rescue Shell
   Loaded: loaded (/lib/systemd/system/rescue.service; static)
   Active: active (running) since Sun 2015-05-31 12:47:04 UTC; 3min 55s ago
     Docs: man:sulogin(8)
  Process: 614 ExecStartPre=/bin/echo -e Welcome to rescue mode! Type
"systemctl default" or ^D to enter default mode.\nType "journalctl -xb" to view
system logs. Type "systemctl reboot" to reboot. (code=exited, status=0/SUCCESS)
  Process: 609 ExecStartPre=/bin/plymouth quit (code=exited, status=1/FAILURE)
 Main PID: 617 (sh)
   CGroup: /system.slice/rescue.service
           |-617 /bin/sh -c /sbin/sulogin; /bin/systemctl --fail --no-block
default
           `-618 bash
--------------------------------- 8< ---------------------------------

/bin/sh (617) is the main process here, and the only one the termination signal
is sent to. The real interactive shell is the bash (618) process.

When one runs `systemctl default', it isolates default.target, stopping
rescue.service. /bin/sh (617) then recieves SIGHUP, but doesn't resend it to
its children. bash man page says:

 "The  shell  exits by default upon receipt of a SIGHUP.  Before exiting,
  an interactive shell  resends  the  SIGHUP  to  all  jobs,  running  or
  stopped."

/bin/sh (617) is not interactive, so this seems to be the reason for not
resending SIGHUP.

As a result, the interactive shell bash (618) remains stuck trying to read the
stdin (see the attached `bash (618) strace' file). Here is the status of
rescue.service at this point:

--------------------------------- >8 ---------------------------------
● rescue.service - Rescue Shell
   Loaded: loaded (/lib/systemd/system/rescue.service; static)
   Active: inactive (dead) since Sun 2015-05-31 12:53:55 UTC; 3min 25s ago
     Docs: man:sulogin(8)
  Process: 617 ExecStart=/bin/sh -c /sbin/sulogin; /bin/systemctl --fail
--no-block default (code=killed, signal=TERM)
  Process: 614 ExecStartPre=/bin/echo -e Welcome to rescue mode! Type
"systemctl default" or ^D to enter default mode.\nType "journalctl -xb" to view
system logs. Type "systemctl reboot" to reboot. (code=exited, status=0/SUCCESS)
  Process: 609 ExecStartPre=/bin/plymouth quit (code=exited, status=1/FAILURE)
 Main PID: 617 (code=killed, signal=TERM)
--------------------------------- 8< ---------------------------------

systemd-cgls output contains the following:

--------------------------------- >8 ---------------------------------
├─1 /sbin/init
├─system.slice
...
│ ├─rescue.service
│ │ └─618 bash
...
--------------------------------- 8< ---------------------------------

/bin/sh is dash (Debian default system shell), but I've tried bash, too, and it
behaved the same.

Exiting the rescue shell with `exit' or ^D instead of `systemctl default' works
fine.

I've tried copying rescue.service to /etc/systemd/system/ and commenting out
the KillMode=process directive, and it fixed the problem. (Moving
`/bin/systemctl --fail --no-block default' to ExecStopPost= and making
/sbin/sulogin the main process should help, too, but I didn't try it.)

emergency.service also contains KillMode=process, so it may be affected, too.

======================================================================
----------------------[ systemctl --version ]-------------------------
systemd 215
+PAM +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP
-APPARMOR

------------------------[ /etc/os-release ]---------------------------
PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
NAME="Debian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=debian
HOME_URL="http://www.debian.org/"
SUPPORT_URL="http://www.debian.org/support/"
BUG_REPORT_URL="https://bugs.debian.org/"

---------[ dpkg-query -Wf '${Package}\t${Version}\n' bash dash ]------
bash    4.3-11+b1
dash    0.5.7-4+b1

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-bugs/attachments/20150531/d9009905/attachment.html>


More information about the systemd-bugs mailing list