Bug 713574

Summary: Provide native systemd unit file
Product: [Fedora] Fedora Reporter: Stephen Gallagher <sgallagh>
Component: rpcbindAssignee: Steve Dickson <steved>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: high    
Version: 16CC: bugs.michael, johannbg, orion, steved, tcallawa
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: rpcbind-0.2.0-15.fc16 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-10-03 14:08:40 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 713562    
Attachments:
Description Flags
systemd rpcbind.target
none
systemd native socket based rpcbind.service
none
systemd rpcbind.socket
none
Spec file patch none

Description Stephen Gallagher 2011-06-15 15:35:06 EDT
https://fedoraproject.org/wiki/Features/SysVtoSystemd
Comment 1 Jóhann B. Guðmundsson 2011-06-16 09:45:44 EDT
Just throwing this in for history purpose.. 

http://www.spinics.net/lists/linux-nfs/msg14371.html
Comment 2 Jóhann B. Guðmundsson 2011-06-16 09:49:05 EDT
Created attachment 505046 [details]
systemd rpcbind.target
Comment 3 Jóhann B. Guðmundsson 2011-06-16 09:49:53 EDT
Created attachment 505047 [details]
systemd native socket based rpcbind.service
Comment 4 Jóhann B. Guðmundsson 2011-06-16 09:50:34 EDT
Created attachment 505048 [details]
systemd rpcbind.socket
Comment 5 Steve Dickson 2011-07-05 13:53:48 EDT
I'm a bit confused....

why is there a /lib/systemd/system/rpcbind.target already
install with the systemd-units-29-1.fc16 package?
Comment 6 Stephen Gallagher 2011-07-05 14:00:52 EDT
Redirecting this question to Jóhann B. Guðmundsson. I'm not sure why it appeared in the systemd-units package. That seems wrong to me.
Comment 7 Steve Dickson 2011-07-05 14:06:37 EDT
also idea what this error message is trying to tell me?
    Failed to issue method call: Job type reload is not applicable for unit rpcbind.service.

