Check systemd's Battery Gate Before Early Boot Powers Off

You will finish with a reliable way to inspect systemd-battery-check.service, understand why it may stop a machine during early boot, and bypass that check for one boot when the hardware detection is wrong. The examples match systemd 255.4-1ubuntu8.17 installed on this machine.

Allow about fifteen minutes. You need a shell and, for persistent boot-loader changes, administrator access. The read-only inspection steps do not need elevated privileges. Do not test the service by starting it casually: its unit has FailureAction=poweroff-force, which can power the machine off if the check fails.

1. Confirm the installed command and version

Start with the ordinary, read-only checks. They show which package and executable your commands refer to:

$ dpkg-query -W -f='${Package} ${Version}
' systemd
systemd 255.4-1ubuntu8.17
$ /usr/lib/systemd/systemd-battery-check --version
systemd 255 (255.4-1ubuntu8.17)

The binary is normally /usr/lib/systemd/systemd-battery-check. It accepts only --help and --version as command-line options in this installed release. The useful battery decision is made by running it without either option.

2. Read the unit without starting it

Inspect the unit definition:

$ systemctl cat systemd-battery-check.service
# /usr/lib/systemd/system/systemd-battery-check.service
[Unit]
Description=Check battery level during early boot
ConditionVirtualization=no
ConditionDirectoryNotEmpty=/sys/class/power_supply/
ConditionKernelCommandLine=!systemd.battery-check=0
AssertPathExists=/etc/initrd-release
DefaultDependencies=no
...
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/lib/systemd/systemd-battery-check
FailureAction=poweroff-force

Three details explain most surprises. The service is intended for the initial RAM disk, so /etc/initrd-release must exist in that environment. It is skipped when systemd detects virtualisation or no power-supply directory. It is also skipped when the kernel command line contains systemd.battery-check=0. These are conditions, not settings that you should edit in the unit file.

The unit is Type=oneshot and remains active after a successful run. It has no ordinary enablement workflow: on a normal installation systemctl is-enabled reports static. Early-boot generator or initrd packaging determines whether it is present in the boot transaction.

3. Check the service state safely

Ask systemd to report the unit's current state. This does not start, stop or reload anything:

$ systemctl show systemd-battery-check.service \
    -p FragmentPath -p Type -p ExecStart -p FailureAction \
    -p ConditionResult -p AssertResult -p ActiveState -p SubState
Type=oneshot
ExecStart={ path=/usr/lib/systemd/systemd-battery-check ; ... }
FailureAction=poweroff-force
ActiveState=inactive
SubState=dead

On a running host, ConditionResult=no or AssertResult=no means systemd did not run the service because an environmental requirement was not met. That is different from a battery failure. Use systemctl status systemd-battery-check.service for a more readable explanation, and inspect the initrd's unit state when diagnosing an actual boot.

Distraction trap: a missing or empty /sys/class/power_supply/ on a virtual machine tells you that this boot environment is not a useful reproduction of a physical laptop. Do not infer the laptop's battery policy from that result.

4. Understand the pass and fail decision

Run the executable directly only as a controlled diagnostic, never as a substitute for understanding the unit's power-off action. The command returns success when it sees AC power or a battery charge above 5 percent. It returns a non-zero status otherwise:

$ /usr/lib/systemd/systemd-battery-check
$ status=$?
$ printf 'battery check exit status: %s\n' "$status"
battery check exit status: 0

The command normally prints no status report, so capture $? immediately. A zero here means the command's check passed for the power-supply data visible to that process. It does not mean the battery is healthy, that the charger will remain connected, or that the service was part of this boot.

Do not run systemctl start systemd-battery-check.service on a machine you cannot afford to lose. If it fails, systemd is explicitly instructed to force power-off. If you accidentally start it and it succeeds, no persistent configuration has changed, but the oneshot unit may remain active until the next boot.

5. Bypass a false detection for one boot

When the check misreads the battery or AC state, add the exact kernel parameter systemd.battery-check=0 to one boot entry. This makes the program return success immediately and lets the service succeed without checking capacity or AC power.

At a graphical boot menu, edit the selected entry temporarily and append this parameter to the kernel command line. The exact key varies by boot loader. Remove it before the next boot unless you deliberately need the bypass again. This is a boot-time, security-relevant decision: it removes a low-battery protection, so connect external power before continuing.

After boot, verify what the kernel actually received:

$ tr ' ' '\n' < /proc/cmdline | grep '^systemd\.battery-check='
systemd.battery-check=0

No output means the temporary edit was not applied. Do not treat an absent result as proof that the service ran; it only says that this particular override is not in the current command line.

6. Make the override persistent only if you accept the trade-off

A persistent override belongs in the boot-loader configuration, not in a copied unit file. Use your distribution's boot-loader tooling and record the original kernel command line first. For a GRUB-based system, inspect the current setting before editing:

$ grep '^GRUB_CMDLINE_LINUX' /etc/default/grub

Editing /etc/default/grub and rebuilding its menu requires elevated privileges and affects future boots. The command differs by distribution, so do not paste a guessed update command from another system. If you do make this change, keep the parameter inside the existing quoted kernel-argument value, rebuild the boot-loader configuration using your distribution's documented command, reboot once, and check /proc/cmdline as above.

To undo the change, remove only systemd.battery-check=0 from the same kernel-argument setting, rebuild the boot-loader configuration again, and verify that the parameter is absent after reboot. Do not delete the whole line: it may contain unrelated boot and security settings.