Bug 68758

(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