/usr/sbin/on_ac_power incorrectly reporting ac power status

Status changed to 'Confirmed' because the bug affects multiple users.

Looking at the package, it hasn't been updated in 3 years in Debian.

I have this issue on an Intel NUC (NUC10i357FN).

The sysfs entry for the power supply does contain a usb_type entry for it, which contains:

[nuc]: cat usb_type
[C] PD

Possibly this?

--- /bin/on_ac_power 2019-07-20 16:43:51.000000000 +0100
+++ ./on_ac_power 2022-09-22 01:44:53.412558622 +0100
@@ -28,6 +28,17 @@
            type="$(cat "${FN}/type")"
            case "${type}" in
            Mains|USB*|BrickID|Wireless)
+# If USB, is it input or output?
+#
+ case "${type}" in
+ USB*)
+ if test -r "${FN}/usb_type"; then
+ usb_type=`cat "${FN}/usb_type"`
+ case "${usb_type}" in
+ *PD*) continue ;;
+ esac
+ fi
+ esac
                if [ -r "${FN}/online" ]; then
                    online="$(cat "${FN}/online")"
                    [ "$online" = 1 ] && exit 0

(sorry - the indentation spaces after any + are being eaten)

This is still an issue in Kinetic.

And it's now stopping unattended_upgrades running, as these (now?) have a condition of ConditionACPower=true
which is not being met even though the system is running on AC (and has no other way of running).

Actually, it turns out that systemd has its own code to check for AC power (same/similar logic - perhaps this should be done in a single system service rather than duplicated between sub-systems?).

So I'll open a bug for this against systemd as well and cross-reference them.

The systemd bug report for this is bug #1998872

/lib/systemd/systemd-ac-power works (on lunar). on_ac_power still does not.

Perhaps on_ac_power should just be made a symlink to this - or the script should exec that systemd executable if it exists?

It's worth adding that in #1973359 (was closed as duplicate of this bug; I was the author), the computer is plugged in with a barrel power plug, not via USB-C PD. I'm not sure how it still ends up being routed as a USB power source in /sys/class/power_supply. Specifically, it's this computer: https://imgur.com/a/0nUFAFH ... so it's very much in "has consistent power" range.

Ubuntu 22.10 (Kinetic Kudu) has reached end of life, so this bug will not be fixed for that specific release.

It's *still* a bug in 23.04.

Do I need to open a new bug report?

Or do I have to wait until another LTS version comes along and report it against that (since it was also a problem with the previous LTS version, and hence still will be - note the comment above that it hasn't been changed in 3 years).

Gordon - Utkarsh's comment is just about cleaning up Kinetic-related items. We understand that this is still a problem in other releases.

However, I can't see any bug report for it it any other (later) release.

So this one is marked as High importance, but Won't fix.

There's a similar bug report about this from 2019 (bug #1823521). *That* was reported on 18.04.

This bug is only marked as "Won't Fix" for *Kinetic*; the "Triaged" state implicitly applies to the current development release (i.e. Mantic). In other words, this indicates that this bug has not been knowingly fixed in *any* release, and still needs attention.

By the way - is the main problem for you behavior with unattended-upgrades? Or just use of the on_ac_power script in general?

If the main problem is unattended-upgrades, we can more quickly remove use of on_ac_power from that, as opposed move everything away from using on_ac_power.

I'm not the bug opener, but the main problem for *me* was with unattended-upgrades as I noticed it had stopped running (while my other systems were still updating).
But that is fixed (as it runs from systemd and the systemd AC power check was fixed in Lunar).

However, there are (at least) 3 crontab entries in /etc/cron.daily or weekly (apt-compat, plocate and apt-xapian-index) using on_ac_power (although 2 of those don't run from cron if systemd is running...). This isn't bothering me.

FWIW, I opened the duplicate of this bug, and my problem was entirely with unattended upgrades.

I'm seeing this issue as part of a dependency which relies on `on_ac_power`. Here's the GitHub issue: https://github.com/regolith-linux/regolith-powerd/issues/1

I'm on Lunar.

/lib/systemd/systemd-ac-power reports correctly on my desktop.

Ubuntu 23.04 (Lunar Lobster) has reached end of life, so this bug will not be fixed for that specific release.

This is a problem in Mantic too.

And if you never fix it it will be a problem in the next LTS release. Just as it is a problem in the current LTS release.

I have the same problem in 22.04. Is it so difficult to fix it?

Status changed to 'Confirmed' because the bug affects multiple users.

Unsubscribung ubuntu-sponsors since sponsorship is already handled in the attached MP https://code.launchpad.net/~ghadi-rahme/ubuntu/+source/powermgmt-base/+git/powermgmt-base/+merge/466231

Ubuntu 23.10 (Mantic Minotaur) has reached end of life, so this bug will not be fixed for that specific release.

This bug was fixed in the package powermgmt-base - 1.37+nmu1ubuntu1

---------------
powermgmt-base (1.37+nmu1ubuntu1) oracular; urgency=medium

  * Fix on_ac_power incorrectly reporting AC state on some
    machines with USB type-C ports (LP: #1980991).

 -- Ghadi Elie Rahme <email address hidden> Tue, 30 Jul 2024 16:59:34 +0300

Hello,

Uploaded are the focal, jammy and noble patch respectively.

Regards,
Ghadi

Thank you for working on this!

SRU review

> Currently there is an issue with the ac_on_power script where it thinks that USB-c ports with devices plugged in to them are plugged in to power.

This isn't a statement of user impact, making it difficult to understand how changing the stable releases is justified.

But looking through the bug, I found a mention of unattended-upgrades not running on some systems because they are falsely believing that they are never on AC power. That implies a user impact of "system isn't automatically updated as expected". That does justify updating the stable release.

Is that the only user impact, or are there other cases we need to consider as well? This is important because if we identify other use cases then we will be able to know to test them.

> [Test Plan]

Please try to test the actual user impact, which in this case might mean running unattended-upgrades and ensuring that it does update on such a system. Running on_ac_power is a helpful diagnostic but it would be preferable to ensure that nothing else has been missed by testing the end goal directly as close as is possible.

Further, changing this code could regress existing systems into thinking they never are on AC power any more and therefore never run unattended-upgrades any more. This would stop security updates and so the consequences would be quite severe.

For this reason please further test:

a) Not just one power state of the machine, but that all reasonable power states of the machine return the expected result...

b) ...across some reasonable set of combinations of machines with and without USB-C sink and/or source capability...

c) ...considering different "online" states of sinks and sources, given my review point below and that the current separated code paths suggest that a bug may be present in this area.

