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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org