['Solved']Power management and systemd

Due to the dropping of ConsoleKit I have been 'forced', so to speak, to approach a systemd setup earlier than I expected. And I have tried to adjust the past and the present/future the best way possible. After a successful transition of most of my rc.conf content (hwclock is the only one left there right now) I think I can say that I am at the pre-sysvinit removal stage, in terms of placing my setup in a so called 'transition to systemd' timeline that is.

Following the steps in the wiki related to avoid systemd to handle some ACPI events I encounter the following issues though,

- when the suspend key is pressed (Fn+F4) acpid is invoked twice according to journalctl and thus suspends my laptop twice too. It's hooks are run fine though.

- the hibernate process is taken over by systemd now.

In order to track down the first issue I first commented the related line in acpi's handler script to see what would happen. The result was that systemd takes over the process (without obviously executing the related pm hooks I use). Does systemd ignore that I set the Handle options to 'ignore' as said?Later on I tested commenting out the suspend line in handler.sh and set the suspend option in the xfce4 power manager (which is what I use in both xfce4 and openbox) to 'do nothing' and acpi suspends correctly and runs the hooks as always.

The hibernation process, just like the suspension one, has always worked flawless in a pre-systemd setup but now it is run by systemd and, just like in the suspension case when systemd is in charge, the pm hooks are not run.

Sure that I have been working on systemd alternatives to my pm hooks but I still would like to stay with acpid and, thus, know what may be the reasons for this acpi struggle and the systemd hibernation takeover.

Re: ['Solved']Power management and systemd

I think hwclock is already taken care of automatically. But maybe just use ntpd instead?

As far as the hooks and such, I have noticed to difference without them. But if they really concern you that much, you convert them to use /usr/lib/systemd/system-sleep. You may have noticed, buy systemd actually suspends much faster than pm-utils. Apparently this is because pm-utils runs all those scripts one after another. If you put the scripts in system-sleep, the scripts willa ctually be run in parallel, thereby providing faster perfomance still.

I would recommend that if you are going to switch to systemd, "forced" or not, do it right, and use the native functions. The scripts in pm-utils are actually there to deal with bugs and shortcomings of sysv and the kernel. So it should be that these things are not longer needed, presuming that these things are being/have been fixed.

Re: ['Solved']Power management and systemd

The thing WonderWoofy is that, similar to having to use systemd yes or yes to get 'ConsoleKit' support, part of my, and even that of other users if they have or run into the same problem, setup would be 'useless'. That is, some functions of my power manager would be ignored just because systemd decided to claim them at all costs. And that is, besides the tricky double acpi call, is what I am trying to find the reason for. Why does this happen even if I do not want to to be that way?

You are right by saying that there may be some improvement in running the scripts at the same time (ok for me as long as it does respect the line f.e. lock before suspend etc.). But, just as I have stated in my previous paragraph, the problem is more of not being able to tell systemd what to do and, in this case, what not to do.And that, I guess you will agree, is always a problem even if there are no 'improved' alternatives at stake.

Re: ['Solved']Power management and systemd

Have you looked at /etc/systemd/logind.conf? You should be able to prevent systemd managing sleep/hibernate etc. there. If it is ignoring those directives, I'd assume it is a bug.

I use:

