Try #1 succeeds, takes down services like network-manager etc. but doesn't acutally suspend.
Trying again results in:
Error: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.systemd1 was not provided by any .service files
(According to introspection data, you need to pass 'b')

> However, it is checking for the systemd version with a call to org.freedesktop.systemd1.Manager.VErsion and not geting a valid response. For some reason, that method doesn't exist on my system.

That would be because that's not systemd at pid1, but our systemd-shim which just doesn't have this method. Perhaps we should add it, perhaps we shouldn't because it might lure programs into thinking that systemd would actually be pid 1.

Albert Astals Cid [2013-07-23 7:29 -0000]:
> That's a weird answer, if you don't want people thinking we have
> systemd, should we just simply not exposing org.freedesktop.systemd1 ?

Admittedly it's a weird answer, because we have a weird setup -- we
need some parts of org.freedesktop.systemd1 for e. g. NTP or suspend
to work. We can certainly add the version API, if logind consumers
call this.

So it seems part of the problem is that upower forgets to install /lib/systemd/system-sleep/notify-upower.sh. I just fixed that in the packaging git. However, systemd-shim does not call these scripts, this needs to happen until this can work a second time.

Changed in upower (Ubuntu):

assignee:

nobody → Martin Pitt (pitti)

status:

New → Fix Committed

summary:

- Suspend only works once when using upower with logind+ Suspend only works once when using upower with logind -- s-shim needs to+ call /lib/systemd/system-sleep/*

The attachment "Implements version API in systemd-shim" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

Do you think it's a good idea if systemd-shim "lies" about the version number? It's not like it is implementing the full systemd (D-Bus) API.
Somehow I have the feeling it would be better/cleaner if systemd-shim would export its own version number (maybe with distinct prefix) so clients can find out if they are talking to systemd proper or systemd-shim.

I guess it depends on how user programs are currently using the systemd version API to check things. KDE PowerDevil strips everything before the space and just compares against the number, so in principle, the shim could use the prefix string to say something. I don't know how others use the API.

A cleaner approach to handling this would be an API for advertising implemented features so programs aren't checking the version to see if something is supported. Instead, they check if a feature they require is supported. It's the best way if you're just going to implement part of systemd, but you'd have to convince upstream to implement such an API.

Joseph Yasi [2013-08-30 18:50 -0000]:
> A cleaner approach to handling this would be an API for advertising
> implemented features so programs aren't checking the version to see if
> something is supported. Instead, they check if a feature they require is
> supported. It's the best way if you're just going to implement part of
> systemd, but you'd have to convince upstream to implement such an API.

I'm 99% sure that won't happen upstream. Our current cannibalization
of logind is scary enough for them :-)