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.
** No longer affects: systemd (Ubuntu Artful)
** No longer affects: systemd (Ubuntu Zesty)
** No longer affects: systemd (Ubuntu Xenial)
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1701222
Title:
[Hyper-V] LIS daemons fail to start after disable/re-enable VM
integration services
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1701222/+subscriptions
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
