powerplan -s shows a different battery policy than what's set in powerplan.conf

[KarkanAlzwayed]

Description A clear and concise description of what the bug is. In the output of sudo powerplan -s, it was showing the policy as balance_power no matter what I did in the powerplan.conf file. I think it started happening after I ran powerplan --persistent, then it corrected itself after a couple of reboots. Now it is showing the correct thing. I still want to know why it did that at first. Additional info: Please include the output of "powerplan --system" and your powerplan.conf file (if relevant to issue)

System
    OS:                 Linux-5.14.10-1-MANJARO-x86_64-with-glibc2.33
    powerplan:          0.8.5 running on Python3.9.7 with psutil5.8.0
    CPU model:          Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz
    Core configuraton:  4/8  0-4 1-5 2-6 3-7
    Frequency range:    400000 - 1800000 - 4000000
    Driver:             intel_pstate
    Turbo:              /sys/devices/system/cpu/intel_pstate/no_turbo
    Governors:          performance, powersave
    Policies:           default, performance, balance_performance, balance_power, power
    Temperature:        acpitz, pch_skylake, iwlwifi_1, *coretemp
    AC adapter:         AC
    Battery:            BAT0

powerplan.conf:

[DEFAULT]
priority = 99
ac_pollingperiod = 1000
bat_pollingperiod = 2000
ac_cores_online = 4
bat_cores_online = 4
ac_templimit = 95
bat_templimit = 95
ac_minfreq = 400
ac_maxfreq = 4000
bat_minfreq = 400
bat_maxfreq = 3000
ac_minperf = 1
ac_maxperf = 100
bat_minperf = 1
bat_maxperf = 96
ac_tdp_sustained = 30
ac_tdp_burst = 45
bat_tdp_sustained = 10
bat_tdp_burst = 16
ac_turbo = True
bat_turbo = False
ac_governor = powersave
bat_governor = powersave
ac_policy = balance_performance
bat_policy = power
triggerapps = 

.

[Haptein]

Where you running it as a daemon? If so, can you please share your output of powerplan --log? If you can reproduce the problem, you can try running it like this:

powerplan --verbose

This will give you essentially the live output of what would be saved as a log if run as a daemon.

I think it started happening after I ran powerplan --persistent

Did this only happen when using --persistent?

then it corrected itself after a couple of reboots.

This is bit puzzling, powerplan doesn't do any permanent modification whatsoever, and everything should be reset after a reboot (until it runs again). I'm thinking perhaps this could be another application changing the policy, unless this behaviour is reliable triggered with the --persistent argument. I'll keep thinking about it...

[monarc99]

balance_power is the default policy in tlp. Maybe it changes the policy. And KDE has its own energy settings now.

[KarkanAlzwayed]

balance_power is the default policy in tlp. Maybe it changes the policy. And KDE has its own energy settings now.

I have removed TLP via sudo pacman -R tlp. So I am assuming it is not there anymore, since my fans aren't going crazy anymore when the laptop is plugged. Also, I am running Manjaro, and it is still on Plasma 5.22.5. The new power profiles are available on 5.23+

[KarkanAlzwayed]

Where you running it as a daemon? If so, can you please share your output of powerplan --log? If you can reproduce the problem, you can try running it like this:

powerplan --verbose

This will give you essentially the live output of what would be saved as a log if run as a daemon

Yes, always as a daemon Persistent is giving me this error: [ERROR] An instance is already running. You can monitor system status with: powerplan --status

This is powerplan --log

-- Journal begins at Tue 2021-10-26 21:01:30 EDT, ends at Wed 2021-10-27 06:56:45 EDT. --
Oct 26 21:01:31 kalzi-jaro systemd[1]: Started powerplan service.
Oct 26 21:01:38 kalzi-jaro powerplan[565]: Info: Available governors: performance, powersave
Oct 26 21:01:38 kalzi-jaro powerplan[565]: Info: Available policies: default, performance, balance_performance, balance_power, power
Oct 26 21:01:38 kalzi-jaro powerplan[565]: Info: IntelRapl is enabled.
Oct 26 21:01:38 kalzi-jaro powerplan[565]: Info: IntelRapl layer initialized: psys
Oct 26 21:01:38 kalzi-jaro powerplan[565]: Info: IntelRapl layer initialized: dram
Oct 26 21:01:38 kalzi-jaro powerplan[565]: Info: IntelRapl layer initialized: core
Oct 26 21:01:38 kalzi-jaro powerplan[565]: Info: IntelRapl layer initialized: package-0
Oct 26 21:01:38 kalzi-jaro powerplan[565]: Info: IntelRapl layer initialized: uncore
Oct 26 21:01:38 kalzi-jaro powerplan[565]: Info: AC-adapter detected: AC
Oct 26 21:01:38 kalzi-jaro powerplan[565]: Info: Battery detected: BAT0
Oct 26 21:01:38 kalzi-jaro powerplan[565]: Info: Available power method(s): CurrentVoltage, ChargeDeltaVoltage
Oct 26 21:01:38 kalzi-jaro powerplan[565]: Info: Power method selected: CurrentVoltage
Oct 26 21:01:38 kalzi-jaro powerplan[565]: Info: Applying profile: DEFAULT-Battery
Oct 26 22:05:01 kalzi-jaro powerplan[565]: Info: Applying profile: DEFAULT-AC
Oct 26 22:22:17 kalzi-jaro powerplan[565]: Info: Applying profile: DEFAULT-Battery

Just reproduced it and this is the output of powerplan --verbose

Info: Available governors: performance, powersave
Info: Available policies: default, performance, balance_performance, balance_power, power
Info: IntelRapl is enabled.
Info: IntelRapl layer initialized: psys
Info: IntelRapl layer initialized: dram
Info: IntelRapl layer initialized: core
Info: IntelRapl layer initialized: package-0
Info: IntelRapl layer initialized: uncore
Info: AC-adapter detected: AC
Info: Battery detected: BAT0
Info: Available power method(s): CurrentVoltage, ChargeDeltaVoltage
Info: Power method selected: CurrentVoltage
[ERROR] An instance is already running. You can monitor system status with: powerplan --status.

[Haptein]

[ERROR] An instance is already running. You can monitor system status with: powerplan --status

Only one instance of powerplan can be actively changing one system's configuration. Since the daemon is running you can't run powerplan in "active mode". The way to run it with the persistent argument is without any other instance running before it, or adding it to the .service file invocation for the daemon. Perhaps this should be a configuration option (instead of a cli argument), what do you think about this?

Oct 26 21:01:38 kalzi-jaro powerplan[565]: Info: Applying profile: DEFAULT-Battery Oct 26 22:05:01 kalzi-jaro powerplan[565]: Info: Applying profile: DEFAULT-AC Oct 26 22:22:17 kalzi-jaro powerplan[565]: Info: Applying profile: DEFAULT-Battery

This shows that profile application was indeed successful. Can you tell me the steps to reproduce this behaviour?

[KarkanAlzwayed]

Only one instance of powerplan can be actively changing one system's configuration. Since the daemon is running you can't run powerplan in "active mode". The way to run it with the persistent argument is without any other instance running before it, or adding it to the .service file invocation for the daemon. Perhaps this should be a configuration option (instead of a cli argument), what do you think about this?

I don't understand much of this. Do you mean that since I already ran powerplan --persistent, then I can't run it again? Or is powerplan --persistent a whole different process from the normally running powerplan profile (you know, the one that started when I first installed powerplan), do you mean that powerplan can be run in two different ways, "active" (the normal state after installing it) and "persistent" (which can be run independently). I don't know, I am confused.

This shows that profile application was indeed successful. Can you tell me the steps to reproduce this behaviour?

Which behavior, when powerplan -s shows the wrong battery policy than the one I set in powerplan.conf?

[Haptein]

Which behavior, when powerplan -s shows the wrong battery policy than the one I set in powerplan.conf?

Yes, that one.

About the running modes, there's two mayor modes powerplan can run in:

