Bug 1316369

(In reply to Aaron Howell from comment #0)
> Description of problem:
> I believe Bug 1245804 was handled incorrectly. The systemd-preset should
> have been updated to indicate this service is enabled by default. Then this
> RPM only needs to run "systemctl preset nfs-client.target" as it previously
> was to enable or disable the serviceaccording to systemd-preset policy.
> 
But systemd-preset didn't enable *anything* even when the service 
or target which is the reason I explicitly enabled the 
target/services. 

Another thing was it is literally impossible to debug why systemd-preset
was not working so I just went for the for sure thing

(In reply to Steve Dickson from comment #2)
> (In reply to Aaron Howell from comment #0)
> > Description of problem:
> > I believe Bug 1245804 was handled incorrectly. The systemd-preset should
> > have been updated to indicate this service is enabled by default. Then this
> > RPM only needs to run "systemctl preset nfs-client.target" as it previously
> > was to enable or disable the serviceaccording to systemd-preset policy.
> > 
> But systemd-preset didn't enable *anything* even when the service 
> or target which is the reason I explicitly enabled the 
> target/services. 
> 
> Another thing was it is literally impossible to debug why systemd-preset
> was not working so I just went for the for sure thing

While you have stated you looked into doing it the correct way, I'm sorry to say but something must have been missed. It is literally as simple as running the following as root:
$ systemctl status nfs-client.target
● nfs-client.target - NFS client services
   Loaded: loaded (/usr/lib/systemd/system/nfs-client.target; disabled; vendor preset: disabled)
   Active: inactive (dead)
$ echo "enable nfs-client.target" >> /etc/systemd/system-preset/01-policy.preset 
enable nfs-client.target
$ systemctl daemon-reload
$ systemctl status nfs-client.target
● nfs-client.target - NFS client services
   Loaded: loaded (/usr/lib/systemd/system/nfs-client.target; disabled; vendor preset: enabled)
   Active: inactive (dead)
$ systemctl preset nfs-client.target
Created symlink from /etc/systemd/system/multi-user.target.wants/nfs-client.target to /usr/lib/systemd/system/nfs-client.target.
Created symlink from /etc/systemd/system/remote-fs.target.wants/nfs-client.target to /usr/lib/systemd/system/nfs-client.target.
$ systemctl status nfs-client.target
● nfs-client.target - NFS client services
   Loaded: loaded (/usr/lib/systemd/system/nfs-client.target; enabled; vendor preset: enabled)
   Active: inactive (dead)

However, rather than using a policy file in the /etc area as I have done, I would encourage Redhat to update it in the correct location for default Redhat policy:
/usr/lib/systemd/system-preset/90-default.preset

Here is the diff in question

@@ -299,7 +298,12 @@ else
 fi
 
 %post
-%systemd_post nfs-client.target
+echo "post 1=$1"
+if [ $1 -eq 1 ] ; then
+       # Initial installation
+       /bin/systemctl enable nfs-client.target >/dev/null 2>&1 || :
+       /bin/systemctl restart nfs-config  >/dev/null 2>&1 || :
+fi
 %systemd_post nfs-config
 %systemd_post nfs-server
 
@@ -337,6 +341,13 @@ fi
 /bin/systemctl stop rpc-svcgssd  >/dev/null 2>&1 || :
 /bin/systemctl enable nfs-client.target  >/dev/null 2>&1 || :
 
+%triggerin -- nfs-utils > 1:1.3.0-0.1
+# reset configuration files and running daemons
+if [ $1 -eq 2 ] ; then
+       /bin/systemctl enable nfs-client.target >/dev/null 2>&1 || :
+       /bin/systemctl restart nfs-config  >/dev/null 2>&1 || :
+fi
+

What was missing?

(In reply to Steve Dickson from comment #4)
> What was missing?

Mostly the missing entry in /usr/lib/systemd/system-preset/90-default.preset so that preset policy matches expectations. And when a "systemctl preset-all" is run it doesn't disable nfs-client.target unexpectedly.

However I would say that previous change is opposite to recommendations and requirements (rpms should not explicitly enable/disable services - should rely on systemd-preset policy), therefore after placing in the policy the rpm lines:
/bin/systemctl enable nfs-client.target
should be changed to 
/bin/systemctl preset nfs-client.target

Cheers
Aaron

(In reply to Aaron Howell from comment #5)
> (In reply to Steve Dickson from comment #4)
> > What was missing?
> 
> Mostly the missing entry in /usr/lib/systemd/system-preset/90-default.preset
> so that preset policy matches expectations. And when a "systemctl
> preset-all" is run it doesn't disable nfs-client.target unexpectedly.
But it does not enable nfs-client.target either since there is
no "enable nfs-client.target" line, correct? 

I don't own the redhat-release-server-7.3 package, so how do I
get something in there?

> 
> However I would say that previous change is opposite to recommendations and
> requirements (rpms should not explicitly enable/disable services - should
> rely on systemd-preset policy), therefore after placing in the policy the
> rpm lines:
> /bin/systemctl enable nfs-client.target
> should be changed to 
> /bin/systemctl preset nfs-client.target
Once the above question is answered.... I'll make this change.

Sorry I am a little confused.

Isn't nfs-utils and a redhat-release-server both Redhat packages? And aren't you Redhat employee? Isn't there a process for changes to multiple packages?

If nfs-client.target is enabled by default, I think we need to create an entry like the following links:

https://bugzilla.redhat.com/show_bug.cgi?id=855372
https://bugzilla.redhat.com/show_bug.cgi?id=876237

Please see also
https://fedoraproject.org/wiki/Packaging:DefaultServices

Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.

As there is no information about the decision - just the outcome. I cannot make any comments about the undiscussed decision. However I can see no logical path to the outcome - what possible reason could you have not to match the OS systemd policy to the reality of the OS?

Acking request I suppose we want to enable service in present not in RPM. Targeting for Beta if we get all remaining PM and QA acks.

Lubos

We did not receive rhel-7.6+ (due pm_ack+) and issue is not blocker. Postponing to 7.7.

Hi Steve, Could you please set the rhel-7.7.0 flag to + ?
Thanks in advance.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:2351