$ cat /etc/systemd/logind.conf
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
#
# See logind.conf(5) for details
[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
#Controllers=
#ResetControllers=cpu
#InhibitDelayMaxSec=5
#HandlePowerKey=poweroff
#HandleSuspendKey=suspend
#HandleHibernateKey=hibernate
#HandleLidSwitch=suspend
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
LidSwitchIgnoreInhibited=no

Basically, this results in KDE managing all of this stuff.

There is an issue with this stuff with systemd. I essentially ended up with acpid, KDE and systemd all trying to handle things like lid close which made a mess. Moreover, pm-utils is still required. (I actually found it difficult to *stop* the hooks being run - I still haven't managed this for power saving and just mask them.)

And reboot still doesn't work... (but poweroff works better than with initscripts).

As I understand it, systemd should probably not be handling suspend/hibernate functions if a DE is active - hence the inhibitor functionality. But when I last checked, only KDE actually used that facility so YMMV with XFCE.

@rootI assume that you edited your logind.conf like that. Did you reboot after editing that file? Because systemd doesn't automatically reload it (I learned this while trying to fix the exact same problem). You have to either reboot, or restart systemd-logind.service.

As for suspend hooks, an alternative way (probably the "right" way of doing it with systemd) is described in this thread.

Re: ['Solved']Power management and systemd

Configured correctly systemd handles the functionality of consolekit just fine. The reason oh so many users have problems with this switch is because they don't read the news and they fail to search in any kind of reasonable way for threads that match their problem. So this is turn causes reapeated issues to pop up, and this I assume is what you are referring to.

So the non-functioning parts of your power manager is not systemd deciding the "claim them at all costs," so much as it is you having yet to correctly implement to functionality of logind.

I fail to understand how you see the "double acpi call" "tricky" as this to me seems pretty trivial to fix, and is documented in both the wiki and probably twenty times or so in these forums. I think the "problem... of not being able to tell systemd what to do" is simply you not being familiar with systemd yet. But you have to start somewhere, I think. But, being as young as systemd is, the documentation that is included with it is pretty amazing. And with each passing day, the online community info continues to grow (both here in the Arch forums/wiki and elsewhere).

In the end, I personally found systemd quite easy to handle. It may not be as dead simple as the daemons array of rc.conf, but I certainly like it.

Oh, and BTW, that first sentence was very confusing... I had to reread that a couple times.

Re: ['Solved']Power management and systemd

@cfr

Yes, I modified /etc/systemd/logind.conf as soon as I realized that XFCE wasn't among the power managers to be able to inhibit the calls. As you use KDE I am not sure though to what extend my symptons are comparable to the ones you are experiencing. I think that nevertheless I have to make more tests in a DE environment as my main working environment is OpenBox.

@Rad3k

You are right, I edited the file as explained in the wiki. I unfortunately do not recall if I rebooted afterwards. Still further tests have shown the still the same results, that is,

- despite dealing correctly with the suspend button acpi is called twice if besides set in acpi's handler.sh 'suspend' is also active in XFCE's power manager. Hooks are correctly run.

- systemd deals with hibernation and no acpi/pm hooks are run. LID is also taken over as I just tested.

So far I have found some more or less suitable systemd hooks even though I appreciate the 'right' approach of the thread you link to. Thank you.

@WonderWoofy

I am not sure why you refer to the correct setup of systemd for 'consolekit equivalency' as I was referring to

That means that the system must be booted with systemd to be fully functional.

from the 30th November news which made the switch, at least in my case as in that of others I presume, a must and not an option as it was previously (by adding the systemd init line to the bootloader).

As simple as that.

Regarding the missing functions in the power manager I have to expand my statement as, unfortunately, I did not include that I referred to your suggestion of switching completely to systemd to handle acpi events. That way systemd would be, as far as I understand it, off the options of the power manager and thus having to care about two scenarios instead of a single, more simpler, one.I hope the first sentence is more clearer to you now.

I would appreciate a link to the trivial fix you mention. That is, as long as you do not refer to the interference of systemd and a given power managing tool that does not inhibit the former Don't get me wrong, I do not want to sound mean or ungrateful, but I already made the modifications suggested by the wiki as stated again in this message. If I refer to a double call of acpid (with client disconnecting and connecting twice - whereas with systemd I only get the client connected acpid messages) I actually mean to say so.And the reason of this behaviour is what I am trying to figure out, with your help and the rest of the users that replied to this thread.Why suspension will run correctly and once (acpid - as setup in its handler.sh using pm-suspend) only if I disable it (suspension) in the power manager (XFCE) when previously it worked fine in a non-systemd setup?And this behaviour isn't listed in the wiki or the forums as far as I have looked up.

I am glad to read that systemd is easy to handle in your case which I hope will expand to more users, maybe even in the end to me.

Re: ['Solved']Power management and systemd

It seems that I have finally come across the reasons of the double acpi call. Or at least I think I have.

On the basis of my tests it seems that pm-utils inhibits systemd-logind acpi commands but the tricky thing is that this inhibition apparently "enables" the XFCE4 power manager. That is, once pm-utils resume from suspension/hibernation the referred power manager calls the same acpi event and, thus, ends up suspending/hibernating once again.

As I haven't converted to a pure systemd setup yet I was able to 'revert' to a sysv/initscript one to compare the results.With consolekit installed I got a not authorized notification from the power manager when attempting to suspend but was able to do so without further delay.After I once again removed consolekit the behaviour turned back to 'normal', not authorized and nothing unsuspected happening.

Therefore I wonder, a systemd setup breaks the 'collaboration' of XFCE power manager (and similar - maybe the ones not being able to inhibit systemd-logind behaviour? even though cfr's experience with the KDE one does not seem to point in that direction) and acpid/pm-utils? And by doing so they are now run 'independently' and this leads, as in my case, to running procedures twice?Someboy knows if there were any 'inhibitions' in sysv/init to avoid these 'double calls'?

I guess this would be some kind of bug, but who would be the one to 'blame', that is, reported to? acpid? pm-utils? XFCE power manager?

If someone could shed some light on this question I would really appreciate it.

As for now I guess I will let systemd-logind take over and handle the acpi basics and, besides avoiding these headaches for a while, take advantage for now of the speed improvement WonderWoofy referred to in one of his messages. That way, just like the wiki states I will intend to leave acpi handle the extra stuff that is not covered.

Re: ['Solved']Power management and systemd

root, I really don't know WTF you're talking about. pm-utils does not issue the necessary inhibited commands. The inhibits in question were just created a few months ago and pm-utils hasn't been touched in over two hears. The inhibits also can't magically enable the XFCE power manager. It looks to me like you're running both acpid and the XFCE power manager then blaming systemd for double suspends. Do you really not understand that two power managers running together is a bad thing?

Re: ['Solved']Power management and systemd

@Scimmia

You really seem to not know as you mix things up pretty bad. Where do I state that the inhibit action by pm-utils is due to the inhibits in systemd-logind config file? You know, the verb 'inhibit' can be used for more than refer to systemd config related issues.

In the same way, where do I state that I blame systemd for double suspends? As I already told WonderWoofy it is acpid that is involved in those double suspends and not systemd (at least as far as I know taking into account the journal info).

From my sysv/initscript experience XFCE power manager and acpid (extended with pm-utils) just go along pretty well. If they wouldn't, shouldn't this same behaviour happen both in a sysv/initscript setup and in a systemd one?

As it does not I presume there is something more than a 'bad thing'. The more I think of it the more I see it as systemd running both acpid/pm-utils and XFCE power manager as different programs and that is why they run one after another whereas sysv/initscript did not. Thus, yes, in the end systemd may be the one to 'blame'.

Re: ['Solved']Power management and systemd

On the basis of my tests it seems that pm-utils inhibits systemd-logind acpi commands but the tricky thing is that this inhibition apparently "enables" the XFCE4 power manager.

which does seem to suggest a certain degree of confusion. Only KDE, that I know of, has been updated to issue the relevant inhibitory commands. pm-utils *certainly* does not issue them since it has not been updated for a long time and those commands had not been invented then.

And the relevant inhibitions affect systemd's handling of the events. Inhibiting systemd's handling will not "enable" anything.

But if you have found a solution, maybe this is besides the point - mark the thread [solved] and move on .

Re: ['Solved']Power management and systemd

Confusion, as said, if the term 'inhibit' automatically is associated with the systemd-logind config file which I did not do

On the basis of the wiki it seems that Gnome has joined the 'club'. I am actually expectant once XFCE joins it too and how it will affect my nowadays setup.

More than finding a solution it seems that systemd works this way and there isn't much one can do. I also have already moved to a pure systemd setup and thus no further tests are available in a sysv/initscripts environment.