On the actual upload:

1. There are spurious development artifacts being added - various combinations of {focal,jammy,noble}-powermgmt.debdiff. Please re-upload with these removed.

2.

> + power_type="USB*"

This does a glob expansion right here, which I think isn't what is intended. If there are files in the current directory with this pattern then they will be expanded here. This needs fixing.

3. I also don't follow the logic used here. What if a sink is found but it isn't online, and a source exists but is online? Wouldn't that incorrectly identify the system as being on AC power? As far as I can tell from just reading the code, the systemd example presented in the MP doesn't have this behaviour, but the code in this upload would. It's difficult to tell just from inspection though because the addition of this code makes it quite convoluted. Am I missing something?

Point 1 above requires re-upload, so I'm rejecting the current items from the Unapproved queue for now. Please address the other matters raised above before re-uploading.

Hello Robie,

Thank you for reviewing this!

I will update the test plan methodology to cover unattended upgrades and/or any other application that makes use of the script.

1. > There are spurious development artifacts being added

I have looked through the debdiffs and couldn't find such, are you referring to the "Maintainer" and "XSBC-Original-Maintainer" section maybe?

2. > This does a glob expansion right here...

Yes this is intended behavior as USBC is not the only USB power type, it is also the same value used before my changes.

3. > Wouldn't that incorrectly identify the system as being on AC power?

Yes you are correct! however this bug also exists in systemd. Systemd also checks if any of the ports are sink first before looking at all the USB power sources. The reason this works is because a USB-C port that is in source more should NOT show up as online under /sys/class/power_supply/* because only ports in sink more are supposed to show their online status here (ports in source mode will show up in the directory but will have their "online" state as 0 even if a device is plugged in to them). The reason I wrote this patch is because some of these source ports are mirroring their connection state inside the "online" sysfs. Discrete GPUs are the biggest culprits where those with USB-C ports are having their connection status mirrored inside "/sys/class/power_supply/ucsi-*/online" although they are labeled as a source device. Here is an upstream issue from systemd discussing such a case: https://github.com/systemd/systemd/issues/21988

Also here is proof from my system that systemd does indeed only require one port in sink mode to make USBC a valid power delivery option (my system has 4 thunderbolt ports that can all be used for charging):

ghadi@XPS-17-9720 ~ » cat /sys/class/typec/*/power_role
[source] sink
[source] sink
source [sink]
source [sink]

ghadi@XPS-17-9720 ~ » cat /sys/class/power_supply/ucsi-*/online
0
0
0
1

ghadi@XPS-17-9720 ~ » SYSTEMD_LOG_LEVEL=debug systemd-ac-power
BAT0: The battery status is 'Charging', assuming the battery is not used as a power source of this machine.
hidpp_battery_1: The power supply is a device battery, ignoring device.
AC: The power supply is currently online.
port0: The USB type-C port is in power source mode.
port1: The USB type-C port is in power source mode.
port2: The USB type-C port is in power sink mode.
port3: The USB type-C port is in power sink mode.
ucsi-source-psy-USBC000:001: The USB type-C device has at least one port in power sink mode.
ucsi-source-psy-USBC000:001: The power supply is currently offline.
port0: The USB type-C port is in power source mode.
port1: The USB type-C port is in power source mode.
port2: The USB type-C port is in power sink mode.
port3: The USB type-C port is in power sink mode.
ucsi-source-psy-USBC000:002: The USB type-C device has at least one port in power sink mode.
ucsi-source-psy-USBC000:002: The power supply is currently offline.
port0: The USB type-C port is in power source mode.
port1: The USB type-C port is in power source mode.
port2: The USB type-C port is in power sink mode.
port3: The USB type-C port is in power sink mode.
ucsi-sourc...

> 1. > There are spurious development artifacts being added

> I have looked through the debdiffs and couldn't find such, are you referring to the "Maintainer" and "XSBC-Original-Maintainer" section maybe?

Not the debdiffs, the actual upload. For example, from the Rejected queue, http://launchpadlibrarian.net/745154626/powermgmt-base_1.36_1.36ubuntu1.20.04.1.diff.gz contains:

