Bug 970595 - systemd doesn't start nfs-server.service at the boot
Summary: systemd doesn't start nfs-server.service at the boot
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: nfs-utils
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-04 12:39 UTC by FENG Haibo
Modified: 2013-08-27 15:02 UTC (History)
17 users (show)

Fixed In Version: nfs-utils-1.2.8-3.0.fc19
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-08-02 03:50:09 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
boot.log file (9.64 KB, text/plain)
2013-07-17 20:07 UTC, peter
no flags Details
New spec file (16.43 KB, patch)
2013-07-20 00:30 UTC, Jóhann B. Guðmundsson
no flags Details | Diff
New spec file (16.43 KB, patch)
2013-07-20 00:34 UTC, Jóhann B. Guðmundsson
no flags Details | Diff
Patched spec file that enables the nfs.target on installs and updates (2.14 KB, patch)
2013-07-23 17:38 UTC, Steve Dickson
no flags Details | Diff

Description FENG Haibo 2013-06-04 12:39:16 UTC
Description of problem:
I enabled nfs-server.service, but after reboot the PC, the nfs server is dead:
$ sudo systemctl status nfs-server.service
nfs-server.service - NFS Server
   Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; enabled)
   Active: inactive (dead)

Jun 04 20:02:28 localhost.localdomain systemd[1]: Starting NFS Server...
Jun 04 20:02:29 localhost.localdomain systemd[1]: Started NFS Server.
Jun 04 20:03:13 localhost.localdomain systemd[1]: Stopping NFS Server...
Jun 04 20:03:13 localhost.localdomain systemd[1]: Stopped NFS Server.
Jun 04 20:13:07 localhost.localdomain systemd[1]: Starting NFS Server...
Jun 04 20:13:07 localhost.localdomain systemd[1]: Started NFS Server.
Jun 04 20:16:31 localhost.localdomain systemd[1]: Stopping NFS Server...
Jun 04 20:16:31 localhost.localdomain systemd[1]: Stopped NFS Server.

$ ls -l /etc/systemd/system/nfs.target.wants/nfs-server.service
lrwxrwxrwx. 1 root root 42 Jun  4 20:35 /etc/systemd/system/nfs.target.wants/nfs-server.service -> /usr/lib/systemd/system/nfs-server.service

Version-Release number of selected component (if applicable):
$ rpm -qa|grep systemd
systemd-204-4.fc19.i686
systemd-libs-204-4.fc19.i686
systemd-sysv-204-4.fc19.i686
systemd-python-204-4.fc19.i686

$ rpm -qa|grep nfs
libnfsidmap-0.25-5.fc19.i686
nfs-utils-1.2.8-2.0.fc19.i686

How reproducible:
always

Steps to Reproduce:
1. INstalled Fedora 19 livecd. 
2. updated to the latest.
3. $ sudo systemctl enable nfs-server.service


Actual results:
reboot the nfs server is dead

Expected results:
reboot
$ sudo systemctl status nfs-server.service
nfs-server.service - NFS Server
   Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; enabled)
   Active: active (exited) since Tue 2013-06-04 20:38:25 CST; 5s ago
  Process: 2927 ExecStartPost=/usr/lib/nfs-utils/scripts/nfs-server.postconfig (code=exited, status=0/SUCCESS)
  Process: 2910 ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS $RPCNFSDCOUNT (code=exited, status=0/SUCCESS)
  Process: 2906 ExecStartPre=/usr/sbin/exportfs -r (code=exited, status=0/SUCCESS)
  Process: 2900 ExecStartPre=/usr/lib/nfs-utils/scripts/nfs-server.preconfig (code=exited, status=0/SUCCESS)

Jun 04 20:38:25 localhost.localdomain systemd[1]: Started NFS Server.

Additional info:
sudo systemctl start nfs-server.service
can manually start the nfs server

Comment 1 Zbigniew Jędrzejewski-Szmek 2013-06-04 13:49:26 UTC
Add Also=nfs.target to nfs-server.service?

