View Issue Details

IDProjectCategoryView StatusLast Update
0016637CentOS-7hyperv-daemonspublic2019-10-25 17:09
Status newResolutionopen 
Product Version7.7-1908 
Target VersionFixed in Version 
Summary0016637: Isolating systemd targets stops hyperv daemons
DescriptionWhen isolating targets, like and, services like hypervvssd.service get stopped.
Steps To Reproduce1. systemctl isolate
Additional Information
In this commit, the unit files were switched from 'ConditionalVirtualization=microsoft' and '' to simply 'BindsTo=' their devices.

In layman's terms, the unit files used to be:
When starting units for, 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 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.
TagsNo tags attached.




2019-10-24 18:00

reporter   ~0035574

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' system.slice

While this increases my understanding of the situation, it does not lead me closer to a permanent solution.


2019-10-25 15:00

reporter   ~0035589

I created a Fedora account so I could report this issue upstream.


2019-10-25 17:09

reporter   ~0035590

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.

Issue History

Date Modified Username Field Change
2019-10-21 21:14 kai4785 New Issue
2019-10-24 18:00 kai4785 Note Added: 0035574
2019-10-25 15:00 kai4785 Note Added: 0035589
2019-10-25 17:09 kai4785 Note Added: 0035590