Bug 713574

Just throwing this in for history purpose.. 

http://www.spinics.net/lists/linux-nfs/msg14371.html

Created attachment 505046 [details]
systemd rpcbind.target

Created attachment 505047 [details]
systemd native socket based rpcbind.service

Created attachment 505048 [details]
systemd rpcbind.socket

I'm a bit confused....

why is there a /lib/systemd/system/rpcbind.target already
install with the systemd-units-29-1.fc16 package?

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.

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...

(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.

(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..

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...

(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

(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...

Fixed in: 
   rpcbind-0.2.0-12.fc16

The build is at
    http://koji.fedoraproject.org/koji/taskinfo?taskID=3185642

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...

Created attachment 511748 [details]
Spec file patch

This more in the direction the spec file should look like..

Updates applied
Build is at: 
       http://koji.fedoraproject.org/koji/taskinfo?taskID=3207129

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.

This breaks nfs access until rpcbind.service is enabled and started and nfs-lock.service is restarted.

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

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).

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.

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.

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.

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).

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.

> %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.

steved concurred on irc, he's making the update now. I just got the v-r wrong in the trigger, my fault.

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

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.