Bug 58950

Summary:	Send signal when about to suspend
Product:	systemd	Reporter:	Bastien Nocera <bugzilla>
Component:	general	Assignee:	systemd-bugs
Status:	RESOLVED FIXED	QA Contact:	systemd-bugs
Severity:	normal
Priority:	medium	CC:	pedrogfrancisco, richard
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Bastien Nocera 2013-01-02 15:20:49 UTC

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

Comment 1 Lennart Poettering 2013-01-03 17:41:23 UTC

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.

Comment 2 Kamil Páral 2013-01-21 11:44:16 UTC

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.

Comment 3 Lennart Poettering 2013-01-23 01:09:06 UTC

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.

Comment 4 Bastien Nocera 2013-01-23 12:57:54 UTC

(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.