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
Add Also=nfs.target to nfs-server.service? On a related note, why does nfs.target depend directly on named.service? Opened #970647.
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 )
(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.
Hmm, I can't see anything wrong here with systemd. Or am I missing something? Reassigning for now.
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.
Created attachment 774951 [details] boot.log file
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)
Is the nfs.target enabled?
(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.
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....
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
(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.
(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
(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
It appears would also be fixed if nfs.target was enabled https://bugzilla.redhat.com/show_bug.cgi?id=972363
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?
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)
Created attachment 776033 [details] New spec file Forgot to remove a no longer used define there
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?
(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.
(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
(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
(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...
Created attachment 777401 [details] Patched spec file that enables the nfs.target on installs and updates
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
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!
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.
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).
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.
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.
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
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
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.