[Bug 1980991] Re: /usr/sbin/on_ac_power incorrectly reporting ac power status

[Ghadi Rahme]

>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

** Bug watch added: github.com/systemd/systemd/issues #24214
   https://github.com/systemd/systemd/issues/24214

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1980991

Title:
  /usr/sbin/on_ac_power incorrectly reporting ac power status

Status in powermgmt-base package in Ubuntu:
  Fix Released
Status in powermgmt-base source package in Focal:
  Incomplete
Status in powermgmt-base source package in Jammy:
  Incomplete
Status in powermgmt-base source package in Kinetic:
  Won't Fix
Status in powermgmt-base source package in Lunar:
  Won't Fix
Status in powermgmt-base source package in Mantic:
  Won't Fix
Status in powermgmt-base source package in Noble:
  Incomplete
Status in powermgmt-base source package in Oracular:
  Fix Released
Status in powermgmt-base package in Debian:
  New

Bug description:
  Thank you @kevintate for the original bug report.

  [Impact]

  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 is because the script does not check first if these usb-c ports are in sink or source mode first.
  The solution is to check /sys/class/typec/* for the mode these usb ports are in, and ignore them if none of them are running in source mode.
  This is causing tools such as unattended-upgrades to fail to run because on_ac_power is miss reporting the power state of the machine.  

  [Test Plan]

  Part 1: Verifying if the script returns the correct result

  On a device with a USB-c port (it does not matter if the port can be
  used for powering the device or not) run the following test:

  1. Install the patched version of on_ac_power

  2. run: $ on_ac_power

  3. check the return value: $ echo $?

  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)

  compare the return value with the actual state of the machine. If the
  machine is not plugged in to power, you should expect 0 as the return
  code.

  If the machine is plugged in then the return code should be 1.

  If you receive 255 as an return code then the script was unable to
  determine the power profile of the machine and is related to the
  kernel not exposing enough information to user space. Consumers of
  on_ac_power generally consider such a return code as the machine being
  plugged in to power.

  Part2: verifying that no regressions exist with consumers such as
  unattended-upgrades

  One such consumer is unattended-upgrades. To verify if unattended
  upgrades is still affected by this issue, run the following steps:

  1. first make sure unattended upgrades is installed:
  $ sudo apt install unattended-upgrades

  2. using the default config run the following command under different power scenarios:
  $ sudo unattended-upgrade --dry-run -v
  The different power scenarios to test for are:
  - 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)

  3. Make sure that the command above returns the correct result for
  each status, for example when the machine is expected to be on main
  power, the following output should be returned:

  ghadi at XPS-17-9720 ~ » sudo unattended-upgrades --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.

  If the machine is not getting power from main but from it's battery,
  the following output should be seen:

  ghadi at XPS-17-9720 ~ » sudo unattended-upgrades --dry-run -v
  System is on battery power, stopping

  Part3: Test plan conclusions

  If the tests done in part 1 fail, this would mean that the proposed fix was not enough to resolve the issue. 
  If part 2 fails but part 1 passes, further investigations are needed into unattended-upgrades for why it's result might differ from on_ac_power.

  [Where problems could occur]

  * the script could still incorrectly return the state of power of the machine, specially if the kernel incorrectly advertises a usbc port to be in a different mode then it is in.
  * Packages that depend on on_ac_power might fail to run or execute if they require the machine to be in a specific power state first, unattended-upgrades and anacron are two example packages.

  [Original Description]
  Good afternoon, folks.

  I believe I discovered a bug in the /usr/sbin/on_ac_power script. I
  have a Dell OptiPlex 5090 host that has an entry in
  /sys/class/power_supply for "ucsi-source-psy-USBC000:001". I believe
  this is the USB-C power delivery port on the front of the chassis. The
  issue I'm encountering is that /usr/sbin/on_ac_power is exiting with
  code 1 which states: (1 (false) if not on AC power) when that isn't
  the case.

  This looks to be because of the ucsi-source-psy-USBC000:001 entry
  reporting the "online" status as 0, presumably because nothing is
  currently connected to that USB-C port.

  This causes /usr/sbin/on_ac_power to incorrectly report that the
  machine isn't connected to AC power and causes other utilities like
  unattended-upgrades to quit when using the default configuration since
  it believes the machine isn't connected to AC power.

  There is a workaround with unattended-upgrades where you can specify
  it to run regardless of if AC power is connected, but as more and more
  chassis implement power-delivery USB-C ports I foresee this becoming
  more of an issue.

  I'm not sure if it's anything to look into, but I figured I would
  share my findings. Please let me know if you have any questions or if
  I can provide any additional information, troubleshooting, or testing.

  Thanks!
  -Kevin

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/powermgmt-base/+bug/1980991/+subscriptions