Currently, suspending using upower will send the org.freedesktop.UPower.Sleeping signal, but suspending through logind will not emit any signals. It should be easier for applications to know when suspending will occur so that they can close down any open network sockets they might have if necessary (this is a problem for SIP clients for example, where the suspended machine might be the one receiving incoming phone calls). If logind sent a signal, the UPower signal could be deprecated and UPower would use logind to actually suspend. See: https://bugzilla.gnome.org/show_bug.cgi?id=690713
We already have that. It's the PrepareForSleep(true) signal that org.freedesktop.login1.Manager sends out. Please have a look at http://www.freedesktop.org/wiki/Software/systemd/inhibit See the example "Taking Delay Locks" for your use case.
Lennart, why don't you send the old UPower signals as well, so that you don't break existing applications and they have some time to migrate to the new signals? This transition has broken some important applications, not just IM clients, for example NetworkManager. If I suspend through systemd, it fails to disconnect from the network and VPN, and after resume it looks like connected, but the routing is broken. I'll report a bug against NetworkManager, but I just don't understand why do we change API without giving developers time to adjust. Reopening for your consideration.
We actually did a lot of work to get the various components fixed, I patched the code of a ton of projects myself for that. We might have missed some, though. In general we try to fix things properly, rather than carrying compat kludges forever. We do make mistakes though and miss some things. Sorry for that.
(In reply to comment #2) > Lennart, why don't you send the old UPower signals as well, so that you > don't break existing applications and they have some time to migrate to the > new signals? > > This transition has broken some important applications, not just IM clients, > for example NetworkManager. If I suspend through systemd, it fails to > disconnect from the network and VPN, and after resume it looks like > connected, but the routing is broken. > > I'll report a bug against NetworkManager, but I just don't understand why do > we change API without giving developers time to adjust. Reopening for your > consideration. The UPower API was *always* broken as there wasn't a way to delay the suspend while you did things, it would send the signal and suspend even if you were in the middle of saving your data for example. I'm pretty sure that UPower could be fixed to send the signal, but it would have the same caveat which makes it unusable right now.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.