systemd service fails to run with "ConditionACPower=true was not met"

[Richard W.M. Jones]

Fedora 36, plocate-1.1.15-3.fc36.x86_64, systemd-250.8-1.fc36.x86_64

/usr/lib/systemd/system/plocate-updatedb.service has
ConditionACPower=true because they don't want updatedb to run
when on a laptop battery.

Now, my machine is an Intel NUC which has an Intel mobile chipset but
is very definitely not a laptop.  It doesn't have a battery and always
runs off AC power.

But ...

  $ sudo systemctl status plocate-updatedb.service |& cat
  ○ plocate-updatedb.service - Update the plocate database
       Loaded: loaded (/usr/lib/systemd/system/plocate-updatedb.service; static)
       Active: inactive (dead)
  TriggeredBy: ● plocate-updatedb.timer
    Condition: start condition failed at Fri 2022-08-05 10:29:57 BST; 5min ago
               └─ ConditionACPower=true was not met

  Aug 03 14:59:37 dev5 systemd[1]: plocate-updatedb.service - Update the plocate database
was skipped because of a failed condition check (ConditionACPower=true).
  Aug 04 09:29:21 dev5 systemd[1]: plocate-updatedb.service - Update the plocate database
was skipped because of a failed condition check (ConditionACPower=true).
  Aug 05 10:29:35 dev5 systemd[1]: plocate-updatedb.service - Update the plocate database
was skipped because of a failed condition check (ConditionACPower=true).
  Aug 05 10:29:57 dev5 systemd[1]: plocate-updatedb.service - Update the plocate database
was skipped because of a failed condition check (ConditionACPower=true).

Looking at systemd sources it seems as if ConditionACPower is checked
here:

 
https://github.com/systemd/systemd/blob/14e7bc2e77d2699498a1f74d7e4f905f1...

It's a bit hard to follow what the code is doing, but I think it's
looking in /sys for power_supply devices.  This hardware has two, both
with type == USB.  (I believe these are the two USB ports on the front
panel that can provide power to other devices, they cannot power the
machine itself.)

  $ ll /sys/devices/platform/USBC000:00/power_supply
  total 0
  drwxr-xr-x. 5 root root 0 Aug  3 09:00 ucsi-source-psy-USBC000:001
  drwxr-xr-x. 5 root root 0 Aug  3 09:00 ucsi-source-psy-USBC000:002
  $ cat /sys/devices/platform/USBC000:00/power_supply/*/type
  USB
  USB

  $ cat
/sys/devices/platform/USBC000\:00/power_supply/ucsi-source-psy-USBC000\:00*/device/typec/port*/power_role

  [sink]
  [sink]
  [sink]
  [sink]

  $ cat
/sys/devices/platform/USBC000\:00/power_supply/ucsi-source-psy-USBC000\:00*/online
  0
  0

Anyway, I think this is a systemd bug, right?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

[Barry]