> diff -Nru powermgmt-base-1.36/jammy-powermgmt.debdiff powermgmt-base-1.36ubuntu1.20.04.1/jammy-powermgmt.debdiff
> --- powermgmt-base-1.36/jammy-powermgmt.debdiff 1970-01-01 00:00:00.000000000 +0000
> +++ powermgmt-base-1.36ubuntu1.20.04.1/jammy-powermgmt.debdiff 2024-08-12 14:17:10.000000000 +0000

...so debdiff files were being added to the source package upload.

> 2. > This does a glob expansion right here...

> Yes this is intended behavior as USBC is not the only USB power type, it is also the same value used before my changes.

No I think you misunderstand. The script is running from some arbitrary current directory. The result of `power_type="USB*"` depends on the contents of that arbitrary current directory, which is probably not what you intend. For example, if I happen to be in /home/racb/some_project/ when I run on_ac_power, and the file /home/racb/some_project/USB_gotcha exists, then $power_type will get set to "USB_gotcha".

> 3. > Wouldn't that incorrectly identify the system as being on AC power?

Thank you for the detailed reply! This is going to take some time to read and understand. I'll reply to this separately so as not to lose other replies above.

This is noted as Fix Released in Oracular.

This is INCORRECT. This command is STILL BROKEN in Oracular.

This is the result of running it on one of my Intel NUCs (which, I can assure you, is *always* on AC power, as it has no battery).

[ganuc]: sh -x /usr/sbin/on_ac_power
+ set -e
+ OFF_LINE_P=no
+ USB_IS_SINK=no
+ USB_IS_SOURCE=no
+ power_type=Mains
+ [ -d /sys/class/typec/ ]
+ test -d /sys/class/typec/port0
+ test -r /sys/class/typec/port0/power_role
+ cat /sys/class/typec/port0/power_role
+ power_role=[sink]
+ echo [sink]
+ grep -q \[source\]
+ + echo [sink]
grep -q \[sink\]
+ USB_IS_SINK=yes
+ test -d /sys/class/typec/port1
+ test -r /sys/class/typec/port1/power_role
+ cat /sys/class/typec/port1/power_role
+ power_role=[sink]
+ + echo [sink]
grep -q \[source\]
+ + grep -qecho \[sink\] [sink]

+ USB_IS_SINK=yes
+ [ yes = yes ]
+ power_type=USB*
+ [ -d /sys/class/power_supply/ ]
+ test -d /sys/class/power_supply/ucsi-source-psy-USBC000:001
+ test -r /sys/class/power_supply/ucsi-source-psy-USBC000:001/type
+ cat /sys/class/power_supply/ucsi-source-psy-USBC000:001/type
+ type=USB
+ [ -r /sys/class/power_supply/ucsi-source-psy-USBC000:001/online ]
+ cat /sys/class/power_supply/ucsi-source-psy-USBC000:001/online
+ online=0
+ [ 0 = 1 ]
+ [ 0 = 0 ]
+ OFF_LINE_P=yes
+ test -d /sys/class/power_supply/ucsi-source-psy-USBC000:002
+ test -r /sys/class/power_supply/ucsi-source-psy-USBC000:002/type
+ cat /sys/class/power_supply/ucsi-source-psy-USBC000:002/type
+ type=USB
+ [ -r /sys/class/power_supply/ucsi-source-psy-USBC000:002/online ]
+ cat /sys/class/power_supply/ucsi-source-psy-USBC000:002/online
+ online=0
+ [ 0 = 1 ]
+ [ 0 = 0 ]
+ OFF_LINE_P=yes
+ [ yes = yes ]
+ exit 1

So the result is 1, meaning "not on mains power". Which is WRONG.
It seems that the /sys/class/power_supply directory no longer contains info on always-on AC power.

As I have noted (somewhere). The systemd code gets it roght.

[ganuc]: systemd-ac-power
[ganuc]: echo $?
0

Note that on_ac_power code *does* get the correct result on a laptop (where there is a battery to check).

But it gets the incorrect result when running on a system that only has AC power.

Thank you for the report @gordon-lack.

Could you run the systemd-ac-power command with SYSTEMD_LOG_LEVEL=debug?

$ SYSTEMD_LOG_LEVEL=debug systemd-ac-power

And share the logs printed on screen.

Thanks!

[ganuc]: SYSTEMD_LOG_LEVEL=debug systemd-ac-power
port0: The USB type-C port is in power sink mode.
port1: The USB type-C port is in power sink mode.
ucsi-source-psy-USBC000:001: The USB type-C device has at least one port in power sink mode.
ucsi-source-psy-USBC000:001: The power supply is currently offline.
port0: The USB type-C port is in power sink mode.
port1: The USB type-C port is in power sink mode.
ucsi-source-psy-USBC000:002: The USB type-C device has at least one port in power sink mode.
ucsi-source-psy-USBC000:002: The power supply is currently offline.
No power supply reported online and no discharging battery found, assuming system is running on AC.

In the absence of any other power supply, and with no battery, it assumes AC power is on.
So it's the (almost) default setting in on_ac_power which is incorrect.

Invert the logic?

Perhaps just look for any /sys/class/power_supply/BAT?/current_now that is non-zero?
If any found, it's running on battery.
Else it must be on a mains-supply.

