Bug 829856

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

(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

(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

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

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

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

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.

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.