>  On 5 Aug 2022, at 10:48, Richard W.M. Jones <rjones(a)redhat.com&gt;
> wrote:
>  
>  Fedora 36, plocate-1.1.15-3.fc36.x86_64, systemd-250.8-1.fc36.x86_64
>  
>  /usr/lib/systemd/system/plocate-updatedb.service has
>  ConditionACPower=true because they don't want updatedb to run
>  when on a laptop battery.
>  
>  Now, my machine is an Intel NUC which has an Intel mobile chipset but
>  is very definitely not a laptop.  It doesn't have a battery and always
>  runs off AC power.
>  
>  But ...
>  
>   $ sudo systemctl status plocate-updatedb.service |& cat
>   ○ plocate-updatedb.service - Update the plocate database
>        Loaded: loaded (/usr/lib/systemd/system/plocate-updatedb.service; static)
>        Active: inactive (dead)
>   TriggeredBy: ● plocate-updatedb.timer
>     Condition: start condition failed at Fri 2022-08-05 10:29:57 BST; 5min ago
>                └─ ConditionACPower=true was not met
>  
>   Aug 03 14:59:37 dev5 systemd[1]: plocate-updatedb.service - Update the plocate database
> was skipped because of a failed condition check (ConditionACPower=true).
>   Aug 04 09:29:21 dev5 systemd[1]: plocate-updatedb.service - Update the plocate database
> was skipped because of a failed condition check (ConditionACPower=true).
>   Aug 05 10:29:35 dev5 systemd[1]: plocate-updatedb.service - Update the plocate database
> was skipped because of a failed condition check (ConditionACPower=true).
>   Aug 05 10:29:57 dev5 systemd[1]: plocate-updatedb.service - Update the plocate database
> was skipped because of a failed condition check (ConditionACPower=true).
>  
>  Looking at systemd sources it seems as if ConditionACPower is checked
>  here:
>  
>  
> https://github.com/systemd/systemd/blob/14e7bc2e77d2699498a1f74d7e4f905f1...
>  
>  It's a bit hard to follow what the code is doing, but I think it's
>  looking in /sys for power_supply devices.  This hardware has two, both
>  with type == USB.  (I believe these are the two USB ports on the front
>  panel that can provide power to other devices, they cannot power the
>  machine itself.)
>  
>   $ ll /sys/devices/platform/USBC000:00/power_supply
>   total 0
>   drwxr-xr-x. 5 root root 0 Aug  3 09:00 ucsi-source-psy-USBC000:001
>   drwxr-xr-x. 5 root root 0 Aug  3 09:00 ucsi-source-psy-USBC000:002
>   $ cat /sys/devices/platform/USBC000:00/power_supply/*/type
>   USB
>   USB
>  
>   $ cat
> /sys/devices/platform/USBC000\:00/power_supply/ucsi-source-psy-USBC000\:00*/device/typec/port*/power_role
>
>   [sink]
>   [sink]
>   [sink]
>   [sink]
>  
>   $ cat
> /sys/devices/platform/USBC000\:00/power_supply/ucsi-source-psy-USBC000\:00*/online
>   0
>   0
>  
>  Anyway, I think this is a systemd bug, right? 
That code has lots of debug logs. Try running systemd with log level debug and see which
of those logs is printed.

Barry

>  
>  Rich.
>  
>  -- 
>  Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
>  Read my programming and virtualization blog: http://rwmj.wordpress.com
>  virt-top is 'top' for virtual machines.  Tiny program with many
>  powerful monitoring features, net stats, disk stats, logging, etc.
>  http://people.redhat.com/~rjones/virt-top
>  _______________________________________________
>  users mailing list -- users(a)lists.fedoraproject.org
>  To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Richard W.M. Jones]

