[opensuse-factory] Your thoughts on dropping pm-utils
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I maintain pm-utils, and I want to drop them soon, because systemd can handle (sort of) suspend and hibernation and also becouse their upstream is dead and I'm not able to (and don't want to) fix all the bugs all by myself. There is some information and an initial discussion on the topic here: https://bugzilla.novell.com/show_bug.cgi?id=790157 The current state is that pm-utils are sort of "plugged in" to systemd and are called from systemd to perform suspend and hibernate, if they are installed. Doesn't work too well. So I'm interested in other people's opinions on how this should be done and in particular what hooks you would like to see rewritten as systemd units, since I can usually do that. IMO the most important hook is 99Zgrub that prevents to boot another OS if we have hibernated, I've already rewritten that one, if someone wants to look at it or test it (just put it in /usr/lib/systemd/system-sleep, hibernate without pm-utils and see if the grub menu appears when you turn the computer on - it shouldn't) , here's the link: http://bugzillafiles.novell.org/attachment.cgi?id=569356 I just modified it at the end, so it works as a systemd unit, but all the functions are the same as in 99ZGrub from pm-utils. I also think it would be nice to have a "transitional period", when pm-utils won't be used as default, but if someone would be unhappy with using systemd for suspending, pm-utils could be installed. So please share your thoughts on this. I also realize there are people who would like to keep pm-utils, but unfortunately I'm not able to fix those bugs any more, so if someone wants to disagree with dropping pm-utils, that person would have to become the maintainer and fix all the bugs (or find someone else to do it), because I can't and don't want to, thanks for understanding. Wojtek Dziewięcki -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSlhzWAAoJEHrcxBn8c1xjNVMH/2qvaIUSxUz/wtCBPqSmhlv9 nJXyrst1/eM3WMA2cGt6+8DjpeNDq19Fs2j19H/WH4l1MPCyvW6R8b2UKwb++fPt RDJd4T6vKBaK46hzL6DNdigwf7JtSFJB7B69ohN85fNoSNyrzIzVtnQA0Cl5QGU8 SStmp0vy8n67WXKkOerszmpOqdpomUu+GPdy4OCcjbK2Z6VLnwBVGnFw4IcTNw2N Wu2U/Iplyt1e7mpueNOxFCQr3qJePlyqbHLeLRYi3ROshJiJycx/siyD8yB7WGa6 UmKHPj5a+Q2yZ2T9/gzZm5OmQscfum/jgPV+B4Uh53BudnW2wm75xPSuOQOyaQI= =b39f -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, * Vojtěch Dziewięcki <vdziewiecki@suse.cz> [2013-11-27 17:25]:
I maintain pm-utils, and I want to drop them soon, because systemd can handle (sort of) suspend and hibernation and also becouse their upstream is dead and I'm not able to (and don't want to) fix all the bugs all by myself.
that's a reasonable position.
There is some information and an initial discussion on the topic here: https://bugzilla.novell.com/show_bug.cgi?id=790157
The current state is that pm-utils are sort of "plugged in" to systemd and are called from systemd to perform suspend and hibernate, if they are installed. Doesn't work too well.
So I'm interested in other people's opinions on how this should be done and in particular what hooks you would like to see rewritten as systemd units, since I can usually do that.
IMO the most important hook is 99Zgrub that prevents to boot another OS if we have hibernated, I've already rewritten that one, if someone wants to look at it or test it (just put it in /usr/lib/systemd/system-sleep, hibernate without pm-utils and see if the grub menu appears when you turn the computer on - it shouldn't) , here's the link: http://bugzillafiles.novell.org/attachment.cgi?id=569356 I just modified it at the end, so it works as a systemd unit, but all the functions are the same as in 99ZGrub from pm-utils.
I also think it would be nice to have a "transitional period", when pm-utils won't be used as default, but if someone would be unhappy with using systemd for suspending, pm-utils could be installed.
So please share your thoughts on this.
I also realize there are people who would like to keep pm-utils, but unfortunately I'm not able to fix those bugs any more, so if someone wants to disagree with dropping pm-utils, that person would have to become the maintainer and fix all the bugs (or find someone else to do it), because I can't and don't want to, thanks for understanding.
I don't think the problem is not so much the emotional attachment people have to pm-utils (at least I hope so ;) but the potential of severe regressions with suspend/hibernate. The hardware quirks db probably doesn't matter that much any more since it is outdated by now. But what about the other non-quirk hooks apart from grub in /usr/lib/pm-utils/sleep.d/, have you evaluated which ones are still needed, e.g. does systemd do the checks in s2disk-check? Will it properly restart the networking for interfaces not managed by NM, will other networking services be stopped and restarted properly, will it save/restore the hardware clock etc.? Much of that seems still applicable unless systemd has equivalents. In addtition there are third-party packages delivering hooks to pm-utils such as storage-fixup which I rely on to prevent my HDD to commit suicide and there may be consumers with undeclared dependencies making use of the tools delivered by pm-utils (e.g making decisions based on /usr/bin/on_ac_power). So before removing it please grep over an extracted factory tree for the use of /usr/bin/on_ac_power /usr/bin/pm-is-supported /usr/bin/powersave and /usr/lib/pm-utils/sleep.d/ -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2013-11-28 10:59, Guido Berhoerster wrote:
I don't think the problem is not so much the emotional attachment people have to pm-utils (at least I hope so ;) but the potential of severe regressions with suspend/hibernate. The hardware quirks db probably doesn't matter that much any more since it is outdated by now.
I accidentally removed pm-utils some time ago and the machine failed to hibernate. I don't remember the exact cause, and I haven't tested 13.1 on this machine yet - but I expect problems. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)
"Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2013-11-28 10:59, Guido Berhoerster wrote:
I don't think the problem is not so much the emotional attachment people have to pm-utils (at least I hope so ;) but the potential of severe regressions with suspend/hibernate. The hardware quirks db probably doesn't matter that much any more since it is outdated by now.
I accidentally removed pm-utils some time ago and the machine failed to hibernate. I don't remember the exact cause, and I haven't tested 13.1 on this machine yet - but I expect problems.
I read the long bugzilla and I gather in 12.3 systemd ended up calling pm-utils, but it was a clumsy, error prone process? No idea how it is done in 13.1. My laptop does hibernate with 13.1. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le jeudi 28 novembre 2013 à 09:06 -0500, Greg Freemyer a écrit :
"Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2013-11-28 10:59, Guido Berhoerster wrote:
I don't think the problem is not so much the emotional attachment people have to pm-utils (at least I hope so ;) but the potential of severe regressions with suspend/hibernate. The hardware quirks db probably doesn't matter that much any more since it is outdated by now.
I accidentally removed pm-utils some time ago and the machine failed to hibernate. I don't remember the exact cause, and I haven't tested 13.1 on this machine yet - but I expect problems.
I read the long bugzilla and I gather in 12.3 systemd ended up calling pm-utils, but it was a clumsy, error prone process?
No idea how it is done in 13.1. My laptop does hibernate with 13.1.
Nothing changed in that regard in 13.1. If pm-utils is installed, it will be called by logind. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 28/11/13 06:59, Guido Berhoerster escribió:
The hardware quirks db probably doesn't matter that much any more since it is outdated by now.
I removed several of the hardware quirks after some research that indicated that the problems were already fixed in the kernel. I did not checked everything but it is likely there are more things that need to be disabled, some might be using ancient userspace components nowhere to be found or workaround ancient kernel versions..
But what about the other non-quirk hooks apart from grub in /usr/lib/pm-utils/sleep.d/, have you evaluated which ones are still needed,
I converted the remaining sleep.d snippets from packages a while ago, an example is the "at" daemon, which I believe has a bug that is being worked around by restarting the service on system resume, this is of course extremely ugly and it might be better to fix the daemon instead. e.g. does systemd do the checks in s2disk-check? No, systemd does suspend/hibernate only using the interfaces the linux kernel provides.
Will it properly restart the networking for interfaces not managed by NM, will other networking services be stopped and restarted properly,
No idea if the if-up scripts can or should react to system resume.
will it save/restore the hardware clock etc.?
The kernel takes care of the RTC suspend/resume. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2013-11-28 15:55, Cristian Rodríguez wrote:
El 28/11/13 06:59, Guido Berhoerster escribió:
Will it properly restart the networking for interfaces not managed by NM, will other networking services be stopped and restarted properly,
No idea if the if-up scripts can or should react to system resume.
At least to force renew dhcp. A laptop can awake on a different network. Some cards have to be reloaded.
will it save/restore the hardware clock etc.?
The kernel takes care of the RTC suspend/resume.
ntp has to be restarted. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)
El 28/11/13 12:09, Carlos E. R. escribió:
On 2013-11-28 15:55, Cristian Rodríguez wrote:
El 28/11/13 06:59, Guido Berhoerster escribió:
Will it properly restart the networking for interfaces not managed by NM, will other networking services be stopped and restarted properly,
No idea if the if-up scripts can or should react to system resume.
At least to force renew dhcp. A laptop can awake on a different network.
Yes.
Some cards have to be reloaded.
if by that you mean network cards need the driver to be reloaded, please file a bug report against the kernel indicating what driver has this problem.
will it save/restore the hardware clock etc.?
The kernel takes care of the RTC suspend/resume.
ntp has to be restarted.
And what happens if ntp is not restarted inmediately after resume? looks like a bug, is there a bug report about that? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-11-28 16:21, Cristian Rodríguez wrote:
El 28/11/13 12:09, Carlos E. R. escribió:
Some cards have to be reloaded.
if by that you mean network cards need the driver to be reloaded, please file a bug report against the kernel indicating what driver has this problem.
AFAIK, I don't have such a card, so I can't write that bugzilla. Ask the wifi experts.
will it save/restore the hardware clock etc.?
The kernel takes care of the RTC suspend/resume.
ntp has to be restarted.
And what happens if ntp is not restarted inmediately after resume? looks like a bug, is there a bug report about that?
No idea if there is a bug report. I'm sure it is working as designed, time servers should not be ever powered off, after all. Hibernating is not the proper thing to do in that scenario - it is a different scenario. On restore from hibernation it just tries to keep sync with previous time servers, but the clock is no longer in exact sync. It the difference is large it can take many hours to sync again, or even abort and exit. A restart ensures that you get the right pool of servers, that it does a step sync, then starts the daemon. If you think this is a bug, _you_ talk with the ntp designers, not me (most likely I would agree with them). Another example: dovecot. It strongly dislikes clock changes, it can crash on them. It prints warning and errors after hibernation:
<2.4> 2013-11-28 14:00:09 Telcontar dovecot - - - imap: Warning: Time jumped forwards 28271 seconds <2.4> 2013-11-28 14:00:09 Telcontar dovecot - - - imap: Warning: Time jumped forwards 28407 seconds <2.4> 2013-11-28 14:00:09 Telcontar dovecot - - - imap: Warning: Time jumped forwards 30034 seconds
There are many things that can break without pm-utils. If they are going to be dropped and replaced, you devs have to investigate more. - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKXdGYACgkQtTMYHG2NR9XWpwCfQvQPTK9/eHrvHGI2aXGo+H4h W7UAnjJW2KJ7lez2vIFFznC34OvrL0wN =wvUF -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Nov 28, Carlos E. R. wrote:
And what happens if ntp is not restarted inmediately after resume? looks like a bug, is there a bug report about that?
No idea if there is a bug report. I'm sure it is working as designed, time servers should not be ever powered off, after all. Hibernating is not the proper thing to do in that scenario - it is a different scenario.
The ntpd running on systems doing suspend/resume is more a client than a server. And even an upstream server will probably go down for maintenence. So there must be ways to recover from hickups.
On restore from hibernation it just tries to keep sync with previous time servers, but the clock is no longer in exact sync. It the difference is large it can take many hours to sync again, or even abort and exit. A restart ensures that you get the right pool of servers, that it does a step sync, then starts the daemon.
Since on resume the time is kind of undefined, and in addition an unavoidable timejump happens anyway. it would be good if the systemtime would at least be forced to be correct by restarting ntpd and letting it grab time from remote. Like you said.
Another example: dovecot. It strongly dislikes clock changes, it can crash on them. It prints warning and errors after hibernation:
<2.4> 2013-11-28 14:00:09 Telcontar dovecot - - - imap: Warning: Time jumped forwards 28271 seconds <2.4> 2013-11-28 14:00:09 Telcontar dovecot - - - imap: Warning: Time jumped forwards 28407 seconds <2.4> 2013-11-28 14:00:09 Telcontar dovecot - - - imap: Warning: Time jumped forwards 30034 seconds
Thats likely a wrong expectation of dovecot. If the logs above really come from suspend/resume cycles it just tells that its not suspend/resume aware. Perhaps the wrappers around suspend/resume can stop and start the service to work around this shortcoming within dovecot. Olaf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-11-28 16:21, Cristian Rodríguez wrote:
El 28/11/13 12:09, Carlos E. R. escribió:
Some cards have to be reloaded.
if by that you mean network cards need the driver to be reloaded, please file a bug report against the kernel indicating what driver has this problem.
AFAIK, I don't have such a card, so I can't write that bugzilla. Ask the wifi experts.
On my laptop, the wlan interface does occasionally go into a permanent sleep mode, which requires me to unload and reload the driver module. -- Per Jessen, Zürich (-0.1°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 28/11/13 14:35, Per Jessen escribió:
On my laptop, the wlan interface does occasionally go into a permanent sleep mode, which requires me to unload and reload the driver module.
Please file a bug report against the kernel..that should never happen.. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 28 Nov 2013 18:42, Cristian Rodríguez <crrodriguez@...> wrote:
El 28/11/13 14:35, Per Jessen escribió:
On my laptop, the wlan interface does occasionally go into a permanent sleep mode, which requires me to unload and reload the driver module.
Please file a bug report against the kernel..that should never happen..
And, please, add if you are using "NetworkManager" and if, which version. That could also be the cause. - Yamaban.
El 28/11/13 14:49, Yamaban escribió:
On Thu, 28 Nov 2013 18:42, Cristian Rodríguez <crrodriguez@...> wrote:
El 28/11/13 14:35, Per Jessen escribió:
On my laptop, the wlan interface does occasionally go into a permanent sleep mode, which requires me to unload and reload the driver module.
Please file a bug report against the kernel..that should never happen..
And, please, add if you are using "NetworkManager" and if, which version. That could also be the cause.
Networkmanager only gets notified of suspend/resume so it can set the interface up or down.. that is quite different than having to reload the kernel module to get the device to appear again. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 2013-11-28 at 15:20 -0300, Cristian Rodríguez wrote:
El 28/11/13 14:49, Yamaban escribió:
And, please, add if you are using "NetworkManager" and if, which version. That could also be the cause.
Networkmanager only gets notified of suspend/resume so it can set the interface up or down.. that is quite different than having to reload the kernel module to get the device to appear again.
It also needs to do stuff like reinit GSM modules. Regards Oliver -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Cristian Rodríguez wrote:
El 28/11/13 14:35, Per Jessen escribió:
On my laptop, the wlan interface does occasionally go into a permanent sleep mode, which requires me to unload and reload the driver module.
Please file a bug report against the kernel..that should never happen..
Willdo. -- Per Jessen, Zürich (0.3°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 28 Nov 2013 15:55, Cristian Rodríguez <crrodriguez@...> wrote:
El 28/11/13 06:59, Guido Berhoerster escribió: [snip] e.g. does systemd do the checks in s2disk-check?
No, systemd does suspend/hibernate only using the interfaces the linux kernel provides.
Let's have a look beyond our soup-dish: - Redhat / Fedora are (mostly) in the same situation, it would be good to do some checking / asking how they handle this. - Debian (AFAIK) do stil stay on SysVinit -- how do they handle suspend / hibernate? - Ubuntu: Debian + Upstart -- no knowledge on my side. - Arch: BYOS, but in the end: same point. IMHO inter-distro dialog is needed to get a long-term solution, that does not re-invent the wheel a dozen times.
Will it properly restart the networking for interfaces not managed by NM, will other networking services be stopped and restarted properly,
No idea if the if-up scripts can or should react to system resume.
For me NM is a no-go, thus I need the 'classic way' (if-up/-down) A down/up or unplug/plug or reconnect cycle is needed in most environments and situations (dhcp, changed location, etc). "Static Address" is a dwindeling number, and in some cases (hw) wireless even needs a full hw/driver re-init. No easy situation to detect. IMO restart the networking (fully) is the easiest way, or stop network before suspend/hibernate and start after wakeup/thaw. - both ways work-for-me. - Yamaban.
Am 28.11.2013 15:55, schrieb Cristian Rodríguez:
I converted the remaining sleep.d snippets from packages a while ago, an example is the "at" daemon, which I believe has a bug that is being worked around by restarting the service on system resume, this is of course extremely ugly and it might be better to fix the daemon instead.
This is not a bug, it is by design. atd simply "sleep()"s until it is time for the next job. The sleep()-timer is stopped during hibernation. So atd needs either a restart or a wakup call (SIGHUP), to get the current time after resume. Otherwise it oversleeps the next job. Hendrik -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Cristian Rodríguez writes:
No idea if the if-up scripts can or should react to system resume.
I've removed pm-utils from my system and did a suspend/resume. Network is shut down before suspend and fetches a new DHCP address after the wake-up.
will it save/restore the hardware clock etc.?
The kernel takes care of the RTC suspend/resume.
Systemd notices that the time has been changed, I assume that this is the RTC interaction. NTP is not explicitly handled as far as I can tell from the log, but ntpd notices that the network has been down and sets the reach for all clock sources to zero, then re-syncs. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Thu, 28 Nov 2013 22:07:23 +0100 Achim Gratz <Stromeko@nexgo.de> пишет:
Cristian Rodríguez writes:
No idea if the if-up scripts can or should react to system resume.
I've removed pm-utils from my system and did a suspend/resume. Network is shut down before suspend and fetches a new DHCP address after the wake-up.
Are using NetworkManager or ifup? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Andrey Borzenkov writes:
Are using NetworkManager or ifup?
I've recently switched to NM in an attempt to speed up the boot process. It helps somewhat, but systemd still waits for ntpd to sync (about two minutes) before starting kdm. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Thu, 28 Nov 2013 22:22:56 +0100 Achim Gratz <Stromeko@nexgo.de> пишет:
Andrey Borzenkov writes:
Are using NetworkManager or ifup?
I've recently switched to NM in an attempt to speed up the boot process.
NetworkManager (at least, in current version) has own logic for handling suspend/resume and does not need pm-utils. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28/11/13 15:55, Cristian Rodríguez wrote:
e.g. does systemd do the checks in s2disk-check?
It already checks for available space, and I opened this bugreport: https://bugzilla.novell.com/show_bug.cgi?id=856389 that is should check for kernel resume parameter. I also proposed a patch there. On 28/11/13 16:30, Yamaban wrote:
A down/up or unplug/plug or reconnect cycle is needed in most environments and situations (dhcp, changed location, etc).
"Static Address" is a dwindeling number, and in some cases (hw) wireless even needs a full hw/driver re-init.
No easy situation to detect.
IMO restart the networking (fully) is the easiest way, or stop network before suspend/hibernate and start after wakeup/thaw. - both ways work-for-me.
I don't get it, what's the problem with dhcp? As for changed location, well, if you take a laptop to a different location you have to somehow connect to a new network even if you don't suspend it. On 28/11/13 22:07, Achim Gratz wrote:> Cristian Rodríguez writes:
Systemd notices that the time has been changed, I assume that this is the RTC interaction. NTP is not explicitly handled as far as I can tell from the log, but ntpd notices that the network has been down and sets the reach for all clock sources to zero, then re-syncs.
No need to worry about ntpd then, good. Although I'm not sure if it will still notice (on systems that don't use networkmanager) if there is no if-up/down scheme on suspend/resume (and I'm not convinced that there should be). As for ntp server, it doesn't make sense to suspend them does it? So again, nothing to worry about. On 29/11/13 12:39, Robert Schweikert wrote:
pm-utils is needed by libvirt-client not certain if the client can get what it needs from systemd functionality.
https://bugzilla.novell.com/show_bug.cgi?id=856381 I hope I addressed most of your concerns. If there is anything else or you think I'm wrong somewhere, tell me. As for the transition, I agreed with Frederic that he will revert the patch that plugs pm-utils to systemd. If someone wants to use pm-utils after that happens, he or she will have to invoke them manually from the commandline (pm-[suspend,hibernate]). If someone wants to object, feel free. Wojtek -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSs0ReAAoJEHrcxBn8c1xji20H/0M15PDN0ZgbCUEaqdX+vck0 MywhiZSlNmDAUu195U2WLOaCrUlFx5OHrUHFFwQQuLxDP53O6BT180mu6A+SEjuj 09ETUQwaFGMLw9TNDhyy1H4uxK20MFqB+tmt/r0u9IsGIqBvK905+6fJIBrlNfOt f92B5avKrBDBNchwLNCxbNTDeuGO6Ib1MKuQs4Nxii9F/SCiSryy8KUaS8Lg2QXs JZVXAx3hanFm+Cbt/cBvnZHOOou8Pn1ia8GDqfEdEseIgSrnrRVx+3r9vyouyPoX 4ICibOuH7Dr5C90DT+IxWS6sZlppyJxMpqsVnjrNbP4k81fDRpRVe89/0mV8PLg= =ncL9 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le 19/12/2013 20:09, Vojtěch Dziewięcki a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 28/11/13 15:55, Cristian Rodríguez wrote:
e.g. does systemd do the checks in s2disk-check?
It already checks for available space, and I opened this bugreport: https://bugzilla.novell.com/show_bug.cgi?id=856389 that is should check for kernel resume parameter. I also proposed a patch there.
On 28/11/13 16:30, Yamaban wrote:
A down/up or unplug/plug or reconnect cycle is needed in most environments and situations (dhcp, changed location, etc).
"Static Address" is a dwindeling number, and in some cases (hw) wireless even needs a full hw/driver re-init.
No easy situation to detect.
IMO restart the networking (fully) is the easiest way, or stop network before suspend/hibernate and start after wakeup/thaw. - both ways work-for-me. I don't get it, what's the problem with dhcp? As for changed location, well, if you take a laptop to a different location you have to somehow connect to a new network even if you don't suspend it.
On 28/11/13 22:07, Achim Gratz wrote:> Cristian Rodríguez writes:
Systemd notices that the time has been changed, I assume that this is the RTC interaction. NTP is not explicitly handled as far as I can tell from the log, but ntpd notices that the network has been down and sets the reach for all clock sources to zero, then re-syncs.
No need to worry about ntpd then, good. Although I'm not sure if it will still notice (on systems that don't use networkmanager) if there is no if-up/down scheme on suspend/resume (and I'm not convinced that there should be). As for ntp server, it doesn't make sense to suspend them does it? So again, nothing to worry about.
On 29/11/13 12:39, Robert Schweikert wrote:
pm-utils is needed by libvirt-client not certain if the client can get what it needs from systemd functionality. https://bugzilla.novell.com/show_bug.cgi?id=856381
I hope I addressed most of your concerns. If there is anything else or you think I'm wrong somewhere, tell me.
As for the transition, I agreed with Frederic that he will revert the patch that plugs pm-utils to systemd. If someone wants to use pm-utils after that happens, he or she will have to invoke them manually from the commandline (pm-[suspend,hibernate]). If someone wants to object, feel free.
Wojtek
It sounds laptop-mode-tools still use it. I take this discussion to recall a fate which purpose to replace it with tuned https://features.opensuse.org/314309 Regards. Benjamin -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 19/12/13 16:09, Vojtěch Dziewięcki escribió: ¿
I don't get it, what's the problem with dhcp? As for changed location, well, if you take a laptop to a different location you have to somehow connect to a new network even if you don't suspend it.
Yes, in this case, mobile users will certainly need networkmanager which handles this correctly.
No need to worry about ntpd then, good. Although I'm not sure if it will still notice (on systems that don't use networkmanager) if there is no if-up/down scheme on suspend/resume (and I'm not convinced that there should be). As for ntp server, it doesn't make sense to suspend them does it? So again, nothing to worry about.
ntpd watches routing changes using rtnetlink..or at least it should according to what I read, ps: apparently Redhat has decided to switch the default NTP implementation to "chrony" instead of ntpd in RHEL 7.0beta1..might be worth checking why ;-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le jeudi 19 décembre 2013 à 20:45 -0300, Cristian Rodríguez a écrit :
El 19/12/13 16:09, Vojtěch Dziewięcki escribió: ¿
I don't get it, what's the problem with dhcp? As for changed location, well, if you take a laptop to a different location you have to somehow connect to a new network even if you don't suspend it.
Yes, in this case, mobile users will certainly need networkmanager which handles this correctly.
Well, even without networkmanager, if the stack isn't able to handle wifi not being available anymore (imagine you attach your laptop to a leopard or you run very quickly outside of the wifi zone), there is a much bigger issue. In that regard, suspend/hibernate hacks shouldn't be needed. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri Dec 20, 2013 at 09:54 +0100 Frederic Crozat wrote:
Le jeudi 19 décembre 2013 à 20:45 -0300, Cristian Rodríguez a écrit :
El 19/12/13 16:09, Vojtěch Dziewięcki escribió: ¿
I don't get it, what's the problem with dhcp? As for changed location, well, if you take a laptop to a different location you have to somehow connect to a new network even if you don't suspend it.
Yes, in this case, mobile users will certainly need networkmanager which handles this correctly.
Well, even without networkmanager, if the stack isn't able to handle wifi not being available anymore (imagine you attach your laptop to a leopard or you run very quickly outside of the wifi zone), there is a much bigger issue. In that regard, suspend/hibernate hacks shouldn't be needed.
Well, applications have problems with hibernate without NetworkManager. Applications are not notified about time shift and consequent socket breakage, and for example Evolution goes crazy after resume. Here is one example of triggered bugs: uncaught time shift https://bugzilla.gnome.org/show_bug.cgi?id=680611 Another problems (unfixed) are caused by the losing of opened sockets. Evolution reports error, SIP does not reconnect etc. I am not sure whether there is a standard D-Bus signal for announcing of network loss and hibernation, but there surely should be, and hibernation should broadcast these signals. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
At Wed, 27 Nov 2013 17:24:56 +0100, Vojtěch Dziewięcki wrote:
Hi, I maintain pm-utils, and I want to drop them soon, because systemd can handle (sort of) suspend and hibernation and also becouse their upstream is dead and I'm not able to (and don't want to) fix all the bugs all by myself. There is some information and an initial discussion on the topic here: https://bugzilla.novell.com/show_bug.cgi?id=790157
The current state is that pm-utils are sort of "plugged in" to systemd and are called from systemd to perform suspend and hibernate, if they are installed. Doesn't work too well.
What doesn't work actually as of now? It'd be helpful if you could point out the bug list, for judging whether to drop pm-utils or not. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (17)
-
Achim Gratz -
Andrey Borzenkov -
Carlos E. R. -
Carlos E. R. -
Cristian Rodríguez -
denisart benjamin2 -
Frederic Crozat -
Greg Freemyer -
Guido Berhoerster -
Hendrik Woltersdorf -
Olaf Hering -
Oliver Neukum -
Per Jessen -
Stanislav Brabec -
Takashi Iwai -
Vojtěch Dziewięcki -
Yamaban