View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0016637||CentOS-7||hyperv-daemons||public||2019-10-21 21:14||2019-10-25 17:09|
|Target Version||Fixed in Version|
|Summary||0016637: Isolating systemd targets stops hyperv daemons|
|Description||When isolating targets, like multi-user.target and graphical.target, services like hypervvssd.service get stopped.|
|Steps To Reproduce||1. systemctl isolate multi-user.target|
In this commit, the unit files were switched from 'ConditionalVirtualization=microsoft' and 'WantedBy=multi-user.target' to simply 'BindsTo=' their devices.
In layman's terms, the unit files used to be:
When starting units for multi-user.target, and we are in a Microsoft hypervisor, start the unit.
And now they are:
When ever the sys device entry appears, start the unit, and when it disappears, stop the unit.
Since BindsTo is limited to only starting and stopping units, and isolating multi-user.target does not start or stop the device units in question, the service units are gracefully stopped.
One possible solution is to combine the efforts. Keep the BindsTo, and simply re-add the ConditionalVirtualization and WantedBy lines. This will mean that both start scenarios will apply. Not knowing the code for these service units, it may also require adding an 'After=' for the same device units, to ensure the device units are actually up before starting the service units, which is a sort of side-effect of BindsTo that WantedBy does not have.
|Tags||No tags attached.|
I'm learning more about udev than I expected to.
This is a little less straight forward than I thought. The udev rule has a SYSTEMD_WANTS environment set corectly, and I see that reflected in systemd:
[user@retconned ~]$ systemctl show sys-devices-virtual-misc-vmbus*_kvp.device | egrep -i 'want|req'
[user@retconned ~]$ systemctl show hypervkvpd.service | egrep -i 'want|req'
While this increases my understanding of the situation, it does not lead me closer to a permanent solution.
I created a Fedora account so I could report this issue upstream.
Adding a systemd drop-in with:
Seems to resolve this issue very directly. This gives me a work around, and a potential one-liner solution for each of the service units.