Bug 380909 – net-fs/autofs : current init script does not start dependencies

• Product: Gentoo Linux
• Status: RESOLVED DUPLICATE

[Description Sod off! I am no loger here! 2011-08-28 06:23:19 UTC]

autofs needs to have nfs or some of the nfs dependencies started to work properly. When I start nfs (/etc/init.d/nfs) it will start its dependencies. This does not happen when I start /etc/init.d/autofs. 

I suggest that autofs shall work the same way, i.e. make sure that its dependencies are started. 

On the other hand /etc/init.d/net.eth0 will start and stop autofs when restarted. 

Reproducible: Always

Steps to Reproduce:
1. Setup a working autofs. 
2. /etc/init.d/autofs stop
3. /etc/init.d/nfs stop
4. /etc/init.d/autofs start 
5. Autofs no longer works. 
Actual Results:  
Autofs does not work properly. 

In my case the directory entries are shown with errors when listing the auto-root. 

Expected Results:  
When the autofs init-script is started it shall ensure that services it needs are started as well.

[Comment 1 Peter Volkov (RETIRED) 2011-09-01 15:47:19 UTC]

Do you have nfs at default runlevel? Please, show output of rc-update.

[Comment 2 Sod off! I am no loger here! 2011-09-02 16:59:47 UTC]

When I found this issue I did not have NFS at the default runlevel, I have now though. 

My point is that some init-scripts starts its dependencies while autofs does not. My suggestion is that autofs shall do so as well. 


BR 
ERIK

[Comment 3 Sod off! I am no loger here! 2011-09-03 05:39:13 UTC]

After taken a look in the script I found the following in the depend() function:

need localmount
use ypbind nfs slapd portmap net


On my systems (all quite similar) I cannot use autofs unless nfs is started. Given the documentation for need and use in initscripts I sugest the following change:

need localmount nfs
use ypbind  slapd portmap net
(nfs is moved to need)

Mind that this is what I can figure out in my little corer of the world. I do not know if this is a true and always existing dependency on all systems. 


BR
Erik

[Comment 4 Dustin Polke 2011-09-12 16:12:03 UTC]

Peter,

IMO this is a dupe of bug 163210. If you agree, please mark as such or shortly explain why not and I'll try to come up with a solution.
Dustin

[Comment 5 Sod off! I am no loger here! 2011-09-13 19:24:08 UTC]

Well, 

As bug 163210 was solved back in May and I still have problem with this I think it is still valid in autofs 5.0.6-r1.

My specific point is that the autofs init-script make proper use of the "use" and "need" statements. As I understand it nfs shall be declared as a "need" if it is needed for autofs to work properly, and to me this appears to be the situation. 

It is my belief that a ebuild message is not a proper alternative for a proper init-script, unless there are some to me unknown consequences.

BR
Erik

[Comment 6 Dustin Polke 2011-09-14 08:31:10 UTC]

(In reply to comment #5)
> Well, 
> 
> As bug 163210 was solved back in May and I still have problem with this I think
> it is still valid in autofs 5.0.6-r1.
> 
> My specific point is that the autofs init-script make proper use of the "use"
> and "need" statements. As I understand it nfs shall be declared as a "need" if
> it is needed for autofs to work properly, and to me this appears to be the
> situation.
>
> It is my belief that a ebuild message is not a proper alternative for a proper
> init-script, unless there are some to me unknown consequences.
> 
> BR
> Erik

The thing is that autofs works without nfs as well and we cannot force nfs to all users even though they don't want to use that. The init script does take care that nfs is started before autofs if it is added to the runlevel. A user who wants to set-up autofs + nfs needs to take care that nfs is added to the runlevel and the elog message reminds to do so.

[Comment 7 Sod off! I am no loger here! 2011-09-14 10:13:20 UTC]

Thanks. That is a reason I fully understand and accept.

Then this suggestion is probably not valid any more and OK to close.

[Comment 8 Peter Volkov (RETIRED) 2011-09-14 17:54:07 UTC]

Ok, closing as dupe. Thank you guys.

*** This bug has been marked as a duplicate of bug 163210 ***