jochen
f2ab795926
The bar left the battery out because it belongs to whoever knows the hardware, and had no way to take it back in. i3status-rust now renders bar-neutral blocks through its template; the power module contributes the battery where the machine reports one and the power draw where something measures it, sampling the root-only energy counter as root and publishing only a rate. The memory block shows what programs hold, the figure memory-pressure judges by, instead of counting the cache as used.
116 lines
7.1 KiB
Markdown
116 lines
7.1 KiB
Markdown
# power
|
|
|
|
A machine's power (novox/hq ADR 0211). This module holds `node-power` on every machine, servers
|
|
included, because every machine boots and shuts down. It owns logind's power key and lid handling. It
|
|
runs the code other modules contribute for the power moments, and it publishes the machine's power
|
|
states on the bus.
|
|
|
|
## What it owns
|
|
|
|
| | |
|
|
|---|---|
|
|
| `/etc/systemd/logind.conf.d/power.conf` | the power key and the lid, from this module's settings (below); logind is reloaded, never restarted |
|
|
| `/etc/mesh-power/moments/<moment>` | for each moment, every module's code as the controller placed it (`${shell:<moment>:<slot>}`) |
|
|
| `/usr/local/lib/mesh-power/bin/power-moment` | the runner: each module's piece on its own, as root, with `sh`, bounded (`MESH_POWER_BOUND`, default 30 s); every outcome in the journal under `mesh-power` |
|
|
| five units | `mesh-power-after-boot`, `-before-shutdown` (its stop is the shutdown, while the network is still up), `-before-sleep`, `-after-wake`, `-supply` |
|
|
| `mesh-power-draw` (process) | samples the power drawn and publishes it to `/run/mesh-power/draw` for the bar (below) |
|
|
| `/etc/udev/rules.d/90-mesh-power.rules` | a power supply's change starts `mesh-power-supply`, which runs `on-mains` or `on-battery` once per change of source |
|
|
|
|
## The moments, and how a module adds code
|
|
|
|
The moments are `after-boot`, `before-sleep`, `after-wake`, `before-shutdown`, `on-mains` and
|
|
`on-battery`. A module declares a `shell` entry whose `for` names the moment, in the `first`,
|
|
`normal` or `last` slot, with POSIX shell code. That entry depends on this seat (ADR 0210). The code
|
|
runs as root. Code that needs the operator's session finds it itself, as the laptop module's touchpad
|
|
reset does with `runuser`.
|
|
|
|
**One rule for contributed code:** the runner splits the placed file at lines of the form `# <module>`,
|
|
which the controller writes before each module's piece. A comment line of the piece's own that is
|
|
one lowercase word would split it too, so comments in contributed code use more than one word.
|
|
|
|
Code that must run *inside* the sleep transaction, such as the NVIDIA driver's own suspend and
|
|
resume units, is not a contribution. Its module keeps its own drop-ins on the sleep services (ADR
|
|
0211, "What got harder").
|
|
|
|
## The bar's battery and power draw (novox/hq ADR 0255)
|
|
|
|
The module holds the machine's power everywhere, so it gives the bar what is generic about power, on
|
|
the machines that have it. Both are contributions to `node-bar` in the bar's own neutral terms, so any
|
|
bar renders them, and each names the capability the node-engine reports for it:
|
|
|
|
| block | where | what it shows |
|
|
|---|---|---|
|
|
| battery | `if-capability: battery` (a Battery supply not scoped to a device) | the charge, and the time left or to full |
|
|
| power draw | `if-capability: power-meter` (a system battery, a powercap package counter, or a graphics device that reports its power) | one line from `bin/power-draw` |
|
|
|
|
The power draw says what it measured:
|
|
|
|
- **on battery**, the battery's discharge: `18.2 W machine`;
|
|
- **otherwise**, the processor package's power from the kernel's powercap energy counter (RAPL, Intel
|
|
and AMD), plus a discrete graphics device's own power where it reports one: `14.0 W CPU+GPU` or
|
|
`14.0 W CPU`. That is part of the machine, and is called that part.
|
|
- **The machine at the wall** needs a metered plug or a UPS and is not measured.
|
|
|
|
**The energy counter stays root's.** `energy_uj` is readable by root alone on purpose: read often by
|
|
anyone, it leaks what the processor is doing (the PLATYPUS attack). So no permission is loosened. The
|
|
module's process `mesh-power-draw` (`power draw`, as root) samples every 5 s and writes only the
|
|
averaged rate, one line, to `/run/mesh-power/draw` (0644). The bar's script prints that line, and says
|
|
`power not measured` when it is missing or older than 30 s. Graphics are counted honestly: an AMD
|
|
device only when it has its own memory (an APU's integrated graphics report the whole package, which
|
|
the counter already holds), and an NVIDIA device through `nvidia-smi` only while it is awake, so the
|
|
bar never wakes a sleeping GPU.
|
|
|
|
## Settings
|
|
|
|
`handle-power-key`, `handle-lid-switch`, `handle-lid-switch-external-power` and
|
|
`handle-lid-switch-docked`, each one of logind's actions. They have no defaults, so the mesh's layer
|
|
must be set before the first assignment. The mesh's layer carries logind's own defaults (`poweroff`,
|
|
`suspend`, `suspend`, `ignore`). A machine's layer changes them: the laptop suspends on all four.
|
|
|
|
## Events
|
|
|
|
| event | when |
|
|
|---|---|
|
|
| `booted` | once per boot, not per restart of the runtime (the boot id is remembered) |
|
|
| `sleeping` | before the machine sleeps: the module's watcher holds logind's delay lock, publishes, waits for the bus at most 3 s, and lets go |
|
|
| `woke` | after waking, queued until the bus is reachable |
|
|
| `shutting-down` | before a shutdown, as `sleeping` |
|
|
| `on-mains`, `on-battery` | when the power source changes, on a machine with a Mains supply |
|
|
| `battery-low` | at 10 % on battery, once per discharge |
|
|
|
|
Each carries the time it happened. Events the bus did not take wait in order and go out when it answers
|
|
again. A machine that said `sleeping` is asleep, not out of touch.
|
|
|
|
## Tools
|
|
|
|
| tool | |
|
|
|---|---|
|
|
| `power_state` | boot time, source and battery, lid, logind's settings, and the watcher's lock, last sleep and wake, and queue |
|
|
| `power_hooks` | every moment's contributed pieces, with their module |
|
|
| `power_history` | boots, sleeps, wakes and moment runs from the journal |
|
|
| `power_run` | run one moment now, to test it (needs `sudo -n`) |
|
|
| `power_check` | units, runner, moment files, one logind writer, no hand-placed sleep hooks, the lock held, nothing stuck before the bus |
|
|
|
|
## Migration
|
|
|
|
- **The laptop:** its model module owned `logind.conf.d/power.conf` and a touchpad resume unit. Both
|
|
move here: the file to this module, and the resume to an `after-wake` contribution.
|
|
- **The desktop:** the predecessor left `logind.conf.d/brightness.conf` and
|
|
`/etc/systemd/system-sleep/xinput-reset-touchpad.sh`. Move both aside after the first push;
|
|
`power_check` names them while they remain.
|
|
- **The servers** have no logind drop-ins and no sleep hooks today.
|
|
|
|
The lesson from the day this module was written belongs to the dbus module: a full upgrade restarted
|
|
the system bus live on a workstation, and logins hung until a reboot.
|
|
|
|
**Why the sleep hooks are wanted, not enabled.** The host reads a one-shot unit that is not running
|
|
and has not failed as having run and worked, so a hook unit waiting for a sleep could never be
|
|
declared stopped. The first version tried that and was refused on its first apply. The two sleep
|
|
units are therefore not services the mesh manages. They have no install section, and the sleep
|
|
targets want them through this module's drop-ins (`sleep.target.d`, and `suspend.target.d` with
|
|
its three siblings) — the same way the laptop module asks for the NVIDIA driver's sleep actions.
|
|
|
|
**polkit is this module's package.** logind gives a delay lock to a process that is not root only
|
|
through polkit. A server without polkit refused the watcher with "Permission denied", and its
|
|
sleeps and shutdowns would have gone unsaid. The module installs it; nothing else needed it there.
|