• Active mode: powerplan applies profile configurations.
• Monitor mode: powerplan applies no changes whatsoever, it just serves a a system monitor.

If you run powerplan only once it will run in active mode. If you run powerplan two times at the same time the second of these two instances of powerplan can only run in monitor mode (and requires you to use the --status argument). If you run powerplan only once with the --status argument, it will run in active mode, while providing monitoring at the same time (at the top of the status screen it will be shown in which mode is powerplan running).

Given all this, running powerplan with the --persistent argument (which enforces the changes periodically) only makes sense when running on active mode. Running it as a daemon is the same as running it manually (with --verbose, which logs some info), it will run in active mode at boot, and if for some reason there's ever another instance running at the time you start/restart the daemon it will just fail.

I'm trying my best to explain this, but don't hesitate to ask if it still is unclear. English isn't my first language and my use of it is mostly academic, please feel free to suggest changes in the project's readme if you think something is unclear 😅

[KarkanAlzwayed]

Active mode: powerplan applies profile configurations.
Monitor mode: powerplan applies no changes whatsoever, it just serves a a system monitor.

How do I run either of these two modes? With what commands? I thought running sudo powerplan -s is just to show some info and also to see how much power I am drawing under powerplan(that is already running and helping me save battery). I thought that installing powerplan the very first time activates it automatically until I reboot, then running powerplan --daemon would make it persistent through reboots.

If you run powerplan only once it will run in active mode

Again, how do I run that?

If you run powerplan two times at the same time the second of these two instances of powerplan can only run in monitor mode (and requires you to use the --status argument).

How do I run it a second time? After I ran sudo powerplan -s then ctrl+c then sudo powerplan -s again? Is that consider a second time? Or is it in another terminal tab? I don't think it is your English, I think it is me, I am very slow to understand things at first. Your English is actually better than you think. lol

[Haptein]

I thought that installing powerplan the very first time activates it automatically until I reboot, then running powerplan --daemon would make it persistent through reboots.

Yes, that is correct:+1: Running: sudo powerplan --daemon installs it as a systemd daemon. It runs at boot time ( in active mode of course).

After I ran sudo powerplan -s then ctrl+c then sudo powerplan -s again? Is that consider a second time?

No, by second time I mean a second simultaneous process. So for example, if I already installed powerplan as a daemon, executing powerplan --status in a terminal window will run a second process of powerplan, this time in monitor mode (as the daemon is already running in active mode). If I didn't install it already as a daemon and execute the same command (without any other simultaneous process of powerplan running) it will run in active mode, applying profiles.

The idea behind the distinction between active and monitor mode is that only one instance (ie. one running process) of powerplan is applying changes, and any additional simultaneous processes of powerplan won't be allowed to make changes.

I don't think it is your English, I think it is me, I am very slow to understand things at first.

Oh I get you, I might be on the same boat :P But still, I think I might be making things sound more convoluted than they really are.

Your English is actually better than you think. lol

That's reassuring haha ❤️

[KarkanAlzwayed]

If you want my honest opinion, this is kind of overly complicated. I think that it should be simplified a bit. Here is what I have gathered so far:

1. Running sudo ./install inside of the powerplan folder, installs it in active mode. (but not across reboots)
2. Running sudo powerplan -s (or --status) after that shows active mode, and now it is the one that is applying profiles. Running it over and over is still active mode, but it will be reset after a reboot, and I'd have to run the command again after reboot to activate it (I feel like the last part is not correct)
3. Running sudo powerplan --daemon runs it in active mode (which I can't show anymore by running powerplan -s because it will only show monitor mode from now on, because powerplan --daemon is now the active mode, but it has no command to show it where I can see [active mode] in the top.), even across reboots, and it is also now the one that is applying the profiles, and running sudo powerplan -s after that is just to monitor what powerplan --daemon is doing in the background (applying profiles) Is that correct?

[Haptein]

If you want my honest opinion, this is kind of overly complicated. I think that it should be simplified a bit.

Hmm, do you think so? The best I can summarize it is like this: If an instance of powerplan is running, a new one isn't allowed to make changes to your system (monitor mode). If no other instance is already running a new one is always allowed to make changes (active mode).

So if an instance runs in monitor mode it means another one must be already running in active mode.

1. Running sudo ./install just moves the needed files to their installation directory. Active/monitor mode just makes sense in the context of a running process. You can actually run in both modes straight from the git clone directory.

2. Yes. --status only means the program will periodically show you the system status, it has no impact on it running on active/monitor mode.

3. Yes, this is correct. sudo powerplan --daemon will install and activate powerplan as a system service. This means it will run automatically at boot. You can stop it with sudo systemctl stop powerplan for example, just like any other systemd service.

[KarkanAlzwayed]

I think that it should be installed with the ./install (obviously), then there should only be a --start, --stop, --persistent (for across reboots), --no-override (to prevent other programs from overriding powerplan's settings) and just leave --status to be the monitor only. Keep the other ones --log, --system.... etc for your troubleshooting. Everything else can still stay the same, like creating profiles and whatnot. Hope this makes sense. :)

[Haptein]

then there should only be a --start, --stop

You can control start/stop/enable/disable with systemd already. I'd also like to support systems without systemd in the future and implementing these additional functions also mean powerplan would take additional responsibilities, which are already redundant.

--persistent (for across reboots)

While using similar tools it seemed to me that persistent always meant persistent changes Vs embedded controllers or other software. I think that --daemon is already explicit (maybe I could change it to install as service or something), but I agree that --persistent can be confusing. Maybe changing the help messages, or making persistency (protection against override) a config entry could help. I'm open to opinions, but it isn't obvious to me what's the best way to go about it, honestly.

just leave --status to be the monitor only.

This sounds very reasonable.

@monarc99 Can I bother you with an opinion on these things? 🙏

[monarc99]

I would remove --daemon, --start --stop. Normally a daemon is packaged by a linux distribution. And the packager decide, how a daemon is started on the system. (systemd, openrc, ...)
Distributions (like Debian, Arch) don't like install scripts (like install, uninstall, enable-daemon - scripts with root rights) and try not to package them. (with reason)

I would provide a powerplan.service file for systemd and your install scripts - for easy testing on github - until powerplan can be installed from AUR.

--persistent or permanent (?) i think a config entry would be better. # you can explain the option with a comment

[KarkanAlzwayed]

All this confusion would be solved with a simple GUI app that has a couple of switches, "activate/dactivate powerplan", "start at boot", "prevent overrides"... etc. A couple of switches/check boxes would make it very simple. The user would just worry about those checkboxes/switches, and you (and hopefully future contributors) worry about the backend. I wish I knew how to or had the time to learn how. :/

[monarc99]

Anyway i can reproduce the problem. If i edit the powerplan.conf file and don't restart both - daemon and monitor, something is wrong.

1. edit /etc/powerplan.conf
2. stop monitor with CTRL+C in console
3. restart daemon with :

---

sudo systemctl restart powerplan

---

4. restart monitor with

---

sudo powerplan --status

---

it seems to work.

[Haptein]

Oh, in the middle of everything I missed the fact that he was running it as a daemon. A service restart is needed after config edits, just like with any other service.

[KarkanAlzwayed]

I think I may need to re-read the README.md. I never knew that I needed to restart the service after changing powerplan.conf file. I didn't have to do it when I first started using this program. Is it something new?

[Haptein]

Is it something new?

It's always been like that. I don't think it is mentioned in the readme as of now, I guess mentioning it is a good idea.

[KarkanAlzwayed]

Do I need to run powerplan as a daemon before I can restart it with systemctl? Because when I rung sudo systemctl restart powerplan, I get this error:

Failed to restart powerplan.service: Unit powerplan.service not found. I haven't run sudo powerplan --daemon after installing it, just to be clear.

[Haptein]

Do I need to run powerplan as a daemon before I can restart it with systemctl?

Yes, running powerplan --daemon installs and enables powerplan as a systemd daemon. If you uninstall powerplan the service naturally get's uninstalled as well.

[KarkanAlzwayed]

I'm so confused. So running --daemon makes powerplan run across reboots, which means, without it, it should stop when I reboot, but it is not stopping on my machine even after several reboots. Every time I run sudo powerplan -s, it shows the active window like normal, and it is working. The only difference I am seeing after running it as a daemon is now powerplan -s shows as a monitor mode instead of active. Can you please beat some sense into my brain? lol

[Haptein]

Ok, help me get some things clear.

but it is not stopping on my machine even after several reboots.

What do you mean it's not stopping? Can you see it running on a process monitor?

Every time I run sudo powerplan -s, it shows the active window like normal, and it is working.

With active window do you mean the active mode indication? Since no other instance of powerplan is running, the instance of it when you run powerplan -s in the terminal will be allowed to make system changes.

The only difference I am seeing after running it as a daemon is now powerplan -s shows as a monitor mode instead of active.

That's to be expected. Since the daemon is already running, if you run powerplan in a terminal window this new instance won't be allowed to make changes to your system (hence the monitor mode).

What I am getting is that somehow the changes are persisting across reboots without the daemon. Is this correct? If this is somehow the case, without an active powerplan process your power profiles won't get automatically switched (with ac power changes or profile-triggering apps running).

The main difference between running powerplan manually (with or without the --status argument) and installing it as a daemon is that as a daemon it will run automatically at boot.

[KarkanAlzwayed]

What do you mean it's not stopping? Can you see it running on a process monitor?

I mean, after install powerplan for the first time, run sudo powerplan -s, I'd get the [active mode] window in the terminal where I see info about the power draw and all that stuff (see screenshot). If I reboot and run the same powerplan -s, I'd still get the active mode window where I can see the same info. That indicates to me that it ran through reboots. Wouldn't it just throw an error when I run powerplan -s after a reboot if I've never run -daemon? Because it should've stopped after the reboot? Or am I wrong?

What I am getting is that somehow the changes are persisting across reboots without the daemon. Is this correct?

Yes, this is the window that I am talking about. I am seeing this even after a reboot without even running sudo powerplan -daemon

[Haptein]

I think I see the misunderstanding now.

Using the --status argument means that in addition to doing it's thing, powerplan will also output some status data. If there's already a process or powerplan running at the time of running powerplan -s in a terminal, then the powerplan process you created in the terminal won't do any system changes, it will just show the status data (and it will therefore show monitor mode at the top). "active/monitor mode" indicates if the current process being run is allowed to do system changes.

If I reboot and run the same powerplan -s, I'd still get the active mode window where I can see the same info. That indicates to me that it ran through reboots. Wouldn't it just throw an error when I run powerplan -s after a reboot if I've never run -daemon? Because it should've stopped after the reboot? Or am I wrong?

The behaviour you describe is exactly as expected, but that doesn't mean the process maintains it's presence across boots. This happens in the following way:

1. You run sudo powerplan -s in terminal.
2. No other instance of powerplan is detected so this new process is granted system changing rights (active mode that is)
3. Reboot
4. Repeat steps 1 and 2.

So powerplan never runs at boot time automatically in this scenario, but whenever you run it it runs on active mode.

[Haptein]

Ok, so I'd like some feedback on this. I was thinking on introducing a pair of global config variables (persistent and notifications, both off by default). But I worry it'd be a bit confusing if I include all that in the current profile config file (/etc/powerplan.conf). The idea is to change that to: /etc/powerplan/powerplan.conf /etc/powerplan/profiles.conf

The current /etc/powerplan.conf would just get moved to /etc/powerplan/profiles.conf and new global variables can go in the other file. Does this sound reasonable?

[monarc99]

It sounds good. Global config in /etc/powerplan/powerplan.conf

Profiles:
1 file or several

/etc/powerplan/profiles.conf

or

/etc/powerplan/profiles.d/default.conf /etc/powerplan/profiles.d/performance.conf /etc/powerplan/profiles.d/powersave.conf

like the ananicy rules.