transactional-update.service goes into standby instead of failing to start if laptop isn't plugged in

[SharkPlush]

Currently if transactional-update.service gets triggered and the laptop isn't plugged in the service will just fail. The problem with this is the service gets triggered between 12:00 - 02:00 AM when most users are sleeping. So when they wake up their device in the morning and it's not plugged in the service auto fails.

Some people don't plug in their devices before bed. Primary reason is to save preserve battery health.

Below I'll provide a a hypothetical.

User schedule:

• Goes to sleep at 10:00 PM (laptop unplugged)
• transactional-update.timer "triggers" in the background between 12:00 - 02:00 AM (I understand it doesn't actually trigger but when the laptop wakes up the timer sees time as passed and will trigger)
• User wakes up the laptop at 09:00 AM (laptop is still unplugged)
• transactional-update.service sees laptop is unplugged and will fail to update.

If the user lives on this schedule consistently the laptop will never auto update.

So instead of outright failing, the timer should get triggered like normal and if the services sees the laptop is unplugged it goes into standby waiting for a charger to be plugged in to update Aeon.

Currently (at least to my knowledge) systemd doesn't have a system to detect if the laptop is charging but tik does. Is it possible to take the charging detection system from tik and combine it with the systemd service?

[SharkPlush]

I realized that if there is a system where it's checking to see if the laptop is charging it will probably waste more battery over the course of a day than just allowing updates on battery life.

So it will have to be done in such way where once AC power is in it tells the service to start an update.

Basically instead of the service going "hey are you plugged in yet?" every few minutes, something else tells the service "I'm plugged in now, if you were waiting for that you can start updating"

That way there won't be unnecessary battery drain.

[sysrich]

Maybe the ConditionACPower= is actually on the wrong systemd unit

I THINK if we moved ConditionACPower=true from transactional-update.service to transactional-update.timer we'd result in the following behaviour

• Goes to sleep at 10:00PM (laptop unplugged)
• transactional-update.timer passes it's trigger time
• User wakes up the laptop at 09:00AM (laptop is still unplugged)
• transactioanl-update.service is NOT triggered, as it's still unplugged

Now, I'm not sure if it'll magically trigger when you plug it in..I'm not sure if the Persistant= on the .timer is that smart

But at least it would stop the .service triggering and failing

Anyone feels like experimenting with this to take a look?

[SharkPlush]

I'll do a test here is what I've done to the service files if you want to double check.

Aeon@localhost:~> cat /etc/systemd/system/transactional-update.service.d/override.conf 
[Unit]
ConditionACPower=
Aeon@localhost:~> cat /etc/systemd/system/transactional-update.timer.d/override.conf 
[Unit]
ConditionACPower=true

[SharkPlush]

It says condition unmet, and after plugging in the laptop stays that way.

Aeon@localhost:~> sudo systemctl status transactional-update.timer 
○ transactional-update.timer - Daily update of the system
     Loaded: loaded (/usr/lib/systemd/system/transactional-update.timer; enabled; preset: enabled)
    Drop-In: /etc/systemd/system/transactional-update.timer.d
             └─override.conf
     Active: inactive (dead)
    Trigger: n/a
   Triggers: ● transactional-update.service
  Condition: start condition unmet at Fri 2025-09-26 04:20:11 EEST; 3min 48s ago
             └─ ConditionACPower=true was not met
       Docs: man:transactional-update(8)

Sep 26 04:20:11 localhost.localdomain systemd[1]: Daily update of the system was skipped because of an unmet condition check (ConditionACPower=true).

[SharkPlush]

Never really coded anything before so apologizing if something is incorrect or just low quality! But I've done quick tests with this script on my laptop and it seems to work well. I haven't tested the laptop detection system (taken from tik) because I don't have a PC but I think it should be fine.

Having this wrapper replace the current systemd service ExecStart= and removing the ConditionACPower= should work.

If systemd service triggers and the user doesn't plug in the laptop till the next trigger I have no idea what will happen.

At the moment the script works but it's more of a draft and I believe it can be made more robust, accurate and simpler alongside testing with what happens when the device goes to sleep and how the script handles that which I'll attempt to do.

And of course the part I'm most proud and excited of is there is no polling (I hope) so no extra battery drain.

#!/bin/bash

# THE UPDATE COMMAND
tu_dup() {
    transactional-update cleanup dup reboot
}

# DETECT IF DEVICE IS A LAPTOP
CHASSIS=`cat /sys/class/dmi/id/chassis_type`
  if [[ "$CHASSIS" =~ ^(8|9|10|11)$ ]]; then
  
  # IF A LAPTOP IS DETECTED THEN WE CHECK IF THE BATTERY IS ON AC OR NOT
  STATE=`upower -i /org/freedesktop/UPower/devices/battery_BAT0 | awk '/state:/ {print $2}'`
  
  # IF THE DEVICE ISN'T A LAPTOP IT GET THE NO_BATTERY STATE
  else STATE="NO_BATTERY"
  
fi

# IF DEVICE ISN'T A LAPTOP, JUST UPDATE
if [[ "$STATE" == "NO_BATTERY" ]]; then
    tu_dup
    
# IF THE DEVICE IS LAPTOP WE CHECK WHAT BATTERY STATE WAS RECORDED, IF AC WAS PLUGGED IN WE UPDATE
else
  if [[ "$STATE" =~ ^(charging|pending-charge|fully-charged)$ ]]; then
  tu_dup
  
# IF THE LAPTOP WASN'T PLUGGED INTO AC WE WAIT FOR AC
else
  echo "Waiting for AC power"
  gdbus monitor --system --dest org.freedesktop.UPower --object-path /org/freedesktop/UPower/devices/battery_BAT0 | grep -m1 --line-buffered -oE "'State': <uint32 [^>]+>" | while read -r line; do

  # ONCE AC IS DETECTED THE UPDATE TRIGGERS
  if [[ "$line" =~ ("'State': <uint32 1>"|"'State': <uint32 4>"|"'State': <uint32 5>") ]]; then
  tu_dup
  
  # GDBUS HAS TO BE KILLED FOR THE SCRIPT TO EXIT BUT I DON'T LIKE THIS SOLUTION
  pkill -P $$ gdbus
  
  break
  
fi
done
fi
fi

EDIT:

https://github.com/SharkPlush/Aeon-AC-update-detection

I improved it some more if you like it feel free to take it and remix it however you want I'd love to see something like this in the base system rather than a third party addon.