On a related note, why does nfs.target depend directly on named.service? Opened #970647.

Comment 2 Jóhann B. Guðmundsson 2013-06-04 14:08:50 UTC
I dont recall but I think the current nfs units are from bug 769879#c2 at that time he ( Steve ) just implemented not the entire set of those submitted units for reasons unknown to me so the first thing is to check is to look at those units and compare them to what we currently ship.

The reason why they are depended on named.service ( like in any other units ) is because the LSB header in the legacy sysv script did so ( which if memory servers me correct was a big scripted mess that started all the daemons )

Comment 3 Zbigniew Jędrzejewski-Szmek 2013-06-04 14:16:51 UTC
(In reply to Jóhann B. Guðmundsson from comment #2)
> I dont recall but I think the current nfs units are from bug 769879#c2
Units from 769879#c2 are actually quite similar to the current version,
except that they don't have the dependency on named at all.

> The reason why they are depended on named.service ( like in any other units
> ) is because the LSB header in the legacy sysv script did so ( which if
> memory servers me correct was a big scripted mess that started all the
> daemons )
Yeah, that explains things.

Comment 4 Lennart Poettering 2013-06-21 11:23:02 UTC
Hmm, I can't see anything wrong here with systemd. Or am I missing something? Reassigning for now.

Comment 5 peter 2013-07-13 17:39:10 UTC
I confirm this bug. Since I updated from F18 to F19, I have to start the nfs-services manually. It works but up to F18 it was not necessary. When I log in after reboot
$systemctl status nfs-server.service

nfs-server.service - NFS Server
   Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; enabled)
   Active: inactive (dead)

like above.

Comment 6 peter 2013-07-17 20:07:52 UTC
Created attachment 774951 [details]
boot.log file

Comment 7 peter 2013-07-17 20:17:06 UTC
My F19 release is a fresh installation, no update.

I start the nfs-services:

# systemctl enable nfs-server.service
# systemctl start nfs-server

Check the status:
# systemctl status nfs-server.service

nfs-server.service - NFS Server
   Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; enabled)
   Active: active (exited) since Mi 2013-07-17 20:52:14 CEST; 18s ago
  Process: 6922 ExecStartPost=/usr/lib/nfs-utils/scripts/nfs-
server.postconfig (code=exited, status=0/SUCCESS)
  Process: 6906 ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS 
$RPCNFSDCOUNT (code=exited, status=0/SUCCESS)
  Process: 6895 ExecStartPre=/usr/sbin/exportfs -r (code=exited, 
status=0/SUCCESS)
  Process: 6892 ExecStartPre=/usr/lib/nfs-utils/scripts/nfs-
server.preconfig (code=exited, status=0/SUCCESS)

Jul 17 20:52:14 localhost.localdomain systemd[1]: Started NFS Server.

But if I restart the computer, the nfs server is inactive, the /var/log/boot.log file doesn't contain any reference to nfs services. See the attachment (774951)

Comment 8 Jóhann B. Guðmundsson 2013-07-17 20:35:38 UTC
Is the nfs.target enabled?

Comment 9 peter 2013-07-17 22:36:06 UTC
(In reply to Jóhann B. Guðmundsson from comment #8)
> Is the nfs.target enabled?

Thank you very much for the quick reply. This is the solution. I have enabled nfs.target too, now the reboot works fine. 

# systemctl status nfs-server.service
nfs-server.service - NFS Server
   Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; enabled)
   Active: active (exited) since Do 2013-07-18 00:26:46 CEST; 5min ago
  Process: 796 ExecStartPost=/usr/lib/nfs-utils/scripts/nfs-server.postconfig (code=exited, status=0/SUCCESS)
  Process: 731 ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS $RPCNFSDCOUNT (code=exited, status=0/SUCCESS)
  Process: 689 ExecStartPre=/usr/sbin/exportfs -r (code=exited, status=0/SUCCESS)
  Process: 685 ExecStartPre=/usr/lib/nfs-utils/scripts/nfs-server.preconfig (code=exited, status=0/SUCCESS)

