Description of problem: When user disables monitoring rules (systemctl disable), rules are installed and enabled again after package upgrade. Version-Release number of selected component (if applicable): lvm2-2.02.95-2.fc18.x86_64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
There seems to be more weird things around systemd services. We have dm-event.service and dm-event.socket and various starting and stopping combination are leading to unexpected states. Possible some of them could be bugs in the systemd itself, which starts sockets or services as dependency of the target, but they are not automatically closed upon service stop. Another thing here is - even when socket service is stopped, fifos and sockets are left in place in /var/run/dmeventd*.
(In reply to comment #1) > Another thing here is - even when socket service is stopped, fifos and sockets > are left in place in /var/run/dmeventd*. Yes, this seems to be a bug in systemd itself, I've noticed that too. I'll have a look at those other things mentioned though...
(In reply to comment #1) > There seems to be more weird things around systemd services. > > We have dm-event.service and dm-event.socket and various starting and stopping > combination are leading to unexpected states. > I've discussed this with a systemd folk and he told me that we could define even tighter dependency with the "BindTo" tag, so we end up with: dm-event.socket: BindTo=dm-event.service dm-event.service: Requires=dm-event.socket And whenever the service is stopped, the socket should be stopped as well (it works fine the other way round though, when stopping the socket unit, the service unit is automatically stopped as well because of the Requires dependency we already have there). But for this to work, we actually need the next item to be resolved... Anyway, I was told there was an RFE for issuing the warning message at least > Another thing here is - even when socket service is stopped, fifos and sockets > are left in place in /var/run/dmeventd*. As discussed with the systemd folk, this is intentional! Anyway, we agreed that I should file a bug to discuss this further, maybe this restriction will be removed, see bug #802748.
There's a movement to use "systemd presets" through the introduction of systemd-specific rpm macros which is advised to use instead of direct scriptlets calling systemctl all around the spec file (bug #850196). In this model, a global "preset" file controls which services get enabled by default on pkg installation (*not* upgrade!): https://fedoraproject.org/wiki/Features/PackagePresets On pkg upgrade, the enable/disable state of the pkg should stay the same as it was set for the old pkg version. So I think that this bz will be resolved together with the #850196. I'll do a few tests and I'll commit the changes then...
Should be fixed now in latest rawhide package (lvm2-2.02.98-1.fc19).