=====
#!/bin/sh
#

cd /sys/class/power_supply || exit 255

for bd in BAT*; do
    [ -f "$bd"/current_now ] || continue
    bc=`cat "$bd"/current_now 2>/dev/null`
    [ "$bc" -gt 0 ] && exit 1 # Not on AC.
done
exit 0 # Is on AC
=====

Interesting, when fixing the script I relied on the mode the USB ports are in (which they should always be in source mode for a desktop machine but apparently each vendor does things differently).

The USB port being in sink mode means that it is configured to power the system and not power peripherals.

It seems that systemd devs were aware of this behavior in some machines and added an extra check that verifies battery status.

Currently on_ac_power has no such checks and completely ignores batteries.
I will update the script to also check for batteries and battery status before returning that the system is in offline mode.

Thanks!

All of my Intel NUcs report the type-C port being in sink mode.
None of them can be powered by a USB-C port.

Even plugging in an external drive leaves the system reporting them all in sink mode.

According to https://www.ti.com/lit/wp/slyy109b/slyy109b.pdf that is correct.
A sink is a port that will supply power to a peripheral.
A source is something that can "obtain" power for the system.

So I think you have your definitions reversed?

From the definition of the TI documentation page 3:

- A sink is a port that when attached consumes power from VBUS and a sink is most often a device. A sink could include USB peripherals such as a USB powered light or fan.

- A source is a port that when attached provides power over VBUS. Common sources are a host or hub DFP. An example of a source application is a USB Type-C wall charger.

The definitions are a bit confusing because when connecting two devices together, one port will be in sink and the other in source, so the definition needs to be read based on the perspective of the device being mentioned.

For example a webcam plugged in to the usb-c port of laptop, will have it's port in sink mode since power "sinks" to it from the laptop, but the laptop port will be in source mode since it is a "source" of power for the webcam.

When charging a laptop, it is the one consuming power so it's port is in sink mode while the usb charger will have it's port in source mode (a USB wall charger will always be a source of power).

Thus although a laptop's USB-C port will always be in source mode when a webcam or keyboard is plugged in to it, the webcam and the keyboard are called "sink" devices since their ports are in sink mode and the laptop will be the "source" device.

You can also confirm this view by looking at the systemd logs of systemd-ac-power, where it first verified that the port was in sink mode before checking if there was anything connected to it (they would have been ignored if they were in source mode). And when nothing was connected is did a fallback where it checked the battery status.

I have looked at systemd upstream and found an issue [1] mentioning that intel NUC devices have their ports in sink mode by default (none are in source mode), this lead to a PR [2] that added the battery check you saw when enabling the systemd logs

[1] https://github.com/systemd/systemd/issues/24214
[2] https://github.com/systemd/systemd/pull/24220

I will make sure to update the on_ac_power script to fulfill such scenarios similar to systemd ;)

I am just waiting for feedback from @racb first before working on it.

This is all veeeeery confusing. And making a mistake here can have drastic consequences, as was mentioned: unattended-upgrades can stop applying security updates.

I wonder if we wouldn't be in a better shape if we switched unattended-upgrades to use systemd-ac-power. That seems to be at least maintained (systemd), whereas powermgmt-base seems unmaintained.

Question to the reporter: does systemd-ac-power work correctly in the system you have where unpatched on_ac_power is incorrect?

>>> Question to the reporter: does systemd-ac-power work correctly in the system you have where unpatched on_ac_power is incorrect?

Yes. See #7, where I suggested this (once the systemd version was fixed).

Hello @ahasenack,

Using systemd-ac-power is only an option on noble and later releases since it is not available in earlier releases of systemd. So jammy and focal would not be able to make use of it.

This is the main reason I put time on getting the current script to work.

Another solution for unattended-upgrades is for it to not depend on external programs/libraries to determine the power state of a system and instead have it's own built in implementation. (I would happily work on implementing that!)

I find it more suitable for such a critical tool to depend as little as possible on external libraries especially when those are not guaranteed to be maintained.

There is also other packages that depend on on-ac-power that are not working as expected because of these issues.

Would it not be simpler to assume that on_ac_power is True unless you can find a working battery?

Not necessarily because not all systems might expose their battery through their ACPI table.

The reason there are so many checks is because not all systems have their firmware expose their components to the kernel.

Focal and Jammy (and Bionic) have /lib/systemd/systemd-ac-power:

# echo "$(grep VERSION= /etc/os-release) $(dpkg -S systemd-ac-power)"
VERSION="20.04.6 LTS (Focal Fossa)" systemd: /lib/systemd/systemd-ac-power

# echo "$(grep VERSION= /etc/os-release) $(dpkg -S systemd-ac-power)"
VERSION="22.04.3 LTS (Jammy Jellyfish)" systemd: /lib/systemd/systemd-ac-power

# echo "$(grep VERSION= /etc/os-release) $(dpkg -S systemd-ac-power)"
VERSION="18.04.6 LTS (Bionic Beaver)" systemd: /lib/systemd/systemd-ac-power

Interesting, on newer releases it's located in /bin and /usr/bin which explains why I missed it.

@ahasenack I can modify unattended upgrades to utilize systemd-ac-power, but this will also require me to backport any missing systemd-ac-power patches to it to make sure the script covers as many scenarios as possible.