Jul 18 00:26:45 localhost.localdomain systemd[1]: Starting NFS Server...
Jul 18 00:26:46 localhost.localdomain systemd[1]: Started NFS Server.

Comment 10 Steve Dickson 2013-07-18 13:58:32 UTC
Well this is odd... The nfs.target is not enabled
# systemctl status nfs.target                                             
nfs.target - Network File System Server                                         
   Loaded: loaded (/usr/lib/systemd/system/nfs.target; disabled)                
   Active: inactive (dead)              

But the nfs-server.service comes up just fine when I do a reboot
on a couple machines

# systemctl status nfs-server.service                                     
nfs-server.service - NFS Server                                                 
   Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; enabled)         
   Active: active (exited) since Thu 2013-07-18 09:36:56 EDT; 10min ago         
  Process: 642 ExecStartPost=/usr/lib/nfs-utils/scripts/nfs-server.postconfig (c
ode=exited, status=0/SUCCESS)                                                   
  Process: 566 ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS $RPCNFSDCOUNT (code=exi
ted, status=0/SUCCESS)                                                          
  Process: 541 ExecStartPre=/usr/sbin/exportfs -r (code=exited, status=0/SUCCESS
)                                                                               
  Process: 530 ExecStartPre=/usr/lib/nfs-utils/scripts/nfs-server.preconfig (cod
e=exited, status=0/SUCCESS)

and I'm using the exact same systemd and nfs-utils packages.

The only difference I see is I'm on an x86_64 machine and the reporters 
are on a i686 machine.... That shouldn't matter....

