The unit entered a failed state, and thus would not automatically started until failed state clears.
Why does bouncing of the services result in the daemon exiting with an error condition? Should that particular exit code result in a graceful shutdown of the service, such that the unit can be restarted again?
What userspace events should be causing the start of this unit? a udev event / udev rule? a .path unit monitoring sysfs or some such?
Is it possible to reproduce this on e.g. azure for me to investigate?
I'm going to remove per-series tasks from systemd, until this issue is trianged. per-series tasks on the src:systemd package are used to track fixes/patches which have been developed and are ready for inclusion in the distribution.
The unit entered a failed state, and thus would not automatically started until failed state clears.
Why does bouncing of the services result in the daemon exiting with an error condition? Should that particular exit code result in a graceful shutdown of the service, such that the unit can be restarted again?
What userspace events should be causing the start of this unit? a udev event / udev rule? a .path unit monitoring sysfs or some such?
Is it possible to reproduce this on e.g. azure for me to investigate?
I'm going to remove per-series tasks from systemd, until this issue is trianged. per-series tasks on the src:systemd package are used to track fixes/patches which have been developed and are ready for inclusion in the distribution.