udev Device Events: Start Long-Running Acquisition in a Service, Not a RUN Child
A data-acquisition program started from a udev RUN rule may disappear as soon as device-event processing ends. Backgrounding it does not give it an independent service lifetime. For an embedded instrument that must keep collecting samples after attachment, let the device event request a service and let the service manager own the long-running process.
This guide pins systemd v257. Its example is a hypothetical, non-actuating sensor with a driver-defined readiness indication. It is an activation design review, not a rule installation, permission change or live acquisition test.
Identify the event-worker lifetime
The udev manual restricts RUN programs to short foreground work. Long-running children are killed when event handling finishes, even if detached. A shell background operator, nohup or a double-fork does not change that documented lifecycle.
A symptom timeline can therefore be misleading: the process starts, opens a log and briefly appears in process inspection, then vanishes. That does not establish a serial-driver failure or a crashing decoder. First determine whether it is still a descendant of the event worker and whether its lifetime ends at the event boundary.
Keep any permitted event-side helper narrowly bounded. It should not become a service supervisor or wait indefinitely for another device to appear. The worker must finish processing the event so dependent device handling can proceed.
Express activation as a dependency
The device-unit manual describes SYSTEMD_WANTS as a way to add wanted units to a device’s activation. The device must carry the systemd tag for these properties to be considered.
For an already reviewed device match, the relevant assignment fragment is:
TAG+="systemd", ENV{SYSTEMD_WANTS}+="sensor-acquire.service"This is deliberately only the assignment portion. A production rule must first match the intended device and event context. Pasting it as a broad rule would associate the service with unrelated devices. Device identity, node permissions and service sandboxing remain separate requirements.
The corresponding service owns the acquisition executable, its exit status and its restart policy. Define those in the product’s service configuration rather than embedding a detached shell command in the event rule. The service should still verify that the selected sensor is available and compatible before beginning work.
Gate first activation on actual readiness
Adding a wanted service to an already active device does not itself trigger it. The documented trigger is the device’s transition to active. SYSTEMD_READY=0 keeps a visible but unready device from being considered active; a later readiness transition can permit activation.
Consider this proposed sequence. At initial attachment, the driver exposes the device but has not finished initialization. The matching rule records the wanted acquisition service and marks the device unready. When a genuine driver-supported readiness event arrives, the rules mark it ready. The device can then become active and request the service.
Original activation timeline. The readiness signal must come from a defined device contract; elapsed time alone is not the signal.
This sequence is not permission to toggle readiness properties arbitrarily as a substitute for proper initialization. Establish which event and attribute identify readiness, how rules evaluate them, and what happens if initialization fails. A timeout policy belongs in the owning service or integration design, with an explicit failure result.
Do not confuse activation with removal handling
A request to start the service does not, on its own, specify what happens when the sensor disappears. Decide whether the acquisition service remains available awaiting reconnection or terminates with that particular device instance. Review the appropriate unit dependencies and application disconnect handling for that choice.
For example, a product with one fixed sensor role might keep a supervisor alive while replacing the active acquisition session. A different product might create a separate service instance per device. Those designs have different cleanup and identity requirements. Neither follows automatically from one SYSTEMD_WANTS property.
Check the three transition cases
Propose a development test with an initially unready device, a later ready transition and a removal during acquisition. Record device-unit state, effective properties and service start/exit events together. The useful assertion is that acquisition begins after the defined readiness transition, under the service manager’s ownership.
As a negative case, add a wanted-unit property to a device that is already active and verify that the review does not expect a fresh activation merely from that update. Also check that repeated ordinary change events do not create unintended duplicate acquisition owners.
The final artifact should be a small event-to-service state table. It explains which transition starts work, which component supervises it and which component handles disappearance. That is a more reliable fix than trying another shell detachment technique inside the udev worker.