On Fri, Aug 05, 2022 at 11:36:13AM +0100, Barry wrote:
>  
>  
>  > On 5 Aug 2022, at 10:48, Richard W.M. Jones <rjones(a)redhat.com&gt; wrote:
>  > 
>  > Fedora 36, plocate-1.1.15-3.fc36.x86_64, systemd-250.8-1.fc36.x86_64
>  > 
>  > /usr/lib/systemd/system/plocate-updatedb.service has
>  > ConditionACPower=true because they don't want updatedb to run
>  > when on a laptop battery.
>  > 
>  > Now, my machine is an Intel NUC which has an Intel mobile chipset but
>  > is very definitely not a laptop.  It doesn't have a battery and always
>  > runs off AC power.
>  > 
>  > But ...
>  > 
>  >  $ sudo systemctl status plocate-updatedb.service |& cat
>  >  ○ plocate-updatedb.service - Update the plocate database
>  >       Loaded: loaded (/usr/lib/systemd/system/plocate-updatedb.service; static)
>  >       Active: inactive (dead)
>  >  TriggeredBy: ● plocate-updatedb.timer
>  >    Condition: start condition failed at Fri 2022-08-05 10:29:57 BST; 5min ago
>  >               └─ ConditionACPower=true was not met
>  > 
>  >  Aug 03 14:59:37 dev5 systemd[1]: plocate-updatedb.service - Update the plocate
> database was skipped because of a failed condition check (ConditionACPower=true).
>  >  Aug 04 09:29:21 dev5 systemd[1]: plocate-updatedb.service - Update the plocate
> database was skipped because of a failed condition check (ConditionACPower=true).
>  >  Aug 05 10:29:35 dev5 systemd[1]: plocate-updatedb.service - Update the plocate
> database was skipped because of a failed condition check (ConditionACPower=true).
>  >  Aug 05 10:29:57 dev5 systemd[1]: plocate-updatedb.service - Update the plocate
> database was skipped because of a failed condition check (ConditionACPower=true).
>  > 
>  > Looking at systemd sources it seems as if ConditionACPower is checked
>  > here:
>  > 
>  > 
> https://github.com/systemd/systemd/blob/14e7bc2e77d2699498a1f74d7e4f905f1...
>  > 
>  > It's a bit hard to follow what the code is doing, but I think it's
>  > looking in /sys for power_supply devices.  This hardware has two, both
>  > with type == USB.  (I believe these are the two USB ports on the front
>  > panel that can provide power to other devices, they cannot power the
>  > machine itself.)
>  > 
>  >  $ ll /sys/devices/platform/USBC000:00/power_supply
>  >  total 0
>  >  drwxr-xr-x. 5 root root 0 Aug  3 09:00 ucsi-source-psy-USBC000:001
>  >  drwxr-xr-x. 5 root root 0 Aug  3 09:00 ucsi-source-psy-USBC000:002
>  >  $ cat /sys/devices/platform/USBC000:00/power_supply/*/type
>  >  USB
>  >  USB
>  > 
>  >  $ cat
> /sys/devices/platform/USBC000\:00/power_supply/ucsi-source-psy-USBC000\:00*/device/typec/port*/power_role
>
>  >  [sink]
>  >  [sink]
>  >  [sink]
>  >  [sink]
>  > 
>  >  $ cat
> /sys/devices/platform/USBC000\:00/power_supply/ucsi-source-psy-USBC000\:00*/online
>  >  0
>  >  0
>  > 
>  > Anyway, I think this is a systemd bug, right?
>  
>  That code has lots of debug logs. Try running systemd with log level debug and see which
> of those logs is printed. 
Good idea ...

# systemd-analyze set-log-level debug
# systemctl start plocate-updatedb.service 
# journalctl

The relevant section is attached in full.

It seems as if the code only finds the USB ports, they are all in
"sink" mode, it doesn't find any other power_supply devices so it
assumes battery?  There seem to be at least two things wrong here -
the USB ports are not "sinks" and there are no other power supply
devices.

I think this is a systemd bug.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

[Richard W.M. Jones]

On Fri, Aug 05, 2022 at 12:16:46PM +0100, Richard W.M. Jones wrote:
>  I think this is a systemd bug. 
It seems like the source/sink check was added recently to fix:

https://github.com/systemd/systemd/issues/21988

but that the fix is either wrong or incomplete.

Here's another interesting related bug:

https://github.com/systemd/systemd/issues/20964

I have filed a new bug for this:

https://github.com/systemd/systemd/issues/24214

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

[Barry]

>  On 5 Aug 2022, at 12:27, Richard W.M. Jones <rjones(a)redhat.com&gt;
> wrote:
>  
>  On Fri, Aug 05, 2022 at 12:16:46PM +0100, Richard W.M. Jones wrote:
> > I think this is a systemd bug.
>  
>  It seems like the source/sink check was added recently to fix:
>  
>  https://github.com/systemd/systemd/issues/21988
>  
>  but that the fix is either wrong or incomplete.
>  
>  Here's another interesting related bug:
>  
>  https://github.com/systemd/systemd/issues/20964
>  
>  I have filed a new bug for this:
>  
>  https://github.com/systemd/systemd/issues/24214
>   
Sounds like it’s worth taking this to the systemd list.
I think you have two questions:
Why does the code no power surprise means battery and not mains power?
Why is the the usb code getting the usb direction wrong?

Barry


>  Rich.
>  
>  -- 
>  Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
>  Read my programming and virtualization blog: http://rwmj.wordpress.com
>  libguestfs lets you edit virtual machines.  Supports shell scripting,
>  bindings from many languages.  http://libguestfs.org
>  _______________________________________________
>  users mailing list -- users(a)lists.fedoraproject.org
>  To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue