Output from the nfs init script from net-fs/nfs-utils-1.1.2 on starting: * Service nfs starting * Service rpc.statd starting * Service rpc.statd started * Exporting NFS directories * Starting NFS mountd * Starting NFS daemon * Starting NFS smnotify * Service nfs started But on stopping, * Service nfs stopping * Stopping NFS mountd * Stopping NFS daemon * Unexporting NFS directories * Service nfs stopped rpc.statd, which is separate script, is called for start, but not for stop.
AFAICT, this is the correct behaviour. Stopping the server through "/etc/init.d/nfs stop" should not stop rpc.statd, since nfs clients may still be using it.
Sorry to be so sarcastic, but what part of the word "stop" do you not understand? Anyway, isn't the point the of the word "stop" to stop everything, server and client processes included? Most server processes, such as those for netatalk and samba stop everything. sshd just stops the server, but its clients don't seem to lock up resources preventing the system from unmounting devices as NFS does. OTOH, by this logic, we could consider a new command for init scripts, where "stop" just stops the parent server process and "stopall" stops everything.
you are being sarcastic and he really doesnt deserve that ... the points he raised are clearly valid what you're asking for is not nfs-utils specific and really, i dont see a gain compared with the added complexity here. if you want to stop a service, stop it yourself.
Well, I even pointed out I was being sarcastic. I am stopping the service: I'm calling "/etc/init.d/nfs stop" and it's not doing that. I'm not asking for adding complexity; I am asking for adding simplicity!
i'm not sure how your logic is working. i cant think of any way your proposed change is *simpler*. on the frontend, you're talking about cascading stopping of services which is pretty unexpected. on the backend, you need to maintain a tree of running services and whether the service was only started implicitly, and then see if it is still needed by anything active.
To tell the truth, I'm not sure if there are serious consequences to having rpc.statd remain running. That is, with regard to bug http://bugs.gentoo.org/show_bug.cgi?id=228127, it's major fault. Without the rpc.nfsd 0, my server configuration essentially gets hung. I have to physically power it down. That's because my /var/lib/nfs is on a partition that is destined to be unmounted on server shutdown and it can't if some process is holding it hostage. I suspect that rpc.statd is not tying up resources that way and that as asymmetrical as the script is it is not critical, but I posted this because it seems logical that the stopping of a script should be a mirror image of starting it. For example, when I stop samba with /etc/init.d/samba stop, every instance of it is just wiped. The same with the netatalk script. OTOH, when I stop sshd, only the server is killed. Ultimately, this gets back to idea of a "stopall" command. But that sounds like a matter for a next-generation baselayout.
You could also just do "rc", which will stop any services not defined in the current runlevel (+boot level) except for services these services need. In other words, I don't see a bug here. Maybe more documentation is needed for the rc command?
This would be akin to starting ntpd on a machine where the network was down, the network would be brought up and then ntpd started. When you then went to stop ntpd, you should not expect the network to go down again. This isn't a bug.
No, your analogy is a straw man, and in two ways. Can you see why?
