Bug 802687 - The enabled/disabled state of lvm2 systemd units is lost on package upgrade
The enabled/disabled state of lvm2 systemd units is lost on package upgrade
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Rajnoha
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-13 05:43 EDT by Zdenek Kabelac
Modified: 2012-10-16 06:25 EDT (History)
11 users (show)

See Also:
Fixed In Version: lvm2-2.02.98-1.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-16 06:25:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Zdenek Kabelac 2012-03-13 05:43:38 EDT
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:
Comment 1 Zdenek Kabelac 2012-03-13 06:12:13 EDT
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*.
Comment 2 Peter Rajnoha 2012-03-13 07:16:34 EDT
(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...
Comment 3 Peter Rajnoha 2012-03-13 08:53:11 EDT
(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.
Comment 4 Peter Rajnoha 2012-09-12 10:01:14 EDT
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...
Comment 5 Peter Rajnoha 2012-10-16 06:25:36 EDT
Should be fixed now in latest rawhide package (lvm2-2.02.98-1.fc19).

Note You need to log in before you can comment on or make changes to this bug.