Bug#792761: UX issue, handling of endless shutdown loops
Control: close -1 On Mon, 27 Jul 2015 21:27:23 +0200 Eduard Bloch wrote: > On Mon, 20 Jul 2015 10:13:25 -0300 Felipe Sateler wrote: > > > >> I'm afraid 2 is really an upstream issue and not an integration issue. > > >> Could you please file that bug upstream? > > > > > > Maybe... I will give it a try tonight. However I am sceptical regarding > > > "productive" communication with upstream. > > > > Great, let us know when you have filed a bug upstream. > > https://github.com/systemd/systemd/issues/633^ > > > > Says that it cannot find an id. Checked: > > > > > > $ sudo journalctl --list-boots > > > -1 39f59f8ebdd644f39aeb46b67eef9bff Sa 2015-07-18 09:12:05 CEST—Mo 2015-07-20 08 > > > 0 39f59f8ebdd644f39aeb46b67eef9bff Mo 2015-07-20 08:39:43 CEST—Mo 2015-07-20 08 > > > > > > No idea what happened to the logs. > > > > Do you have persistent logging enabled? I think you do not. Please > > follow the instructions of the README.Debian if you want to enable it. > > Done, waiting for repro situation... It's been 9 years without a follow-up, so assuming the issue was solved elsewhere, closing. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#792761: UX issue, handling of endless shutdown loops
On Mon, 20 Jul 2015 10:13:25 -0300 Felipe Sateler fsate...@debian.org wrote: I'm afraid 2 is really an upstream issue and not an integration issue. Could you please file that bug upstream? Maybe... I will give it a try tonight. However I am sceptical regarding productive communication with upstream. Great, let us know when you have filed a bug upstream. https://github.com/systemd/systemd/issues/633^ Says that it cannot find an id. Checked: $ sudo journalctl --list-boots -1 39f59f8ebdd644f39aeb46b67eef9bff Sa 2015-07-18 09:12:05 CESTâMo 2015-07-20 08 0 39f59f8ebdd644f39aeb46b67eef9bff Mo 2015-07-20 08:39:43 CESTâMo 2015-07-20 08 No idea what happened to the logs. Do you have persistent logging enabled? I think you do not. Please follow the instructions of the README.Debian if you want to enable it. Done, waiting for repro situation... Regards, Eduard. -- xTs rpm? Waren das nicht verwunschene debs? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#792761: UX issue, handling of endless shutdown loops
Hallo, * Felipe Sateler [Sun, Jul 19 2015, 03:14:11PM]: Control: tags -1 moreinfo Hi Eduard, On 18 July 2015 at 05:24, Eduard Bloch e...@gmx.de wrote: 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. So, we have 2 issues: 1. Your system is not shutting down 2. Systemd is not telling you enough to discover what is wrong. I'm afraid 2 is really an upstream issue and not an integration issue. Could you please file that bug upstream? Maybe... I will give it a try tonight. However I am sceptical regarding productive communication with upstream. We can try to help debug number 1, though, and there may be a real integration bug. Please see the shutdown section in the upstream wiki[1]; in particular, starting the debug shell before shutting down The thing is, the issue is not reproducible. It might happen once a month, and then not appear for many months. And you don't want to enable all the debug machinery all the just in case. The thing needed is the minimum control mechanism in place just when the problem occurs. And when it happens for the first time, it's too late to active the debug shell. and switching to it when the shutdown hangs should let you query the journal to find out issues. Note that if you enabled persistent journal logging you can maybe still get the info from the journal: journalctl -b -number of boots since the last hang Says that it cannot find an id. Checked: $ sudo journalctl --list-boots -1 39f59f8ebdd644f39aeb46b67eef9bff Sa 2015-07-18 09:12:05 CEST—Mo 2015-07-20 08 0 39f59f8ebdd644f39aeb46b67eef9bff Mo 2015-07-20 08:39:43 CEST—Mo 2015-07-20 08 No idea what happened to the logs. Regards, Eduard. [1] http://freedesktop.org/wiki/Software/systemd/Debugging/ -- Saludos, Felipe Sateler -- Die letzte Stimme, die man hört, bevor die Welt explodiert, wird die Stimme eines Experten sein, der sagt: 'Das ist technisch unmöglich!' -- Sir Peter Ustinov -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#792761: UX issue, handling of endless shutdown loops
On 20 July 2015 at 03:48, Eduard Bloch e...@gmx.de wrote: Hallo, * Felipe Sateler [Sun, Jul 19 2015, 03:14:11PM]: So, we have 2 issues: 1. Your system is not shutting down 2. Systemd is not telling you enough to discover what is wrong. I'm afraid 2 is really an upstream issue and not an integration issue. Could you please file that bug upstream? Maybe... I will give it a try tonight. However I am sceptical regarding productive communication with upstream. Great, let us know when you have filed a bug upstream. We can try to help debug number 1, though, and there may be a real integration bug. Please see the shutdown section in the upstream wiki[1]; in particular, starting the debug shell before shutting down The thing is, the issue is not reproducible. It might happen once a month, and then not appear for many months. And you don't want to enable all the debug machinery all the just in case. The thing needed is the minimum control mechanism in place just when the problem occurs. And when it happens for the first time, it's too late to active the debug shell. You can enable debug-shell.service, so that when it happens, you have the shell on tty9. I don't know if this can be started up on demand (specially if it is that late in the shutdown sequence). and switching to it when the shutdown hangs should let you query the journal to find out issues. Note that if you enabled persistent journal logging you can maybe still get the info from the journal: journalctl -b -number of boots since the last hang Says that it cannot find an id. Checked: $ sudo journalctl --list-boots -1 39f59f8ebdd644f39aeb46b67eef9bff Sa 2015-07-18 09:12:05 CEST—Mo 2015-07-20 08 0 39f59f8ebdd644f39aeb46b67eef9bff Mo 2015-07-20 08:39:43 CEST—Mo 2015-07-20 08 No idea what happened to the logs. Do you have persistent logging enabled? I think you do not. Please follow the instructions of the README.Debian if you want to enable it. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#792761: UX issue, handling of endless shutdown loops
Control: tags -1 moreinfo Hi Eduard, On 18 July 2015 at 05:24, Eduard Bloch e...@gmx.de wrote: 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. So, we have 2 issues: 1. Your system is not shutting down 2. Systemd is not telling you enough to discover what is wrong. I'm afraid 2 is really an upstream issue and not an integration issue. Could you please file that bug upstream? We can try to help debug number 1, though, and there may be a real integration bug. Please see the shutdown section in the upstream wiki[1]; in particular, starting the debug shell before shutting down and switching to it when the shutdown hangs should let you query the journal to find out issues. Note that if you enabled persistent journal logging you can maybe still get the info from the journal: journalctl -b -number of boots since the last hang [1] http://freedesktop.org/wiki/Software/systemd/Debugging/ -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#792761: UX issue, handling of endless shutdown loops
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 libapparmor12.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 libkmod220-1 ii liblzma55.1.1alpha+20120614-2.1 ii libmount1 2.26.2-6 ii libpam0g1.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 udev222-1 ii util-linux 2.26.2-6 Versions of packages systemd recommends: ii dbus1.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
