Bug#792761: UX issue, handling of endless shutdown loops

[Eduard Bloch]

Package: systemd
Version: 222-1
Severity: normal

Hello systemd maintainers,

foreword for systemd hatters:
I want this problem to be fixed IN systemd and not by removing systemd.
Move along, those are not the droids you are looking for.

There is a thing in systemd that bothers me (and has for a while) and it
looks like upstream is not moving to fix this. I say BUG and FIX because
this is not cosmetics (i.e. a minor user experience issue), the UX might
affect how the user acts in order to solve the problem and eventually
loose/damage his data because of this problem.

What happens is, sometimes systemd gets into an endless loop at the
shutdown. Right when the devices are unmounted, in the most vulnerable
moment. And then this BS happens, see
https://www.unix-ag.uni-kl.de/~bloch/part2.m4v .

Obvious questions and events so far (and during/after the video):

 - what does it wait for?
 - why don't you let me see any useful detail of that running tasks?
 - why do I have to wait for 90s and then it tells me: HA HA, now you
   wait another two minutes.
 - And when I waited another two minutes, again, HA HA, wait until 4:36...
 - or maybe until "no limit" which is blinking again and again? Waiting
   forever? Are you kidding me?
 - ok, I was pissed now and pressed Ctrl-Alt-Del, expecting it to do
   something useful. Now it showed me some
   Stopped... messages and then immediately three "Starting..."
   messages. And huh... Starting? Starting something? I am trying to
   shutdown, why do you restart some sh.. instead?
 - Now I have enough of that sh... and use Magic-SysRQ sequence to sync
   and reboot.

I see some room for improvement:
 - give the user usable information in this case!
 - AND/OR tell the user how to retrieve more information. Maybe there is
   some "secret" shortcut to dump information (I haven't checked the
   docs yet but I expect upstream to be sane enough to have implemented
   a such thing) but that infomration needs to be revealed NOW. Having
   it in some wiki on the internet does not help.
 - give the user a way to interrupt this. I guess it's either a systemd
   bug (closed depedency loop?) or one of the outstanding tasks is
   blocked for some reason (might be a kernel driver issue with
   devmapper) but in any case, I want to be able to investigate and
   apply the most harmless fix (kill or ignore the hanging task). Right
   now I just feel stupid and it's not my fault.

Best regards,
Eduard.

-- Package-specific info:

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.1.2+ (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages systemd depends on:
ii  adduser         3.113+nmu3
ii  libacl1         2.2.52-2
ii  libapparmor1    2.9.2-3
ii  libaudit1       1:2.4.2-1
ii  libblkid1       2.26.2-6
ii  libc6           2.19-19
ii  libcap2         1:2.24-9
ii  libcap2-bin     1:2.24-9
ii  libcryptsetup4  2:1.6.6-5
ii  libgcrypt20     1.6.3-2
ii  libkmod2        20-1
ii  liblzma5        5.1.1alpha+20120614-2.1
ii  libmount1       2.26.2-6
ii  libpam0g        1.1.8-3.1
ii  libseccomp2     2.2.1-2
ii  libselinux1     2.3-2+b1
ii  libsystemd0     222-1
ii  mount           2.26.2-6
ii  sysv-rc         2.88dsf-59.2
ii  udev            222-1
ii  util-linux      2.26.2-6

Versions of packages systemd recommends:
ii  dbus            1.8.18-1
ii  libpam-systemd  222-1

Versions of packages systemd suggests:
pn  systemd-ui  <none>

-- no debconf information

-- 
Geschichte handelt fast nur von schlechten Menschen, die später
gutgesprochen worden sind.
		-- Friedrich Wilhelm Nietzsche