Synopsis #
OpenBSD exposes battery state and sleep controls through apm(8) and coordinates power events through apmd(8) . Hardware and firmware determine which power states work. This guide establishes automatic performance adjustment, tests suspend and resume, and adds lid or low-battery actions only after the basic path is reliable.
Complete this work with a local console available. Suspend and hibernate failures can leave a system unreachable or require a forced power cycle. Save work and ensure that current backups exist before testing.
Inventory Power Support #
Display battery, AC, and performance-policy information:
$ apm -v
# Display the complete power status reported by the platform
$ sysctl hw.sensors
# Inspect battery, AC adapter, temperature, and fan sensors when present
Sensor availability varies by architecture and device. A missing battery-life estimate or temperature sensor is not created by apmd and should not be replaced with a guessed value.
Review the boot messages for the power-management and button drivers:
$ dmesg | grep -Ei 'acpi|apm|battery|lid|power'
On ACPI systems, acpibtn(4) reports supported lid and power-button behavior. Other architectures can expose different capabilities.
Enable Automatic Performance Adjustment #
Enable apmd and select automatic performance adjustment:
# rcctl enable apmd
# Start apmd during future boots
# rcctl set apmd flags -A
# Select automatic performance adjustment
# rcctl start apmd
# Start the daemon for the current boot
# rcctl check apmd
# Confirm that it remains running
The automatic policy permits the system to adjust performance according to platform support and power state. Record idle and active battery behavior before adding more policy.
Test Explicit Suspend and Resume #
Open a text console, stop nonessential jobs, and request suspend with zzz(8) :
# zzz
After resume, verify more than the display:
$ apm -v
# Confirm battery and AC state
$ ifconfig
# Confirm that required network interfaces recovered
$ sndioctl
# Confirm that the audio control path responds
$ dmesg | tail -n 80
# Review the end of the kernel message buffer for resume errors
Repeat the test on battery and AC power, with each required external display and USB device, and after a normal lid-close event. Keep a clean-boot dmesg for comparison.
Configure the Lid Action #
Read the current lid action only when the platform exposes it:
$ sysctl machdep.lidaction
On systems supported by acpibtn(4)
, value 0 ignores a lid event, 1 suspends, and 2 hibernates. Test an immediate suspend action before making it persistent:
# sysctl machdep.lidaction=1
After several successful lid-close and resume cycles, add the setting to /etc/sysctl.conf:
machdep.lidaction=1
Do not add an unsupported machine-dependent variable to another architecture. Hibernation also requires platform support and sufficient swap space; it should be tested separately from suspend.
Add a Low-Battery Action Carefully #
The apmd -z flag requests suspend when estimated battery life reaches a selected percentage. Battery estimates can be absent, inaccurate, or delayed. Confirm stable readings over several charge cycles before enabling this action.
For a tested threshold of 10 percent:
# rcctl set apmd flags "-A -z 10"
# Retain automatic performance adjustment and add the threshold
# rcctl restart apmd
# Apply the new daemon flags
Do not use an automatic sleep threshold on a host whose battery estimate is unknown. Monitoring and a tested shutdown procedure are safer than an unreliable action.
Diagnose Resume Failures #
Classify a failure before changing settings:
- No sleep entry indicates a daemon, permissions, or platform-support problem.
- A machine that sleeps but does not wake indicates firmware, wake-device, or driver behavior.
- A recovered console with failed networking, audio, USB, or graphics indicates a device-specific resume problem.
- A graphical session failure with a working text console belongs to the X server, driver, or session layer.
Collect the complete dmesg, the relevant /var/log/messages interval, exact hardware identity, and a reproducible sequence. Collect OpenBSD Diagnostic Evidence
provides a disclosure-aware evidence workflow.
Do not apply undocumented ACPI overrides or kernel patches from another operating system. Confirm any workaround against current OpenBSD documentation or a relevant developer report.