Processed: Re: Bug#743157: [Pkg-systemd-maintainers] Bug#743157: systemd: disables networking permanently during tried suspend
Processing commands for cont...@bugs.debian.org: severity 743157 important Bug #743157 [systemd] systemd: disables networking permanently during tried suspend Severity set to 'important' from 'serious' thanks Stopping processing here. Please contact me if you need assistance. -- 743157: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743157 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743157: [Pkg-systemd-maintainers] Bug#743157: systemd: disables networking permanently during tried suspend
severity 743157 important thanks Am 31.03.2014 15:50, schrieb Norbert Preining: Hi Michael, On Mon, 31 Mar 2014, Michael Biebl wrote: There is already a bug report for that, so cloning it wouldn't have been necessary. Ah, ok, sorry. Close it or merge it. What nmcli nm sleep false does is to wake it up by hand. Ok, will try it. There is a connection, yes. I can go into more detail, if you are interested (not sure, since you said you don't care). Ah, fine with me. If you know what it is and can fix it, that is fine with me. I've added a workaround to the network-manager package to not setup the systemd based sleep monitor when the system was not booted with systemd [0]. As a consequence, you should no longer run into the problem that NM remains in sleep mode with unmanaged devices after a suspend request when you run standalone logind. We might eventually fix logind to not send the PrepareForSleep signal in the first place when running standalone. But since this issue no longer breaks NM, I'm downgrading it from RC to important. Regards, Michael [0] http://anonscm.debian.org/gitweb/?p=pkg-utopia/network-manager.git;a=commitdiff;h=3b5d274bf03bffc800173d619def8b8e467d504c -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#743157: [Pkg-systemd-maintainers] Bug#743157: systemd: disables networking permanently during tried suspend
Am 31.03.2014 15:50, schrieb Norbert Preining: Hi Michael, On Mon, 31 Mar 2014, Michael Biebl wrote: There is already a bug report for that, so cloning it wouldn't have been necessary. Ah, ok, sorry. Close it or merge it. . What nmcli nm sleep false does is to wake it up by hand. Ok, will try it. There is a connection, yes. I can go into more detail, if you are interested (not sure, since you said you don't care). Ah, fine with me. If you know what it is and can fix it, that is fine with me. I think the way to address is, is to make systemd-logind not send out the Suspending D-Bus signal when there is no way the suspend request will be processed. My immediate idea was to stick a sd_booted() check into logind, but unfortunately it's not quite as simple. With systemd-shim around, such a suspend request can actually work for PID 1 != systemd as it would be handled by the systemd-shim process (which is D-Bus activated on-demand). So we probably need a different approach, like logind doing a D-Bus Ping to the org.freedesktop.systemd1 interface to see if there would be process handling the suspend/hibernate request. Thoughts? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#743157: [Pkg-systemd-maintainers] Bug#743157: systemd: disables networking permanently during tried suspend
Am 03.04.2014 16:03, schrieb Michael Biebl: I think the way to address is, is to make systemd-logind not send out the Suspending D-Bus signal when there is no way the suspend request will be processed. My immediate idea was to stick a sd_booted() check into logind, but unfortunately it's not quite as simple. With systemd-shim around, such a suspend request can actually work for PID 1 != systemd as it would be handled by the systemd-shim process (which is D-Bus activated on-demand). So we probably need a different approach, like logind doing a D-Bus Ping to the org.freedesktop.systemd1 interface to see if there would be process handling the suspend/hibernate request. If you look at org.freedesktop.login1.Manager's D-Bus interface, at least the following methods rely on systemd = PID1 (or systemd-shim): PowerOff Reboot Hibernate HybridSleep Suspend If those methods are called, logind in turn will try to activate the corresponding targets in systemd, like suspend.target, hibernate.target via org.freedesktop.systemd1.Manager StartUnit() See e.g. src/login/logind-dbus.c execute_shutdown_or_sleep() If we could enforce that either systemd-sysv or systemd-shim is installed, this would make things simpler, since we could assume org.freedesktop.systemd1.Manager to be present. (in case of systemd-sysv after a reboot, at least). -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#743157: [Pkg-systemd-maintainers] Bug#743157: systemd: disables networking permanently during tried suspend
Am 31.03.2014 03:31, schrieb Norbert Preining: Package: systemd Version: 204-8 Severity: serious Justification: breaks unrelated software Hi, running xfce4, latest sid, recent clean new install. suspend to ram via the xfce shutdown button works without any hunk. connected to power source I closed the lid of the laptop, with the following consequences: * suspend did not succeed * networking was completely broken - shown as disabled in the nm-applet, and could not be reenabled Does nmcli nm enable true help? The log messages indicate that this is a systemd bug, here are the messages starting from when the sleep was requested: Mar 31 10:21:03 wienerschnitzel NetworkManager[3382]: info sleep requested (sleeping: no enabled: yes) Mar 31 10:21:03 wienerschnitzel NetworkManager[3382]: info sleeping or disabling... Mar 31 10:21:03 wienerschnitzel NetworkManager[3382]: info (wlan0): device state change: activated - unmanaged (reason 'sleeping') [100 10 37] Mar 31 10:21:03 wienerschnitzel NetworkManager[3382]: info (wlan0): deactivating device (reason 'sleeping') [37] Mar 31 10:21:03 wienerschnitzel NetworkManager[3382]: info (wlan0): canceled DHCP transaction, DHCP client pid 10688 As you see, it is NetworkManager manager which disables the network interfaces whenever there is a suspend request, not systemd. Mar 31 10:21:20 wienerschnitzel dbus[3055]: [system] Activating service name='org.freedesktop.systemd1' (using servicehelper) Mar 31 10:21:20 wienerschnitzel dbus[3055]: [system] Activated service 'org.freedesktop.systemd1' failed: Launch helper exited with unknown return code 1 I assume you are not using systemd as PID 1 as the log message org.freedesktop.systemd1' failed indicates? This means you won't get a proper resume signal. NM listens to that resume signal and re-enables the network interfaces. Since it doesn't get that signal, it simply stays in disabled state. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#743157: [Pkg-systemd-maintainers] Bug#743157: systemd: disables networking permanently during tried suspend
Am 31.03.2014 11:29, schrieb Michael Biebl: Am 31.03.2014 03:31, schrieb Norbert Preining: Package: systemd Version: 204-8 Severity: serious Justification: breaks unrelated software Hi, running xfce4, latest sid, recent clean new install. suspend to ram via the xfce shutdown button works without any hunk. connected to power source I closed the lid of the laptop, with the following consequences: * suspend did not succeed * networking was completely broken - shown as disabled in the nm-applet, and could not be reenabled Does nmcli nm enable true help? Try that instead nmcli nm sleep false (as root) -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#743157: [Pkg-systemd-maintainers] Bug#743157: systemd: disables networking permanently during tried suspend
clone 743157 -1 reassign -1 network-manager thanks Hi Michael, Does nmcli nm enable true help? Try that instead nmcli nm sleep false (as root) I guess you mean to recreate working network? Will try later on. As you see, it is NetworkManager manager which disables the network interfaces whenever there is a suspend request, not systemd. Ok. I assume you are not using systemd as PID 1 as the log message org.freedesktop.systemd1' failed indicates? I guess, I don't know/care (I keep out of the init flame wars). I installed Debian two days ago from the daily netinst image ... This means you won't get a proper resume signal. NM listens to that resume signal and re-enables the network interfaces. Since it doesn't get that signal, it simply stays in disabled state. Umpf, but then this is a serious bug in NM, right? Cloned and reassigned. And, it was *NOT* the case on my old laptop, which had the *very*same* setup, besides it was older and had *no* trace of systemd hanging around (I on purppose kept it uninstalled!) So it seems that there is *some* connection with systemd. Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743157: [Pkg-systemd-maintainers] Bug#743157: systemd: disables networking permanently during tried suspend
Am 31.03.2014 15:34, schrieb Norbert Preining: clone 743157 -1 reassign -1 network-manager thanks There is already a bug report for that, so cloning it wouldn't have been necessary. Hi Michael, Does nmcli nm enable true help? Try that instead nmcli nm sleep false (as root) I guess you mean to recreate working network? See below. NM is in asleep state after receiving the Suspend signal and is never woken up again. What nmcli nm sleep false does is to wake it up by hand. Will try later on. As you see, it is NetworkManager manager which disables the network interfaces whenever there is a suspend request, not systemd. Ok. I assume you are not using systemd as PID 1 as the log message org.freedesktop.systemd1' failed indicates? I guess, I don't know/care (I keep out of the init flame wars). I installed Debian two days ago from the daily netinst image ... This means you won't get a proper resume signal. NM listens to that resume signal and re-enables the network interfaces. Since it doesn't get that signal, it simply stays in disabled state. Umpf, but then this is a serious bug in NM, right? Cloned and reassigned. And, it was *NOT* the case on my old laptop, which had the *very*same* setup, besides it was older and had *no* trace of systemd hanging around (I on purppose kept it uninstalled!) So it seems that there is *some* connection with systemd. There is a connection, yes. I can go into more detail, if you are interested (not sure, since you said you don't care). Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#743157: [Pkg-systemd-maintainers] Bug#743157: systemd: disables networking permanently during tried suspend
Hi Michael, On Mon, 31 Mar 2014, Michael Biebl wrote: There is already a bug report for that, so cloning it wouldn't have been necessary. Ah, ok, sorry. Close it or merge it. What nmcli nm sleep false does is to wake it up by hand. Ok, will try it. There is a connection, yes. I can go into more detail, if you are interested (not sure, since you said you don't care). Ah, fine with me. If you know what it is and can fix it, that is fine with me. Thanks Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