Comment 11 Jóhann B. Guðmundsson 2013-07-18 14:36:16 UTC
l (In reply to Steve Dickson from comment #10)
> Well this is odd... The nfs.target is not enabled
> # systemctl status nfs.target                                             
> nfs.target - Network File System Server                                     
>
> and I'm using the exact same systemd and nfs-utils packages.
> 
> The only difference I see is I'm on an x86_64 machine and the reporters 
> are on a i686 machine.... That shouldn't matter....

Hmm odd indeed that indicates that the entire unit set I had submitted in #769879 did not get committed as is ( which should be entirely depended on the nfs.target being enabled ) or I was doing it wrong. 

However he or you might also be on an upgrades not fresh install. 

Given that people seem to forget to enable the nfs.target ( which is understandable last time I look our F19 docs did not include sysadmin section ) I think we should enable nfs.target by default thus add it to the default preset file 

http://pkgs.fedoraproject.org/cgit/systemd.git/tree/90-default.preset

Comment 12 Steve Dickson 2013-07-18 15:04:39 UTC
(In reply to Jóhann B. Guðmundsson from comment #11)
> l (In reply to Steve Dickson from comment #10)
> > Well this is odd... The nfs.target is not enabled
> > # systemctl status nfs.target                                             
> > nfs.target - Network File System Server                                     
> >
> > and I'm using the exact same systemd and nfs-utils packages.
> > 
> > The only difference I see is I'm on an x86_64 machine and the reporters 
> > are on a i686 machine.... That shouldn't matter....
> 
> Hmm odd indeed that indicates that the entire unit set I had submitted in
> #769879 did not get committed as is ( which should be entirely depended on
> the nfs.target being enabled ) or I was doing it wrong. 
> 
> However he or you might also be on an upgrades not fresh install. 
> 
> Given that people seem to forget to enable the nfs.target ( which is
> understandable last time I look our F19 docs did not include sysadmin
> section ) I think we should enable nfs.target by default thus add it to the
> default preset file 
> 
> http://pkgs.fedoraproject.org/cgit/systemd.git/tree/90-default.preset
Yes... I think enabling nfs.target default would end the 
mount flakiness described in 
    https://bugzilla.redhat.com/show_bug.cgi?id=983915

I guess I could do that when the package is installed.

Comment 13 Jóhann B. Guðmundsson 2013-07-18 15:39:05 UTC
(In reply to Steve Dickson from comment #12)
> (In reply to Jóhann B. Guðmundsson from comment #11)
> > l (In reply to Steve Dickson from comment #10)
> > > Well this is odd... The nfs.target is not enabled
> > > # systemctl status nfs.target                                             
> > > nfs.target - Network File System Server                                     
> > >
> > > and I'm using the exact same systemd and nfs-utils packages.
> > > 
> > > The only difference I see is I'm on an x86_64 machine and the reporters 
> > > are on a i686 machine.... That shouldn't matter....
> > 
> > Hmm odd indeed that indicates that the entire unit set I had submitted in
> > #769879 did not get committed as is ( which should be entirely depended on
> > the nfs.target being enabled ) or I was doing it wrong. 
> > 
> > However he or you might also be on an upgrades not fresh install. 
> > 
> > Given that people seem to forget to enable the nfs.target ( which is
> > understandable last time I look our F19 docs did not include sysadmin
> > section ) I think we should enable nfs.target by default thus add it to the
> > default preset file 
> > 
> > http://pkgs.fedoraproject.org/cgit/systemd.git/tree/90-default.preset
> Yes... I think enabling nfs.target default would end the 
> mount flakiness described in 
>     https://bugzilla.redhat.com/show_bug.cgi?id=983915
> 
> I guess I could do that when the package is installed.


The enabledment should be in the preset [1] I believe although I'm unsure if that file is limited to .service type units ( which probably is bug then ) 

At least you should update the spec file to this [2] and we probably should ask for a removal of that F17 and older section in the guidelines since it's EOL 

1.https://fedoraproject.org/wiki/Features/PackagePresets
2. http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Macroized_scriptlets_.28Fedora_18.2B.29

Comment 14 Steve Dickson 2013-07-18 18:20:55 UTC
(In reply to Jóhann B. Guðmundsson from comment #13)
> The enabledment should be in the preset [1] I believe although I'm unsure if
> that file is limited to .service type units ( which probably is bug then ) 
> 
> At least you should update the spec file to this [2] and we probably should
> ask for a removal of that F17 and older section in the guidelines since it's
> EOL 
> 
> 1.https://fedoraproject.org/wiki/Features/PackagePresets
> 2.
> http://fedoraproject.org/wiki/Packaging:
> ScriptletSnippets#Macroized_scriptlets_.28Fedora_18.2B.29
I've already have update the spec to [2] but I must be doing
some wrong since nfs-lock.server is not being enabled. 
Here is what I have now:

%post
if [ $1 -eq 1 ]; then
    # Package install,
    %systemd_post nfs-lock.service
else
    # Package upgrade
    if /bin/systemctl --quiet is-enabled nfs-lock.service ; then
        /bin/systemctl reenable nfs-lock.service >/dev/null 2>&1 || :
    fi
fi

%preun
if [ $1 -eq 0 ]; then
    # Package removal, not upgrade
    for service in %(sed 's!\S*/!!g' <<< '%{nfs_start_services}') ; do
        %systemd_preun $service
    done
fi

%postun
if [ $1 -ge 1 ]; then
    # Package upgrade, not uninstall
    for service in %(sed 's!\S*/!!g' <<< '%{nfs_start_services}') ; do
        /bin/systemctl try-restart $service >/dev/null 2>&1 || :
    done
fi
/bin/systemctl --system daemon-reload >/dev/null 2>&1 || :


I'm thinking all I need to do is s/nfs-lock.service/nfs.target/g

Comment 15 Steve Dickson 2013-07-18 18:26:39 UTC
It appears would also be fixed if nfs.target was enabled

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

Comment 16 Jóhann B. Guðmundsson 2013-07-18 19:06:51 UTC
I going to see if I cant just take care of this tonight there seems to be something amiss in the units in requirements and wants sections. 

There is stuff there that is already taken care of by the nfs.target itself which should not be in the units ( since it's in the target ) so I need to compare the units with what I submitted to see if I happened to be blind at that time and missed this an test this a bit. 

We can also clean up the spec since the whole fpc finally agreed to drop their useless trigger run section 

Now given that ARM is becoming PA I have to ask since you know people will quickly be driven to insanity running their image of SD cards, hows the nfs on root support these, have we had any issues in that regards with the units?

Comment 17 Jóhann B. Guðmundsson 2013-07-20 00:30:31 UTC
Created attachment 776032 [details]
New spec file

Completely reworked spec file. I have to speak with the rest of the systemd crew regarding the enabledment of the unit as in if it should be enabled in the preset file or not and we need to update the guidelines according to it ( they dont talk about enablement of target units )

For some reason I cant build neither the current spec file or the new one due to this error 

libtool: link: gcc -Wall -Wextra -Wstrict-prototypes -pipe -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fpie -D_FILE_OFFSET_BITS=64 -pie -o exportfs exportfs.o  ../../support/export/libexport.a ../../support/nfs/libnfs.a ../../support/misc/libmisc.a -lwrap
/usr/bin/ld: exportfs.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
exportfs.o: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
make[2]: *** [exportfs] Error 1
make[2]: Leaving directory `/home/johannbg/rpmbuild/BUILD/nfs-utils-1.2.8/utils/exportfs'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/johannbg/rpmbuild/BUILD/nfs-utils-1.2.8/utils'
make: *** [all-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.qPB4xn (%build)

Comment 18 Jóhann B. Guðmundsson 2013-07-20 00:34:41 UTC
Created attachment 776033 [details]
New spec file

Forgot to remove a no longer used define there

Comment 19 Jóhann B. Guðmundsson 2013-07-22 10:28:52 UTC
I have provided a patch to enable nfs.target to the preset file in systemd #986869 so that hopefully takes care of that. 

Steve why does not a simple rpmbuild -ba nfs-utils.spec from the srpm work?

Comment 20 Steve Dickson 2013-07-22 12:51:55 UTC
(In reply to Jóhann B. Guðmundsson from comment #17)
> Created attachment 776032 [details]
> New spec file
> 
> Completely reworked spec file. I have to speak with the rest of the systemd
> crew regarding the enabledment of the unit as in if it should be enabled in
> the preset file or not and we need to update the guidelines according to it
> ( they dont talk about enablement of target units )
> 
With all due respect... I am not a big fan of rewriting 
things when a simple tweak will work... so  I am not going to 
complete rewrite the spec just when I can simply just enable 
the nfs.target....

Rewrites, as Comment #17 shows, introduce regressions so 
I just don't want to go down that path when a simple tweak
will fix the problem... 

To be frank... I like way I had the spec file is set up :-)
plus the file has passed a number of reviews in which
now it may no longer pass... The rewrite just not needed... 
again with all due respect... 

With that said, all I really want to do is make sure
nfs.target is enabled on install which should fix a 
number of problems with NFS not starting up correctly.

Comment 21 Jóhann B. Guðmundsson 2013-07-22 13:01:05 UTC
(In reply to Steve Dickson from comment #20)
> (In reply to Jóhann B. Guðmundsson from comment #17)
> > Created attachment 776032 [details]
> > New spec file
> > 
> > Completely reworked spec file. I have to speak with the rest of the systemd
> > crew regarding the enabledment of the unit as in if it should be enabled in
> > the preset file or not and we need to update the guidelines according to it
> > ( they dont talk about enablement of target units )
> > 
> With all due respect... I am not a big fan of rewriting 
> things when a simple tweak will work... so  I am not going to 
> complete rewrite the spec just when I can simply just enable 
> the nfs.target....
> 
> Rewrites, as Comment #17 shows, introduce regressions so 
> I just don't want to go down that path when a simple tweak
> will fix the problem... 

rewrite only take place when something is so utterly broken to begin with, which was the case with the implementation of the legacy sysv initscript and how it was setup. That spec file is no different from that.

> 
> To be frank... I like way I had the spec file is set up :-)
> plus the file has passed a number of reviews in which
> now it may no longer pass... The rewrite just not needed... 
> again with all due respect... 


With all due to respect I spent more then 4 hours of my time cleaning up your mess. That spec file is not only outdated but broken in so many ways heck even the SOURCE url in it is incorrect and quite frankly when I download srpm from koji I expect to be able to fracking rebuild the package with an simple rpmbuild -ba.

So you might like how you setup your spec file I like very much things working et all

Comment 22 Steve Dickson 2013-07-22 14:59:14 UTC
(In reply to Jóhann B. Guðmundsson from comment #19)
> I have provided a patch to enable nfs.target to the preset file in systemd
> #986869 so that hopefully takes care of that. 
> 
> Steve why does not a simple rpmbuild -ba nfs-utils.spec from the srpm work?
It works for me:
   rpm -ihv nfs-utils-1.2.8-2.1.fc19.src.rpm
   cd <build tree>/SOURCES
   rpmbuild -ba nfs-utils.spec

Comment 23 Jóhann B. Guðmundsson 2013-07-22 15:19:51 UTC
(In reply to Steve Dickson from comment #22)
> (In reply to Jóhann B. Guðmundsson from comment #19)
> > I have provided a patch to enable nfs.target to the preset file in systemd
> > #986869 so that hopefully takes care of that. 
> > 
> > Steve why does not a simple rpmbuild -ba nfs-utils.spec from the srpm work?
> It works for me:
>    rpm -ihv nfs-utils-1.2.8-2.1.fc19.src.rpm
>    cd <build tree>/SOURCES
>    rpmbuild -ba nfs-utils.spec

I'm on F18 and the rebuild of the srpms ( with unmodified spec file ) fails with the previously mentioned errors in comment 17...

Anyway I have better things to do then wasting more of my free time on efforts trying to fix the implementation nfs-utils in Fedora so deal with it as your feelings allow...

Comment 24 Steve Dickson 2013-07-23 17:38:25 UTC
Created attachment 777401 [details]
Patched spec file that enables the nfs.target on installs and updates

Comment 25 Fedora Update System 2013-07-23 19:36:45 UTC
nfs-utils-1.2.8-3.0.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/nfs-utils-1.2.8-3.0.fc19

Comment 26 peter 2013-07-24 22:14:12 UTC
I have downloaded the file nfs-utils-1.2.8-3.0.fc19.x86_64.rpm. Stopped nfs-server.service. Installed the file, restarted nfs-server.service, made a reboot:

# systemctl status nfs-server.service 
nfs-server.service - NFS Server
   Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; enabled)
   Active: active (exited) since Mi 2013-07-24 23:57:28 CEST; 1min 6s ago
  Process: 517 ExecStartPost=/usr/lib/nfs-utils/scripts/nfs-server.postconfig (code=exited, status=0/SUCCESS)
  Process: 501 ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS $RPCNFSDCOUNT (code=exited, status=0/SUCCESS)
  Process: 495 ExecStartPre=/usr/sbin/exportfs -r (code=exited, status=0/SUCCESS)
  Process: 493 ExecStartPre=/usr/lib/nfs-utils/scripts/nfs-server.preconfig (code=exited, status=0/SUCCESS)

Jul 24 23:57:27 localhost.localdomain systemd[1]: Starting NFS Server...
Jul 24 23:57:28 localhost.localdomain systemd[1]: Started NFS Server.

For my case it works. Thanks a lot!

Comment 27 peter 2013-07-24 22:20:42 UTC
I forgot:
# systemctl status nfs.target 
nfs.target - Network File System Server
   Loaded: loaded (/usr/lib/systemd/system/nfs.target; enabled)
   Active: active since Mi 2013-07-24 23:57:28 CEST; 18min ago

Jul 24 23:57:28 localhost.localdomain systemd[1]: Starting Network File System Server.
Jul 24 23:57:28 localhost.localdomain systemd[1]: Reached target Network File System Server.

nfs.target must not be started manually.

Comment 28 Fedora Update System 2013-07-25 00:50:50 UTC
Package nfs-utils-1.2.8-3.0.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing nfs-utils-1.2.8-3.0.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-13591/nfs-utils-1.2.8-3.0.fc19
then log in and leave karma (feedback).

Comment 29 Fedora Update System 2013-08-02 03:50:09 UTC
nfs-utils-1.2.8-3.0.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 30 David A. De Graaf 2013-08-14 20:10:27 UTC
I am delighted to have discovered this BZ, since it explains the instability I've had with F19 and nfs-server failing to start - and maybe dhcpd, too.
However, It may be premature to close it, saying it's fixed by nfs-utils-1.2.8-3.0.fc19.
A yum update had installed this new package but after rebooting, nfs-server was still not running, and the (incomprehensible to mere users) nfs.target was still not enabled.

I did manually enable nfs.target, rebooted, and nfs-server was then properly running.  But the comments above suggest, and I would expect, this would be unnecessary and automatic.

Comment 31 marcindulak 2013-08-25 19:13:34 UTC
The problem is still present on a clean Fedora 19 - with no NFS exports configured.

# yum -y install nfs-utils
# systemctl enable nfs-server.service && reboot
# systemctl status nfs-server.service
nfs-server.service - NFS Server
   Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; enabled)
   Active: inactive (dead)

kernel-PAE-3.10.9-200.fc19.i686
# rpm -qa | grep nfs
nfs-utils-1.2.8-3.0.fc19.i686
libnfsidmap-0.25-5.fc19.i686
# rpm -qa | grep systemd
systemd-python-204-9.fc19.i686
systemd-sysv-204-9.fc19.i686
systemd-libs-204-9.fc19.i686
systemd-204-9.fc19.i686

There is a similar problem with nfs-lock.service not starting, see bug #983915

Comment 32 Jason 2013-08-27 09:46:43 UTC
The problem is the same as for other issues where it involves a change to the default setting of a unit. The nfs-utils package did resolve this bug. However, it was not clearly stated that for any existing installations you would have to manually enable the nfs.target and nfs-lock.service yourself:

systemctl enable nfs-lock.service
systemctl enable nfs.target

The problem is that the fixed package can only fix the problem on initial install and reenable on update. It can't fix the problem on update to know to enable the service on an existing install. It does not know if an existing system/admin purposefully locked down NFS and has it disabled on purpose. In which case, enabling it would be in error.

I can verify, if you do a clean, new install of Fedora 19, and while in selecting the source you "uncheck" the do not install latest updates portion (and have an internet connection to download them) it will install this latest package which will fix the problem. I have just completed a fresh Fedora 19 install where I can done so and verified both nfs.target and nfs-lock.service are enabled and the latest nfs-utils package was installed (nfs-utils-1.2.8-3.0.fc19.x86_64 in my case).

If you do not do this (and install the version from the base image only), you will install the old package, where the bug was not fixed. And upgrading to this package does not fix it. You have to initially install it or apply the workaround after updating, which is manually enabling the services/target.


Fix for new installs: Make sure to install with latest updates

Fix for existing installs or installs that did not use latest updates:

Update to nfs-utils-1.2.8-3.0.fc19 or later and then run

systemctl enable nfs-lock.service
systemctl enable nfs.target

You can then reboot or "systemctl start nfs.target" to start the services under nfs.target

Comment 33 marcindulak 2013-08-27 15:02:38 UTC
OK. I see the %post section in nfs-utils.spec behaves as you explained,
so one can get the nfs.target and nfs-lock.service enabled also by yum remove/install nfs-utils. Works for me.


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