it happens when I do a systemctl load rpcbind.service with above scripts...
Comment 8 Jóhann B. Guðmundsson 2011-07-05 14:48:12 EDT
(In reply to comment #6)
> Redirecting this question to Jóhann B. Guðmundsson. I'm not sure why it
> appeared in the systemd-units package. That seems wrong to me.

rpcbind.target was added so systemd automatically could add dependencies of type After for this target unit to all SysV init script service units with an LSB
header referring to the $rpcbind facility.
Comment 9 Jóhann B. Guðmundsson 2011-07-05 14:55:32 EDT
(In reply to comment #7)
> also idea what this error message is trying to tell me?
>     Failed to issue method call: Job type reload is not applicable for unit
> rpcbind.service.
> 
> it happens when I do a systemctl load rpcbind.service with above scripts...

Note that systemctl "load" command is little use except for debugging and it's simply pointing you out that the job type reload is not applicable for unit rpcbind.service basically exactly what it says there..
Comment 10 Steve Dickson 2011-07-07 10:33:00 EDT
I've looked around but was unable to find how
one gets a service, like rpcbind, to be started
when the system boots in to runlevel 3.

Here is the %post part of the spec file:

%post
/sbin/chkconfig --add %{name}
if [ $1 -eq 1 ]; then
    # Package install, not upgrade
    /bin/systemctl daemon-reload >/dev/null 2>&1 || :
fi

What has to happen? 

tia...
Comment 11 Jóhann B. Guðmundsson 2011-07-07 10:56:12 EDT
(In reply to comment #10)
> I've looked around but was unable to find how
> one gets a service, like rpcbind, to be started
> when the system boots in to runlevel 3.

Well it's best to point out that there are no such things as "run levels" in systemd it's an obsolete concept anywho first you need to decide if you want to drop or keep the legacy sysv init scripts ( legacy sysv init scripts need to be subpackage as stated by the packaging guidelines ) there is about 60/40 drop/keep ratio hence it's best that you read.. 

https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd
http://fedoraproject.org/wiki/Packaging:Tmpfiles.d
Comment 12 Steve Dickson 2011-07-07 11:33:58 EDT
(In reply to comment #11)
> (In reply to comment #10)
> > I've looked around but was unable to find how
> > one gets a service, like rpcbind, to be started
> > when the system boots in to runlevel 3.
> 
> Well it's best to point out that there are no such things as "run levels" in
> systemd it's an obsolete concept anywho first you need to decide if you want to
> drop or keep the legacy sysv init scripts ( legacy sysv init scripts need to be
> subpackage as stated by the packaging guidelines ) there is about 60/40
> drop/keep ratio hence it's best that you read.. 
> 
> https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd
> https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd
> http://fedoraproject.org/wiki/Packaging:Tmpfiles.d

Thanks for the pointers... systemctl enable did the trick...
Comment 13 Steve Dickson 2011-07-07 11:35:29 EDT
Fixed in: 
   rpcbind-0.2.0-12.fc16

The build is at
    http://koji.fedoraproject.org/koji/taskinfo?taskID=3185642
Comment 14 Jóhann B. Guðmundsson 2011-07-07 11:42:38 EDT
This build fails to meet the packaging guidelines as I had mentioned in comment 12
 and as is stated in the packaging guidelines...

"SysV Initscripts
Packages may also provide a SysV initscript file, but are not required to do so. This format is considered legacy, but Fedora still contains init mechanisms such as upstart which do not support the systemd unit file format. If present, the SysV initscript(s) must go into an optional subpackage, so as not to confuse sysadmins. The guidelines for SysV initscripts can be found here: Packaging:SysVInitScript"

The legacy sysvinit must be package seperatly into subpackage or be dropped...
Comment 15 Jóhann B. Guðmundsson 2011-07-07 12:00:05 EDT
Created attachment 511748 [details]
Spec file patch

This more in the direction the spec file should look like..
Comment 16 Steve Dickson 2011-07-18 11:23:41 EDT
Updates applied
Build is at: 
       http://koji.fedoraproject.org/koji/taskinfo?taskID=3207129
Comment 17 Orion Poplawski 2011-08-25 13:39:06 EDT
I just installed F16 Alpha and rpcbind is disabled:

# systemctl status rpcbind.service
rpcbind.service - RPC bind service
          Loaded: loaded (/lib/systemd/system/rpcbind.service; disabled)
          Active: inactive (dead)
          CGroup: name=systemd:/system/rpcbind.service

I'm pretty sure it was enabled by default on F15 and earlier.
Comment 18 Orion Poplawski 2011-08-31 12:41:42 EDT
This breaks nfs access until rpcbind.service is enabled and started and nfs-lock.service is restarted.
Comment 19 Fedora Update System 2011-09-09 13:31:52 EDT
rpcbind-0.2.0-14.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/rpcbind-0.2.0-14.fc16
Comment 20 Fedora Update System 2011-09-10 14:58:01 EDT
Package rpcbind-0.2.0-14.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing rpcbind-0.2.0-14.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/rpcbind-0.2.0-14.fc16
then log in and leave karma (feedback).
Comment 21 Michael Schwendt 2011-09-12 10:49:08 EDT
Something has gone wrong here.

nfs-lock.service here fails to start (failed to create RPC listeners, exiting)

Trying to find out why rpcbind.service is not up and running, I found out it is disabled.

The latest test update tries to correct that, but how is it supposed to work?

| postinstall scriptlet (using /bin/sh):
| if [ $1 -eq 1 ] ; then 
|     # Initial installation
|     /bin/systemctl enable rpcbind.service >/dev/null 2>&1 || :
| fi

This ($1 -eq 1) means that the service is only enabled for installs, not for upgrades.

Conclusively, the test update cannot fix this issue.
Comment 22 Stephen Gallagher 2011-09-12 11:00:50 EDT
I did this for SSSD:

%triggerun -- sssd < %{version}-%{release}
if /sbin/chkconfig --level 3 sssd ; then
        /bin/systemctl --no-reload enable sssd.service >/dev/null 2>&1 || :
fi

if /sbin/chkconfig --level 5 sssd ; then
        /bin/systemctl --no-reload enable sssd.service >/dev/null 2>&1 || :
fi




In English: if the version of SSSD being upgraded from is lower than the current version, check to see if it was enabled at runlevel 3. If so, enable it. Then also check for level 5 and enable it if so.
Comment 23 Michael Schwendt 2011-09-12 11:05:40 EDT
Meanwhile I've followed bug 699040 and have had a closer look:

# rpm -q --triggers rpcbind
triggerun scriptlet (using /bin/sh) -- rpcbind < 0.2.0-12
/usr/bin/systemd-sysv-convert --save rpcbind >/dev/null 2>&1 ||:
/bin/systemctl --no-reload enable rpcbind.service >/dev/null 2>&1
/sbin/chkconfig --del rpcbind >/dev/null 2>&1 || :
/bin/systemctl try-restart rpcbind.service >/dev/null 2>&1 || :

This only works for people upgrading from Fedora 15 or installing Fedora 16. Obviously, it fails for people updating Fedora 16 from Alpha or earlier, because they have had July's rpcbind-0.2.0-12.fc16 which did not contain triggers.
Comment 24 Stephen Gallagher 2011-09-12 11:13:06 EDT
This is why I recommended my approach above. It checks on ALL upgrades and will enable the service if chkconfig says it was enabled.

It's safe for all upgrades (and enabling something that's already enabled is a no-op).
Comment 25 Tom "spot" Callaway 2011-09-12 12:27:18 EDT
The version here is supposed to line up with the first package v-r that contains the triggerun. If that is incorrect, we need to adjust it. If I adjust the triggrun to say:

%triggerun -- rpcbind < 0.2.0-15

That should work, correct?

Re: Comment 24:

Stephen's approach was considered, but rejected, because it was decided that we had no way to differentiate between what is on by default and what is on because the user configured it that way. Instead, we're on a "only specific packages may be on by default, save the settings, provide a simple tool for users to restore the old enablements". Please try not to "recommend" alternate approaches, the systemd packaging guidelines document how this is supposed to be done across the board.
Comment 26 Michael Schwendt 2011-09-12 13:40:38 EDT
> %triggerun -- rpcbind < 0.2.0-15
> 
> That should work, correct?

Yes, and in accordance with

https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Packages_migrating_to_a_systemd_unit_file_from_a_SysV_initscript

With the increased V-R the trigger would fire also for people coming from F-16 Alpha (rpcbind-0.2.0-13.fc16) or post-F-15 Rawhide. Unlike the current test update.
Comment 27 Tom "spot" Callaway 2011-09-12 13:45:14 EDT
steved concurred on irc, he's making the update now. I just got the v-r wrong in the trigger, my fault.
Comment 28 Fedora Update System 2011-09-12 14:23:27 EDT
rpcbind-0.2.0-15.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/rpcbind-0.2.0-15.fc16
Comment 29 Fedora Update System 2011-10-03 14:08:32 EDT
rpcbind-0.2.0-15.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.