Similar as "Should watch UPower AboutToSleep signal", https://bugs.freedesktop.org/show_bug.cgi?id=28370 , telepathy mission control should watch systemd signals / create inhibitor locks for suspend. On my system, current Chakra, the UPower AboutToSleep Signal isn't sent anymore as it has completely transitioned to systemd. This results in telepathy not being able to log out prior to suspend, and because XEP-0198 is not implemented in telepathy, I stay online for others in my contact list until the server disconnects me according to his TCP Keepalive settings, which defaults to 4 hours on Debian systems. During that time, all messages sent to me are getting lost without any notice for the sender's or the receiver's side. I could reproduce this with the KDE-Version of Fedora using KTelepathy like on my own system. Information on the way systemd handles this: http://www.freedesktop.org/wiki/Software/systemd/logind/ Unlike UPower, Systemd doesn't just spit out a signal and waits a second and then shuts down, one can create something called inhibitor locks, which one cand hold and release when one is done with cleaning up. No general one second until everything is suspended, but exactly the time everything needs. Disadvandage is more implementation effort than just listening to a signal. Implementation in NetworkManager: http://code.metager.de/source/xref/freedesktop/NetworkManager/NetworkManager/src/nm-sleep-monitor-systemd.c
(Bug for XEP-0198 is https://bugs.freedesktop.org/show_bug.cgi?id=46700 )
(In reply to comment #0) > Unlike UPower, Systemd doesn't just spit out a signal and waits a second and > then shuts down, one can create something called inhibitor locks, which one > cand hold and release when one is done with cleaning up. This is better than the current state - we can ask all connections to disconnect, and retain the inhibitor lock for the duration - but is going to take rather more design. (In reply to comment #1) > (Bug for XEP-0198 is https://bugs.freedesktop.org/show_bug.cgi?id=46700 ) I suspect XEP-0198 is going to be rather harder than using inhibitor locks in MC, though; it probably makes sense to do this one first. Patches/branches for either feature welcome.
Created attachment 85063 [details] [review] Listen to systemd sleep/shutdown signals, and inhibit until disconnected --- This was easier than I thought. fd-passing in GDBus is a bit of a pain, but everything else is straightforward.
Comment on attachment 85063 [details] [review] Listen to systemd sleep/shutdown signals, and inhibit until disconnected Review of attachment 85063 [details] [review]: ----------------------------------------------------------------- I guess systemd doesn't provide a client side helper lib for this? ::: src/connectivity-monitor.c @@ +50,5 @@ > +#define LOGIN1_MANAGER_PREPARE_FOR_SHUTDOWN "PrepareForShutdown" > +#define LOGIN1_MANAGER_INHIBIT "Inhibit" > + > +struct _McdInhibit { > + gsize holds; Why are you using a gsize here? Also maybe document the semantic of 'holds'? @@ +358,5 @@ > + > + if (sleeping) > + { > + DEBUG ("about to suspend"); > + connectivity_monitor_change_states (self, 0, CONNECTIVITY_AWAKE, Could be clearer to have a CONNECTIVITY_NONE or something rather than 0.
(In reply to comment #4) > Why are you using a gsize here? "It's like a refcount" > Also maybe document the semantic of 'holds'? Sure. > Could be clearer to have a CONNECTIVITY_NONE or something rather than 0. I suppose so, it'd make "this is a bitfield" explicit in the call (but it'd also make the lines longer).
Created attachment 85136 [details] [review] McdConnectivityMonitor: comment how McdInhibit works
Created attachment 85137 [details] [review] Add CONNECTIVITY_NONE, and make state transitions clearer --- Hopefully those two patches address your feedback?
Comment on attachment 85136 [details] [review] McdConnectivityMonitor: comment how McdInhibit works Review of attachment 85136 [details] [review]: ----------------------------------------------------------------- ++
Comment on attachment 85137 [details] [review] Add CONNECTIVITY_NONE, and make state transitions clearer Review of attachment 85137 [details] [review]: ----------------------------------------------------------------- ++
(In reply to comment #7) > Hopefully those two patches address your feedback? Yep, go for it!
Fixed in git master for 5.15.1.
Thank you very very much for having this fixed in just 5 days after reporting, you're great! :) And I guess "smcv" who helped me on irc to to find out what the actual problem was with the DBUS signals stands for "Simon McVittie", so thanks once again. Can't wait for the next version of telepathy to make it into my distro's repositories! No more message losses on suspend, yay! :D
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.