However other applications that also depend on on_ac_power will still suffer from the same issue, (and this also does not resolve the actual package being broken).

Which solution would you prefer?

> @ahasenack I can modify unattended upgrades to utilize systemd-ac-power, but this will also require me to
> backport any missing systemd-ac-power patches to it to make sure the script covers as many scenarios as
> possible.

I rather have to SRU powermgmt-base for a on-power-detection issue or regression than systemd.

I have posted a new MR with the requested changes.
Let me know how it looks like!

I'm confused as to the status of this bug, as it's apparently fixed in Debian now, in 1.38, and this version was sync'd into plucky. But plucky has been reverted from fix released to in progress. Digging further...

Ah, I see: one version was merged and released (and indeed the fix was then subsequently sync'd from Debian) but this didn't fix the issue and, rather than open a new issue, this was re-opened. Anyway, I'll leave a further review on the pending merge for ubuntu/devel.

Well, if it's any help:

The status of powermgmt-base is:
    oracular has 1.37+nmu1ubuntu1
    plucky has 1.38

The /usr/sbin/on_ac_power script is identical in each of these.
And, although the debug trace is slightly different to that in #35, it still produces the WRONG RESULT on a system with no battery.
==========
[nuc]: sh -x /usr/sbin/on_ac_power
+ set -e
+ OFF_LINE_P=no
+ USB_IS_SINK=no
+ USB_IS_SOURCE=no
+ power_type=Mains
+ [ -d /sys/class/typec/ ]
+ test -d /sys/class/typec/port0
+ test -r /sys/class/typec/port0/power_role
+ cat /sys/class/typec/port0/power_role
+ power_role=source [sink]
+ echo source [sink]
+ grep -q \[source\]
+ echo source [sink]
+ grep -q \[sink\]
+ USB_IS_SINK=yes
+ [ yes = yes ]
+ power_type=USB*
+ [ -d /sys/class/power_supply/ ]
+ test -d /sys/class/power_supply/tps6598x-source-psy-i2c-INT3515:02-tps6598x.0
+ test -r /sys/class/power_supply/tps6598x-source-psy-i2c-INT3515:02-tps6598x.0/type
+ cat /sys/class/power_supply/tps6598x-source-psy-i2c-INT3515:02-tps6598x.0/type
+ type=USB
+ [ -r /sys/class/power_supply/tps6598x-source-psy-i2c-INT3515:02-tps6598x.0/online ]
+ cat /sys/class/power_supply/tps6598x-source-psy-i2c-INT3515:02-tps6598x.0/online
+ online=0
+ [ 0 = 1 ]
+ [ 0 = 0 ]
+ OFF_LINE_P=yes
+ [ yes = yes ]
+ exit 1
==========

So it is NOT fixed in 1.38. Nor anywhere else that I can see.

Looks like the bug is still there ;( I will unsubscribe Sponsors for the time being. Please feel free to resubscribe once it is ready to be sponsored.

@gordon-lack the battery fixes are not present in the Plucky release since they are still awaiting merger.
You can view the MR status here: https://code.launchpad.net/~ghadi-rahme/ubuntu/+source/powermgmt-base/+git/powermgmt-base/+merge/482635
I recommend applying the patch from this MR to on_ac_power and testing the script afterwards. If the system cannot detect the power status and there is no battery, the script should return 255 or even 0 if an online port was detected.

@vpa1977 as mentioned in the paragraph above there is an MR that is pending merger to resolve the issue.
Resubscribing sponsors.

>> I recommend applying the patch from this MR to on_ac_power and testing the script afterwards.

It now returns 255 (unknown), rather than 1 (not on mains).

So I can't see that this is any better than the currently broken script.

I would expect any current usage of this to take *any* non-zero result to be not on mains.

If you can't find a battery what else is the system running on? Surely it MUST be on mains!

@Gordon The main reason I did not make it the script return 0 when no battery is detected, is because the same way we fail to detect a power source although one exists, we might also be failing to detect a battery when one might also exist. Currently the 255 error code is handled as if you are on power in packages like unattended upgrades.
Not directly exiting the script with 0 on no battery gives us a chance to run the remaining methods the script has. These might be able to detect a power source and tell if it is online or offline. Otherwise 255 will be returned.

Having said so, systemd does ignore this case and considers a machine with no battery as directly online. So I have did the change now to emulate this behavior although it could mean that the reporting might be less accurate, I made sure that it will only return that the system is online if all other checks fail and a battery is not detected.

You can test the latest version of the MR and confirm if it is working as intended now on your system.

>> You can test the latest version of the MR and confirm if it is working as intended now on your system.

Yes it is now, thanks.

However:
1. lspower (part of the same package) is assuming that /bin/sh is a symlink to dash for the echo command on line 53. If you've set this (sh) to be a symlink to bash instead, then the escape sequences in the echo would need the "-e" option to work.
So line 1 needs to be #!/bin/dash, to make it independent off the user's choice.

2. Can Ubuntu systems run without systemd?
If not, why not just make on_ac_power be a symlink to /usr/bin/systemd-ac-power and only have one code ste to maintain?

This bug was fixed in the package powermgmt-base - 1.38ubuntu1

---------------
powermgmt-base (1.38ubuntu1) questing; urgency=medium

  * on_ac_power: improve reporting of AC power status in more scenarios
    (LP: #1980991)

 -- Ghadi Elie Rahme <email address hidden> Tue, 11 Mar 2025 17:49:39 +0000

Could the new patch be forwarded to Debian?

Unsubscribing ubuntu-sponsors as that seems to have been sponsored but is still in the queue

oracular is about to be EOL

Hello Kevin, or anyone else affected,

Accepted powermgmt-base into plucky-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/powermgmt-base/1.38ubuntu1~25.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-plucky to verification-done-plucky. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-plucky. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Hello Kevin, or anyone else affected,

Accepted powermgmt-base into noble-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/powermgmt-base/1.37ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-noble to verification-done-noble. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-noble. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Hello Kevin, or anyone else affected,

Accepted powermgmt-base into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/powermgmt-base/1.36ubuntu0.22.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Noble verification:

Installed package from proposed:
root@build-noble:~# apt list powermgmt-base
Listing... Done
powermgmt-base/noble-proposed,now 1.37ubuntu0.1 all [installed,automatic]

Running on_ac_power and unattended upgrades while connected to power:
root@build-noble:~# cat /sys/class/power_supply/AC/online
1

root@build-noble:~# on_ac_power

root@build-noble:~# echo $?
0

root@build-noble:~# unattended-upgrade --dry-run -v
Starting unattended upgrades script
Allowed origins are: o=Ubuntu,a=noble, o=Ubuntu,a=noble-security, o=UbuntuESMApps,a=noble-apps-security, o=UbuntuESM,a=noble-infra-security
Initial blacklist:
Initial whitelist (not strict):
No packages found that can be upgraded unattended and no pending auto-removals
The list of kept packages can't be calculated in dry-run mode.

We can see that the power state is correctly detected and that unattended upgrades does run.

Testing while on battery:
root@build-noble:~# cat /sys/class/power_supply/AC/online
0

root@build-noble:~# on_ac_power

root@build-noble:~# echo $?
1

root@build-noble:~# unattended-upgrade --dry-run -v
System is on battery power, stopping

The system correctly detects that it is running on battery and avoids running unattended-upgrades

Jammy verification:

Installed package from proposed:
root@build-jammy:~# apt list powermgmt-base
Listing... Done
powermgmt-base/jammy-proposed,now 1.36ubuntu0.22.04.1 all [installed,automatic]

Running on_ac_power and unattended upgrades while connected to power:

root@build-jammy:~# cat /sys/class/power_supply/AC/online
1

root@build-jammy:~# on_ac_power

root@build-jammy:~# echo $?
0

root@build-jammy:~# unattended-upgrade --dry-run -v
Starting unattended upgrades script
Allowed origins are: o=Ubuntu,a=jammy, o=Ubuntu,a=jammy-security, o=UbuntuESMApps,a=jammy-apps-security, o=UbuntuESM,a=jammy-infra-security
Initial blacklist:
Initial whitelist (not strict):
Removing unused kernel packages: linux-headers-5.15.0-143-generic linux-headers-5.15.0-143
Packages that were successfully auto-removed:
Packages that are kept back:
No packages found that can be upgraded unattended and no pending auto-removals
The list of kept packages can't be calculated in dry-run mode.

We can see that the power state is correctly detected and that unattended upgrades does run.

Test on battery:

root@build-jammy:~# cat /sys/class/power_supply/AC/online
0

root@build-jammy:~# on_ac_power
root@build-jammy:~# echo $?
1
root@build-jammy:~# unattended-upgrade --dry-run -v
System is on battery power, stopping

The system correctly detects that it is running on battery and avoids running unattended-upgrades

Plucky verification:

Installed package from proposed:
root@build-plucky:~# apt list powermgmt-base
powermgmt-base/plucky-proposed,now 1.38ubuntu1~25.04.1 all [installed,automatic]

Running on_ac_power and unattended upgrades while connected to power:

root@build-plucky:~# cat /sys/class/power_supply/AC/online
1

root@build-plucky:~# on_ac_power

root@build-plucky:~# echo $?
0

root@build-plucky:~# unattended-upgrade --dry-run -v
Starting unattended upgrades script
Allowed origins are: o=Ubuntu,a=plucky, o=Ubuntu,a=plucky-security, o=UbuntuESMApps,a=plucky-apps-security, o=UbuntuESM,a=plucky-infra-security
Initial blacklist:
Initial whitelist (not strict):
No packages found that can be upgraded unattended and no pending auto-removals
The list of kept packages can't be calculated in dry-run mode.

We can see that the power state is correctly detected and that unattended upgrades does run.

Test on battery:

root@build-plucky:~# cat /sys/class/power_supply/AC/online
0

root@build-plucky:~# on_ac_power

root@build-plucky:~# echo $?
1

root@build-plucky:~# unattended-upgrade --dry-run -v
System is on battery power, stopping

The system correctly detects that it is running on battery and avoids running unattended-upgrades

@seb128 Upstream Debian MR: https://salsa.debian.org/debian/powermgmt-base/-/merge_requests/4

Thanks for the verification of the test plan!

I have a question, though. The first part of the test plan says:

> 4. check the return value based on different scenarios:
> - plugged in using usb-c
> - plugged in using another non usb port
> - not plugged it at all
> - with a usb-c device plugged in that does not deliver power to the machine
> - with a graphics card or any other PCIE device that happen to have a usb-c port (this with and without
> a usb-c device connected to this extra port)

In your verification, you said only "...while connected to power" and "Test on battery", but it's not clear which of the cases above that is testing. At the very least, it doesn't seem to be testing all those connection possibilities (usb-c, another usb port, different usb-c devices regarding source/sink, etc). Could you please clarify, and/or perhaps perform the testing of those combinations?

I don't think it's necessary to repeat all those for the unattended-upgrades case: just the first part which checks the exit status of on_ac_power, since unattended-upgrades just cares about that, and this was tested already.

Hello @ahasenack,

The tests were done on my machine which has 4 USB-C thunderbolt ports that can all be used for charging, the only way to charge my machine is through these ports.

$ ls /sys/class/power_supply
AC BAT0 hidpp_battery_0 ucsi-source-psy-USBC000:001 ucsi-source-psy-USBC000:002 ucsi-source-psy-USBC000:003 ucsi-source-psy-USBC000:004

The AC directory is not a specific port on my machine but it inherits properties from any on the four USB-C ports.

$ cat ucsi-source-psy-USBC000:00*/online
0
0
1
0

$ cat AC/online
1

From the cases above, I tested "plugged in to usb-c" and "not plugged in at all"

I do have a desktop machine that I can run the test one, but the host is running CachyOS, so although I can test the packages in proposed in a container, the underlying kernel is different from the Ubuntu one, which is relevant in this case since we are testing against sysfs values.

I will run the tests on this desktop machine anyhow, and see if I can get access to another laptop that supports charging with a power barrel port and has a USB-C port.

Plucky verification on a desktop PC running in a lxc container running a non Ubuntu host :

root@plucky-builder:~# ls /sys/class/power_supply/

*directory is empty*

root@plucky-builder:~# apt list powermgmt-base
powermgmt-base/plucky-proposed,plucky-proposed,now 1.38ubuntu1~25.04.1 all [installed]
Notice: There is 1 additional version. Please use the '-a' switch to see it

root@plucky-builder:~# on_ac_power
root@plucky-builder:~# echo $?
0

Noble verification on a desktop PC running in a lxc container running a non Ubuntu host :

root@noble-builder:~# ls /sys/class/power_supply/

*directory is empty*

root@noble-builder:~# apt list powermgmt-base
Listing... Done
powermgmt-base/noble-proposed,noble-proposed,now 1.37ubuntu0.1 all [installed,automatic]
N: There are 2 additional versions. Please use the '-a' switch to see them.

root@noble-builder:~# on_ac_power

root@noble-builder:~# echo $?
0

Jammy verification on a desktop PC running in a lxc container running a non Ubuntu host:

root@jammy-builder:~# ls /sys/class/power_supply/

*directory is empty*

root@jammy-builder:~# apt list --installed powermgmt-base
Listing... Done
powermgmt-base/jammy-proposed,now 1.36ubuntu0.22.04.1 all [installed,upgradable to: 1.36ubuntu999]
N: There is 1 additional version. Please use the '-a' switch to see it

root@jammy-builder:~# on_ac_power

root@jammy-builder:~# echo $?
0

Hi Ghadi,

thanks for your efforts, but unfortunately since this bug involves both userspace and kernel, conducting the testing in an ubuntu lxc container while the host is not ubuntu at the release that is being tested is not valid.

Please note I'm merely asking to follow the test plan that was agreed upon when the package was first accepted: I'm not adding or changing the requirements here.

Plucky verification (ARM Ampere Altra server):
The verification is done in a plucky lxc container running on a Ubuntu 22.04 host. The machine is an ARM Ampere Altra server:

root@build-plucky:~# apt list powermgmt-base
powermgmt-base/plucky-proposed,now 1.38ubuntu1~25.04.1 all [installed]
Notice: There is 1 additional version. Please use the '-a' switch to see it
root@build-plucky:~# ls /sys/class/power_supply/
root@build-plucky:~# uname -r
5.15.0-151-generic
root@build-plucky:~# on_ac_power
root@build-plucky:~# echo $?
0

We can see that the script reports the proper power state (on AC) on a system with no battery.

Noble verification (ARM Ampere Altra server):
The verification is done in a Noble lxc container running on a Ubuntu 22.04 host. The machine is an ARM Ampere Altra server:

root@build-noble:~# apt list powermgmt-base
Listing... Done
powermgmt-base/noble-proposed,now 1.37ubuntu0.1 all [installed,automatic]
N: There is 1 additional version. Please use the '-a' switch to see it
root@build-noble:~# ls /sys/class/power_supply/
root@build-noble:~# uname -r
5.15.0-151-generic
root@build-noble:~# on_ac_power
root@build-noble:~# echo $?
0

We can see that the script reports the proper power state (on AC) on a system with no battery.

Jammy verification (ARM Ampere Altra server):
The verification is done in a Jammy lxc container running on a Ubuntu 22.04 host. The machine is an ARM Ampere Altra server:

root@build-jammy:~# apt list powermgmt-base
Listing... Done
powermgmt-base/jammy-proposed,now 1.36ubuntu0.22.04.1 all [installed,automatic]
N: There is 1 additional version. Please use the '-a' switch to see it
root@build-jammy:~# ls /sys/class/power_supply/
root@build-jammy:~# uname -r
5.15.0-151-generic
root@build-jammy:~# on_ac_power
root@build-jammy:~# echo $?
0

We can see that the script reports the proper power state (on AC) on a system with no battery.

Hi,

I tested the proposed packages on Jammy, Noble, Plucky on a laptop with barrel jack power cord
All packages work as expected

```
_____JAMMY

ubuntu@node2:~$ dpkg -l | grep powermgmt-base
ii powermgmt-base 1.36 all common utils for power management

root@node2:~# apt-cache madison powermgmt-base
powermgmt-base | 1.36ubuntu0.22.04.1 | http://archive.ubuntu.com/ubuntu jammy-proposed/main amd64 Packages
powermgmt-base | 1.36ubuntu0.22.04.1 | http://archive.ubuntu.com/ubuntu jammy-proposed/main i386 Packages
powermgmt-base | 1.36 | http://hu.archive.ubuntu.com/ubuntu jammy/main amd64 Packages
powermgmt-base | 1.36 | http://hu.archive.ubuntu.com/ubuntu jammy/main i386 Packages

sudo apt install powermgmt-base

ubuntu@node2:~$ dpkg -l | grep powermgmt-base
ii powermgmt-base 1.36ubuntu0.22.04.1 all common utils for power management

____laptop plugged in to power source
root@node2:~# on_ac_power
root@node2:~# echo $?
0

____laptop disconnected from power source
root@node2:~# on_ac_power
root@node2:~# echo $?
1
```

```
_____NOBLE

ubuntu@node3:~$ dpkg -l | grep powermgmt-base
ii powermgmt-base 1.37 all common utils for power management

ubuntu@node3:~$ apt-cache madison powermgmt-base
powermgmt-base | 1.37ubuntu0.1 | http://archive.ubuntu.com/ubuntu noble-proposed/main amd64 Packages
powermgmt-base | 1.37 | http://archive.ubuntu.com/ubuntu noble/main amd64 Packages
powermgmt-base | 1.37 | http://archive.ubuntu.com/ubuntu noble/main Sources
powermgmt-base | 1.37ubuntu0.1 | http://archive.ubuntu.com/ubuntu noble-proposed/main Sources

sudo apt install powermgmt-base=1.37ubuntu0.1

ubuntu@node3:~$ dpkg -l | grep powermgmt-base
ii powermgmt-base 1.37ubuntu0.1 all common utils for power management

____laptop plugged in to power source
root@node3:~# on_ac_power
root@node3:~# echo $?
0

____laptop disconnected from power source
root@node3:~# on_ac_power
root@node3:~# echo $?
1
```

```
_____PLUCKY

ubuntu@node3:~$ dpkg -l | grep powermgmt-base
ii powermgmt-base 1.38 all common utils for power management

ubuntu@node3:~$ apt-cache madison powermgmt-base
powermgmt-base | 1.38ubuntu1~25.04.1 | http://archive.ubuntu.com/ubuntu plucky-proposed/main amd64 Packages
powermgmt-base | 1.38ubuntu1~25.04.1 | http://archive.ubuntu.com/ubuntu plucky-proposed/main i386 Packages
powermgmt-base | 1.38 | http://archive.ubuntu.com/ubuntu plucky/main amd64 Packages
powermgmt-base | 1.38 | http://archive.ubuntu.com/ubuntu plucky/main i386 Packages

sudo apt install powermgmt-base=1.38ubuntu1~25.04.1

ubuntu@node3:~$ dpkg -l | grep powermgmt-base
ii powermgmt-base 1.38ubuntu1~25.04.1 all common utils for power management

____lap...

thank you for the verification @Szilard!

Ubuntu 24.04.x as of today has the same bug on HP EliteDesk 800 G4 which does not have any battery. There is no available updates so far.

Okay, proposed 1.37ubuntu0.1 indeed works in my case too. Please, make it an official update (see my previous comment).

This bug was fixed in the package powermgmt-base - 1.38ubuntu1~25.04.1

---------------
powermgmt-base (1.38ubuntu1~25.04.1) plucky; urgency=medium

  * on_ac_power: improve reporting of AC power status in more scenarios
    (LP: #1980991)

 -- Ghadi Elie Rahme <email address hidden> Wed, 04 Jun 2025 12:08:42 +0000

The verification of the Stable Release Update for powermgmt-base has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package powermgmt-base - 1.37ubuntu0.1

---------------
powermgmt-base (1.37ubuntu0.1) noble; urgency=medium

  * Fix on_ac_power incorrectly reporting AC state on some
    machines with USB type-C ports (LP: #1980991).
  * on_ac_power: improve reporting of AC power status in more scenarios
    (LP: #1980991)

 -- Ghadi Elie Rahme <email address hidden> Wed, 04 Jun 2025 14:29:58 +0000

This bug was fixed in the package powermgmt-base - 1.36ubuntu0.22.04.1

---------------
powermgmt-base (1.36ubuntu0.22.04.1) jammy; urgency=medium

  * Fix on_ac_power incorrectly reporting AC state on some
    machines with USB type-C ports (LP: #1980991).
  * on_ac_power: improve reporting of AC power status in more scenarios
    (LP: #1980991)

 -- Ghadi Elie Rahme <email address hidden> Wed, 04 Jun 2025 14:47:30 +0000