Red Hat Bugzilla – Full Text Bug Listing
|Summary:||NFS server cannot be disabled|
|Product:||[Fedora] Fedora||Reporter:||Piergiorgio Sartor <piergiorgio.sartor>|
|Component:||nfs-utils||Assignee:||Steve Dickson <steved>|
|Status:||CLOSED WONTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||17||CC:||bfields, jlayton, johannbg, lnykryn, metherid, mschmidt, msekleta, notting, plautrba, rik.theys, steved, systemd-maint|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-08-01 07:05:06 EDT||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Piergiorgio Sartor 2012-06-07 13:04:37 EDT
Description of problem: I've a PC which has an NFS server. This one is started (by hand) whenever it is required. Reason is that it is seldom required and I do not want to have an NFS server running without using it. Until F16, the service was "disabled" and it was possible to start it, by hand, with "systemctl start nfs-server.service". Same to stop it. After the upgrade to F17, it starts at every boot, even if disabled. Note that: /etc/systemd/system/multi-user.target.wants/nfs-lock.service /etc/systemd/system/multi-user.target.wants/nfs-idmap.service Are still present, while there is no reference, in "/etc/systemd" about "nfs-server.service" (there is one in /usr/lib/systemd/system/nfs-server.service). One solution would be to "mask" the service. Unfortunately, in this case, it is not anymore possible to start it by hand. Version-Release number of selected component (if applicable): systemd-44-12.fc17.x86_64 How reproducible: Always. Steps to Reproduce: 1. Having NFS installed and disabled, reboot. 2. Or mask NFS service. Actual results: In case 1., NFS is started, like it was not disabled. In case 2., NFS is not start-able anymore... Expected results: In case 1., NFS should not start. In case 2., well, I don't know, I guess it would be correct if 1. would work as expected. Additional info: There is one thing I do not get about "systemd". One intriguing issue of this daemon would be the ability, like xinetd, to start services on demand. Nevertheless it seems to me this does not happen really. Many daemons, like sendmail, nfs, maybe dovecot, are anyway started, without waiting someone to use them. I can understand it is not simple, already xinetd cannot handle dovecot or nfs, but there is any plan to work in this direction? IMHO this would improve the complete system. Thanks a lot in advance, bye, pg
Comment 1 Jóhann B. Guðmundsson 2012-06-07 14:41:05 EDT
Hm works for me... # yum -y install nfs-utils # systemctl enable nfs.target nfs-server.service # mkdir -p /tmp/test # echo "/tmp/test 192.168.1.0/255.255.255.0(ro,sync,no_subtree_check)" > /etc/exports.d/test.exports # systemctl start nfs-server.service # systemctl status nfs-server.service nfs-rquotad.service nfs-mountd.service nfs-idmap.service # netstat -pant | grep rpc # systemctl stop nfs-server.service # systemctl status nfs-server.service nfs-rquotad.service nfs-mountd.service nfs-idmap.service # reboot # systemctl netstat -pant | grep rpc # systemctl disable nfs.target nfs-lock.service rpcbind.service # reboot # systemctl status nfs.target nfs-server.service nfs-rquotad.service nfs-mountd.service nfs-idmap.service rpcbind.service # netstat -pant | grep rpc Note that with F17 there have been some changes to the nfs stack including the introduction of the nfs.target so now nfs services are installed into the nfs.target so most likely this is an upgrade bug. Just delete the nfs symbolic links in the multi-user.target.wants directory and enable-ing and disable-ing should work for you. Once nfs-lock.service gets fixed ( currently installs into the multi-user.target instead of the nfs.target ) it should suffice just to run "systemctl disable nfs.target" and "systemctl disable rpcbind.service" if you want to disable rpcbind as well. Moving this bug against the correct component...
Comment 2 Michal Schmidt 2012-06-08 05:52:46 EDT
(In reply to comment #0) > One intriguing issue of this daemon would be the ability, like xinetd, to > start services on demand. systemd has that ability for services that support it. > Nevertheless it seems to me this does not happen really. > Many daemons, like sendmail, nfs, maybe dovecot, are anyway started, without > waiting someone to use them. Only services that know how to obtain open sockets from systemd can have on-demand activation. dovecot can do it. If you enable dovecot.socket without having enabled dovecot.service, it will do what you want. > I can understand it is not simple, already xinetd cannot handle dovecot or > nfs, but there is any plan to work in this direction? > IMHO this would improve the complete system. It makes sense to add support for socket activation to services. But note that even if all services support it, we still don't want to start everything on-demand. The main goal of having socket activation is parallelization. On-demand activation is just a nice optional addition. See http://0pointer.de/blog/projects/socket-activation.html
Comment 3 Piergiorgio Sartor 2012-06-08 13:09:15 EDT
(In reply to comment #1) [...] Hi Jóhann, thanks for the reply and the hint, I just moved the two links from multi-user.target to nfs.target and NFS worked as it was before (and expected). I guess you're right, the upgrade did not reconfigured the links properly. Thanks again, pg
Comment 4 Piergiorgio Sartor 2012-06-08 13:20:48 EDT
Hi Michal, thanks for the information. (In reply to comment #2) > (In reply to comment #0) > > One intriguing issue of this daemon would be the ability, like xinetd, to > > start services on demand. > > systemd has that ability for services that support it. Great! This is really cool! How do I find out which services support it? Are these the *.socket files in /usr/lib/systemd/system/? BTW, sendmail does not seem to be there... Pity... [...] > Only services that know how to obtain open sockets from systemd can have > on-demand activation. dovecot can do it. If you enable dovecot.socket > without having enabled dovecot.service, it will do what you want. I just did that, after reading the link you posted, and it worked! Really on-demand, after starting thunderbird, dovecot was started as soon as I checked the email. Only one thing, maybe this is dovecot specific (it was with xinetd, when working), after exiting thunderbird, dovecot was not stopped. [...] > It makes sense to add support for socket activation to services. But note > that even if all services support it, we still don't want to start > everything on-demand. The main goal of having socket activation is > parallelization. On-demand activation is just a nice optional addition. Of course you do not want to start everything on demand, but you want to have the possibility to do so for everything... The point is: it depends on the workload. If I use sendmail once a day, it does not make any sense to have it running from boot. If I run a mail server or some host with quite a lot of email trafic, then, obviously, sendmail should start ASAP. Another good example is cups, as mentioned in your link. > See http://0pointer.de/blog/projects/socket-activation.html Thanks for this, very instructive, bye, pg
Comment 5 Michal Schmidt 2012-06-11 08:48:31 EDT
(In reply to comment #4) > How do I find out which services support it? > Are these the *.socket files in /usr/lib/systemd/system/? Yes, socket activated services have *.socket units. Another way services can be activated on demand is via DBus. > BTW, sendmail does not seem to be there... Pity... sendmail developers are very conservative. Maybe they're not interested in adding support for socket activation. > Only one thing, maybe this is dovecot specific (it was with xinetd, when > working), after exiting thunderbird, dovecot was not stopped. It is expected that an idle service consumes few resources and can be eventually paged out from memory. Stopping it would be a waste of effort. systemd as an outside observer cannot tell if the service is idle. If a service should quit when not used, it needs to decide to quit by itself.
Comment 6 Piergiorgio Sartor 2013-03-04 15:01:06 EST
Hi all, I noticed this is still open, maybe it can be closed, since the original problem is not anymore there. In case, I'll open again, thanks, bye, pg
Comment 7 Fedora End Of Life 2013-07-03 23:29:16 EDT
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Comment 8 Fedora End Of Life 2013-08-01 07:05:23 EDT
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.