[systemd-devel] systemd version debus call changed

[Lennart Poettering]

On Tue, 04.03.14 01:06, Timothée Ravier (siosm99 at gmail.com) wrote:

> 
> On 03/03/2014 14:28, Àlex Fiestas wrote:
> > On Friday 28 February 2014 02:28:20 Lennart Poettering wrote:
> >> They should just invoke the methods. If they get
> >> org.freedesktop.DBus.Error.UnknownMethod,
> >> org.freedesktop.DBus.Error.UnknownObject or
> >> org.freedesktop.DBus.Error.UnknownInterface back they should assume that
> >> logind is too old and doesn't support the call. (Actually, to make this
> >> really robust, they should just treat any error like that).
> >>
> >> Check for features by trying to make use of them. Don't check for
> >> version numbers.
> > The problem was that long ago logind supported suspend (methods were in the 
> > bus) but they did not work, at least not for opensuse so that work around was 
> > added.
> > 
> > This code will certainly die in the near future.
> 
> I'm working on fixing this for KDE
> (https://git.reviewboard.kde.org/r/116527/). But now that I've looked at
> it little bit closer I think I may understand why they did version checks:
> 
> As far as I understand, between v183 (d889a2069a87e4617b32dd) and v198
> (314b4b0a68d9ab35de98192), PrepareForSleep signal is sent before
> suspending, but no signal is sent on resume, thus one must use upower to
> get this info; From v198 and onward, PrepareForSleep signal is also sent
> on resume, thus no need for upower anymore.
> 
> Am I correct here? Did I miss something? Are there are any other
> solutions than checking for the version number to know if
> PrepareForSleep will be sent on resume? Should we just give up trying to
> support versions of systemd older than 198 (for systemd-based systems)?

So, the old interface really didn't support any notification for system
resume at all. We always assumed the kernel would eventually provide
something for this, but we came to the conclusion that even if the
kernel would provide userspace with a notification scheme for this
(which it still doesn't do to this point) we should probably distuingish
between low-level suspends (possibly done by the kernel itself with
aggressive kernel-level auto-suspend), from high-level suspends managed
by logind.

So, this wasn't really a compat breakage, since we just generated
signals that previously were only available for specific clients so that
all clients would get them. However, that certianly doesn't help
userspace apps like yours, since for them it cannot be determined
whether they are running on a system that only generates
PrepareForSleep() sometimes, or always...

I'd probably recommend using upower when it is there (and support for it
is compiled in), and then use logind as a fallback otherwise. That
should make your code work with any system. Or alternatively, just
declare that you require 198 at least...

Lennart

-- 
Lennart Poettering, Red Hat