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

[kalzEOS]

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.

[kalzEOS]

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+

[kalzEOS]

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?

[kalzEOS]

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 😅

[kalzEOS]

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 ❤️

[kalzEOS]

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.

[kalzEOS]

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

[kalzEOS]

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. :/