systemd Timers on Intermittently Powered Devices: A Catch-Up Trigger Is Not a Backlog
After an embedded device was off for several scheduled runs, why does Persistent=yes produce a catch-up activation rather than one invocation per missed interval?
After an embedded device was off for several scheduled runs, why does Persistent=yes produce a catch-up activation rather than one invocation per missed interval?
Why does a daemon lose unfinished worker cleanup when its ExecStop helper only sends a shutdown request and immediately exits?
When a codec or camera uses the Request API, when do staged controls become associated with buffers and when may the request object be reset for reuse?
Why does a read-only receiver mapping fail to guarantee immutable configuration while another process retains a writable shared mapping?
Why can a noncanonical serial read wait indefinitely with both VMIN and VTIME nonzero, even though the application configured a timeout?
Why can adding MCL_FUTURE make later allocations fail or stack growth fault while the device still has free RAM?
Why can using a physical register address as mmap offset select the wrong UIO map or fail even when the advertised device region exists?
Why does snd_pcm_recover take a different path for EPIPE and ESTRPIPE, and what must an audio service still decide after it returns success?
Why does a background acquisition helper launched by a udev RUN rule disappear after the device event finishes, and when is SYSTEMD_WANTS actually acted on?
Why can a device daemon break later activations by calling shutdown on the listening socket it inherited from systemd?