Getting back suspend/resume with KDE 5’s powerdevil and no systemd by installing an obsolete version of upower

Using a package out of date since more 2 years ago does not sound like a success story but that is the only way so far I found to get suspend/resume to work without systemd within KDE5 without headaches. pm-suspend and pm-hibernate, on the command line, work perfectly though.

Why? Because Powerdevil, KDE’s power management tool, use upower which itself deprecated pm-utils support in favor of systemd.  So, no matter whether your hardware can actually suspend and hibernate, no matter if the kernel, GNU/Linux itself, can handle, upower won’t.

When calling upower -d, it should output something with can-suspend and can-hibernate. Since they dropped support for pm-utils, it won’t if you don’t use systemd . It’ll behave as if it knew what it was doing except it does not.

I filled a bug report and this one was discarded very fast. Martin Gräßlin immediately marked it as RESOLVED DOWNSTREAM with the comment “This works fine on Debian testing. Please get in contact with your distribution to figure out why this broke in your Debian fork. You might consider of course to install systemd”. You get the idea.  Thanks to Michael Palimaka, I got confirmation that it was tied to upower version (which I guessed beforehand because of several related messages by some Ubuntu or else users – hence the mention “with upower 0.99.3 and Devuan” in my report title) and he listed working solutions: using systemd; using ConsoleKit2; using upower <=0.9.23.

Using systemd to fix a problem caused by an attempt not to use systemd? Not an option. Using ConsoleKit2? Except I have no knowledge of ConsoleKit2 being packaged yet, neither do I know which release of upower actually got ConsoleKit2 support.

So I went for the third option, the lamest obviously, that is installing obsolete, unsupported software, and put in on hold. It can be done as follow:

echo "deb wheezy main" > /etc/apt/sources.list.d/oldstable.list
apt-get update
apt-get -t wheezy install libgnutls26 libgcrypt11 libtasn1-3 libusbmuxd1 libimobiledevice2 upower libupower-glib libplist1
echo "upower hold" | dpkg --set-selections

Then a call to upower -d gives:

 daemon-version: 0.9.17
 can-suspend: no
 can-hibernate no
 on-battery: no
 on-low-battery: no
 lid-is-closed: no
 lid-is-present: no
 is-docked: no

It is better but still no good. As root it’ll work, though. You need to add some PolicyKit rule to allow regular users to use it. The following assumes that powerdev group exists and that your regular users are in this group (if they are not, add them with adduser thisuser powerdev):

echo "[Suspend power group override]

[Hibernate power group override]
ResultActive=yes" > /etc/polkit-1/localauthority/50-local.d/power-group.suspend-override.pkla

Now, if done properly, upower -d returns:

 daemon-version: 0.9.17
 can-suspend: yes
 can-hibernate yes
 on-battery: no
 on-low-battery: no
 lid-is-closed: no
 lid-is-present: no
 is-docked: no

Logout and login should be enough to have back suspend and hibernate within KDE5.

So this works. For now. But there is no doubt, this is wrong in so many ways. I wonder for how long it will be possible to run a modern desktop environment on GNU/Linux, and not on systemd/whatever.


