Manual mode not shown in tlp-stat -s output

[drws]

Is your feature request related to a problem? Please describe.

It seems there is currently no way to query the current main mode of operation (automatic or manual). One can only infer by comparing Mode and Power source values from tlp-stat -s, but this is not a reliable indication for such a basic parameter.

Describe the solution you'd like

tlp-stat -s to also display the actual commanded main mode of operation.

Describe alternatives you've considered

As explained before, it is possible to approximate the current mode, but since it's one of the basic (input) parameters, it should have a direct, unambiguous and readily-available indication.

[linrunner]

In fact your feature request was implemented back in 2018 in version 1.2 with the initial implementation of manual mode and it looks like this:

+++ TLP Status State = enabled RDW state = enabled Last run = 15:03:34, 3 sec(s) ago Mode = battery (manual) Power source = AC

May I please see your output from tlp-stat -s (not only my cutout but everything)?

[drws]

Main mode indication is missing in my case. The issue is present on three similar machines (two laptops, one desktop), all running latest Arch Linux with TLP v1.5.0 from official repo. The requested output:

--- TLP 1.5.0 --------------------------------------------

+++ System Info
System         = [multiple values]
BIOS           = [multiple values]
OS Release     = Arch Linux
Kernel         = 6.1.45-1-lts #1 SMP PREEMPT_DYNAMIC Fri, 11 Aug 2023 11:28:00 +0000 x86_64
/proc/cmdline  = BOOT_IMAGE=/vmlinuz-linux-lts root=/dev/sda2 rw acpi.ec_no_wakeup=1 btusb.enable_autosuspend=0
Init system    = systemd 
Boot mode      = UEFI

+++ TLP Status
State          = enabled
RDW state      = not installed
Last run       = 12:41:19,    210 sec(s) ago
Mode           = battery
Power source   = battery

There is no main mode indication in Mode value (as in your case) under any circumstance (fresh boot, automatic mode selected, manual mode selected). Please also note other differences between our outputs:

• excessive whitespace after the comma in Last run value (in my case)
• vertical alignment present in my case, but not yours

Also, there's a single excessive space after value of Init system in my case ("systemd ").

[linrunner]

I can't reproduce this on Arch Linux. So let me see what happens on one of your machines by showing the output of

sudo tlp bat
ls -la /run/tlp
cat /run/tlp/manual_mode
ls -l /bin/sh

Please also note other differences between our outputs:

Your presumed differences come from comparing a code block (your output) with a quote (my example). The difference has no relevance to your problem.

[drws]

The issue is still present after recent update to v1.6. The requested output:

$ sudo tlp bat
TLP started in battery mode (manual).
$ ls -la /run/tlp
total 13k
drwxr-xr-x  2 root root  100 Sep  4 20:49 .
drwxr-xr-x 34 root root  820 Sep  4 17:24 ..
-rw-r--r--  1 root root    2 Sep  4 20:49 last_pwr
-rw-r-----  1 root root    2 Sep  4 20:49 manual_mode
-rw-rw-r--  1 root root 1.8k Sep  4 20:49 run.conf
$ cat /run/tlp/manual_mode
cat: /run/tlp/manual_mode: Permission denied
$ sudo !!
sudo cat /run/tlp/manual_mode
1
$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 May 23 18:38 /bin/sh -> bash
$ sudo tlp-stat -s
...
Mode           = battery
Power source   = AC

I can also confirm TLP is working in practice (laptop power draw, hardware state changes, etc.).

Regarding your remarks:

Your presumed differences come from comparing a code block (your output) with a quote (my example).

The presumed differences might come as a clue as to what's happening with the output to somebody very familiar with the code and seemed it couldn't hurt at the time. They could also be relevant since they are effectively bugs in printout and the original problem could be as well. You seem to be confident this is not the case in your answer, which was published after, but I still see no issue in mentioning them before. Also, you offered no final explanation why there's no excessive whitespace in your example. Using an unambiguous code block yourself would help with that.

The difference has no relevance to your problem.

Probably. Since the excessive whitespaces are really small bugs I thought it was convenient to include them here rather than to open another issue. Besides the fact they might prove helpful here of course.

Also since output I'm seeing shouldn't even be possible at all, I'm taking everything with a grain of salt. If TLP cannot determine its own state in certain cases, it should output an error and stop immediately. And if it can, it's probably a print bug, right?

[linrunner]

-rw-r----- 1 root root 2 Sep 4 20:49 manual_mode

Here we have the reason for your symptom. The status file is only readable by root, so the manual mode output fails when you call tlp-stat -s without sudo.

I suspect the cause is that you have an umask 0027 (or similar) set. Please show

umask
sudo sh -c "umask"
sudo -i sh -c "umask"

Of course TLP has to cope with a restrictive umask. But tlp-stat -s should still be callable without root privilege. For TLP 1.7 I will set the rights accordingly when creating the status file.

[linrunner]

Done. Thanks for reporting this.

[drws]

I noticed permissions before and thought of umask so the tlp-stat call in my previous post was already done as root (with incorrect output). Still the changes you added for v1.7 were necessary and could be sufficient.

Also it seems that TLP should output something if the status is unknown, at least a warning, preferrably an error. Again, the output in question shouldn't be possible in the first place, the corrupted state should be caught, not silently skipped. This is the second issue to consider.

[linrunner]

Your symptom that tlp-stat -s cannot read the file manual_mode despite sudo is not reproducible on my Arch Linux system. This is totally implausible. You would have to look yourself what is actually happening on your system.

The changes so far will be released with 1.6.1. Then we'll see what you come up with.

[linrunner]

I have now revised the code for detecting manual mode so that a read error cannot occur at all.