17 thoughts on “Getting back suspend/resume with KDE 5’s powerdevil and no systemd by installing an obsolete version of upower

  1. Kåre Säs says:

    Why do you make it sound like it was KDE/powerdevil that tries to force systemd on you when it is upower that switched to systemd?

    • I am a KDE end user since long. Before there was ever systemd and upower. I’m now facing regressions with not a single benefit from the user point of view. I understand David Edmonson point of view when he says that it defeats the purpose of using systemd to make it an option. This make sense from a developer point of view. But then, I am concerned that soon enough I’ll be facing the choice of either no longer using KDE or using systemd.

      It matters not that it is caused by some KDE component directly or by some software made mandatory by some KDE component.

      In the long run, if every piece of KDE stops to works in a similar fashion, a parallel to systemd will have to be written to keeps things working. But the point of not using systemd is not to write another systemd, that would be absurd, it is to actually keep using stuff that already works.

      • If your expectation is that you can just upgrade whatever component it is, but only some and ripping out others without suitable replacement, then yes, you’ll be running into trouble in the future. What you are experiencing here is the cost of maintaining devuan, this means that you now get to do the homework of learning about what solutions systemd provides, what applications (such as Plasma expect), and how to replace them. I suggest to do that before upgrading.

        • Actually, if I had time to devote to this, it would makes much more sense to contribute to some desktop completely systemd free.
          How would it makes sense to replace systemd? Using an alternate cheezy clone of systemd? systemd currently does not satisfies me, why would a replacement be better?

          • I didn’t say you have to implement another systemd, kindly try to not put words in my mouth.

            What I offered as a solution is to provide the DBus interfaces, which or what kind of application that does it entirely up to you (ConsoleKit2, upower, systemd, your-own-little-thing, …). This can be a monolithic or modular thing, whatever you prefer — we simply don’t care.

            The dependency here is the DBus interface (which is easy to implement), not systemd.

            If you’re not happy with any of the 3 solutions that are being offered, then you get to write your own. It’s nothing that the Plasma team is planning to do right now, sorry.

          • > Actually, if I had time to devote to this, it would make much more sense to contribute to some desktop completely systemd free.

            But as you lack time, you try to force us into pouring time into something because it fits your agenda, limited understanding and unwillingness to accept currently working solutions, even if it’s just making sure there’s a ConsoleKit2 package?

            And again, you’re not sticking to the facts: Plasma doesn’t hard-depend on systemd, but we use features which are used by systemd (as well as other solutions). It’s important that you are correct in your terminology, because it makes all the difference in the path towards a solution.

            Honestly, it’s hardly surprising that you’re met with raised eyebrows.

  2. As you note yourself, it doesn’t have to be systemd, the problem is that your system is not providing the DBus interfaces which were offered by the upower you moved away from.

    The obvious solution is to it with something that provides the relevant DBus interfaces. That doesn’t have to be systemd, the old upower also works as you note.

    What you’re trying to do here is push the work upon the KDE developers that you ultimately are responsible for yourself: If you want these things to work, make sure the suspend-relevant interfaces are available in your DBus user session.

    If you don’t want upower or systemd, you’ll have to implement them yourself. (And I’m pretty sure you had to do the same for other components already.)

    These are the costs of you forking Debian, which is your right to do, but it means that you have to also do the work that comes with it.

    Trying to gain publicity and coercing developers of other projects into doing the work for you is simply antisocial behaviour. I suggest that you spend the time you’re wasting here into fixing your system. We told you how.

    • Sebastian, I am not fighting you. I perfectly understand your benefit from using systemd.

      My point is: I was satisfied with what I had before. I am less by running with systemd, which I tried since 2012. And I am less now with KDE depending more and more on systemd, directly or not.

      You have not been coerced to anything. If you want me to show you in real life what this word exactly mean, you would not like it.

      I dont think it is wrongly to publicly wonder whether KDE will be usable without systemd next year.

  3. We also pointed you to ConsoleKit2. You said you don’t know about it, and it seems that’s a sufficient “solution” for you. How about you start reading up on it, do your homework to find out if it’s a suitable replacement and package it?

    Even that seems like a more effective use of everyone’s time.

    • I said I doubt know whether ConsoleKit2 has been package, neither do I know software supporting ConsoleKit2 has been too. That is sensibly different.

      But, apart from that, I did my homework: I found out it is a one man project thought as a stop gap until systemd is ready. This does not sounds at all as a durable solution.

      If you follow what Edmunson wrote, KDE will throw away the code that made stuff until then working. Beside implementing another systemd, there is no alternative to systemd. And, well, implementing another systemd, how is that a solution to anything?

      • Let me try to explain why you’re being unfair (and why I used the word ‘coercing’): You’re trying to get us to do something (without pointing out what exactly), and if you’re met with doubts, you take it slashdot? In my books, that’s an unconstructive move that reeks of trying to use public pressure, not constructive discourse.
        You repeatedly use the term “KDE dropped support”, that’s factually incorrect, explanation here: , more correct would be “upower dropped support”. If you’re unhappy with that, please complain to Bastien Nocera (he removed what you’re after from upower).

        My understanding is that you understand exactly what you want to take out of a discussion and completely ignore the rest. That limits the usefulness of the whole exercise. We clearly explained to you what the solutions could be and I even offered help in working towards one, yet all we get is willful twisting of our words and an obvious unwillingness to work towards a solution.

        You said yourself, you lack the time. Guess what, this is a game where you have to scratch your own itch, at least if you think you need alternative #4 instead of the three we already offered.

        Maybe it helps if you contact distributions who already solved this problem to provide some perspective. Because … this problem has been solved by others already (Gentoo, Slackware come to mind).

        Bottom line: this is a downstream problem, it’s marked as such, and no amount of public shaming or discussion is going to change the fact that you can’t just rip out a central component of your system without providing bits and pieces that fill in the now-missing functionality.

        • Sebastian, my post to ./ has an explicit title: will people not using systemd still be able to use KDE in 2016? I’m afraid not.
          The article clearly states “that the bug seemed entirely tied to upower, an upstream software used by Powerdevil”.
          It is nothing for you to take personally.

          So you say it’s downstream. Ok. Upstream, downstream, whatever. My logic is quite simple: I had something that did some work; with systemd, it failed to still work as expected (not once, and fixing it was painy enough each time) so I backed down from systemd, because it was making me loose time. Because I’m used, with GNU/Linux, to select which parts suits my needs. But there is no real way back because the rest was removed in the meantime – or will be. It was not in the past a central component. Now it is.

          A few month ago, when I moved to Devuan, , I was already wondering “how Devuan will cope with bugs reports and stuff in the long run”. Now I have a better view, hence the question: will people not using systemd still be able to use KDE in 2016, which I think is only fair to ask, and of interest to any person using KDE without systemd.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s