autofs5 early daemonization side effects

autofs5 early daemonization side effects

[Leonardo Chiquitto]

Hello,

I've been doing some tests with AutoFS5 and I'd like to confirm that
the behavior I'm seeing during the daemon initialization is expected
or not.

The problem: when the autofs initscript returns, autofs is not really
ready.

Reading the code, I see that the automount daemon detaches itself from
the controlling terminal (becoming a daemon) early in its initialization.
After that, it starts other threads to handle different tasks and just then
reads the available maps. Normally, reading the maps is quick, but it
could take a bit more if using NIS or LDAP, what explains the delay
between the initscript returning (immediately after daemonization) and
autofs being really ready to proceed.

I was thinking about some options to work around this problem (like deferring
daemonization), but after a while, I couldn't find a clean and non-intrusive
solution. Can you help me here?

Thanks,
Leonardo

Re: autofs5 early daemonization side effects

[michael]

Leonardo Chiquitto wrote:
> Hello,
> 
> I've been doing some tests with AutoFS5 and I'd like to confirm that
> the behavior I'm seeing during the daemon initialization is expected
> or not.
> 
> The problem: when the autofs initscript returns, autofs is not really
> ready.
> 
> Reading the code, I see that the automount daemon detaches itself from
> the controlling terminal (becoming a daemon) early in its initialization.
> After that, it starts other threads to handle different tasks and just then
> reads the available maps. Normally, reading the maps is quick, but it
> could take a bit more if using NIS or LDAP, what explains the delay
> between the initscript returning (immediately after daemonization) and
> autofs being really ready to proceed.
> 
> I was thinking about some options to work around this problem (like deferring
> daemonization), but after a while, I couldn't find a clean and non-intrusive
> solution. Can you help me here?

I too have this issue.

We have been inserting a sleep into the startup script to allow autofs 
to finish reading the maps prior to other scripts executing.  The issue 
with this solution it the amount of sleep is dependedent on the site and 
how many NFS maps/mounts.  For some sites it is 1 second, for others it 
is almost 25.

Without it, many of our startup scripts fails because autofs isn't ready.

It would be nice to have a better solution.

Michael

Re: autofs5 early daemonization side effects

[Jeff Moyer]

Leonardo Chiquitto <leonardo.lists@gmail.com> writes:

> Hello,
>
> I've been doing some tests with AutoFS5 and I'd like to confirm that
> the behavior I'm seeing during the daemon initialization is expected
> or not.
>
> The problem: when the autofs initscript returns, autofs is not really
> ready.

Strange.  I originally wrote the code to return a status via a pipe, so
that the init script would not return status until the daemon was ready
to service requests.  It also took care of the problem of the init
script returning success when the daemon actually failed.

Ian, has this changed?

-Jeff

Re: autofs5 early daemonization side effects

[Ian Kent]

Jeff Moyer wrote:
> Leonardo Chiquitto <leonardo.lists@gmail.com> writes:
> 
>> Hello,
>>
>> I've been doing some tests with AutoFS5 and I'd like to confirm that
>> the behavior I'm seeing during the daemon initialization is expected
>> or not.
>>
>> The problem: when the autofs initscript returns, autofs is not really
>> ready.
> 
> Strange.  I originally wrote the code to return a status via a pipe, so
> that the init script would not return status until the daemon was ready
> to service requests.  It also took care of the problem of the init
> script returning success when the daemon actually failed.
> 
> Ian, has this changed?

No, but there was a problem with the read size on x86_64, which has also 
been fixed. I'm not sure if that was a transcription error on my part or 
not.

The other possibility is that the handle_mounts() thread creation could 
be returning before it has completed its initialisation. But looking at 
the code I can't see that happening either, certainly not before the 
mount is done and the map read, if in fact it needs to be read (which, 
as you know, it isn't for the most common configuration).

Ian

Re: autofs5 early daemonization side effects

[Leonardo Chiquitto]

> Jeff Moyer wrote:
>>
>> Leonardo Chiquitto <leonardo.lists@gmail.com> writes:
>>
>>> Hello,
>>>
>>> I've been doing some tests with AutoFS5 and I'd like to confirm that
>>> the behavior I'm seeing during the daemon initialization is expected
>>> or not.
>>>
>>> The problem: when the autofs initscript returns, autofs is not really
>>> ready.
>>
>> Strange.  I originally wrote the code to return a status via a pipe, so
>> that the init script would not return status until the daemon was ready
>> to service requests.  It also took care of the problem of the init
>> script returning success when the daemon actually failed.

The Autofs code is completely right. The problem I'm seeing is being
caused by startproc, a wrapper to start daemons that some distros
(like openSUSE) use.

Applying the following pseudo-patch in the initscript makes everything
work as it should:

-    /sbin/startproc $DAEMON $AUTOFS_OPTIONS
+    $DAEMON $AUTOFS_OPTIONS

Ian and Jeff, thanks for the help and sorry for the noise. Michael,
with luck this will be a valid workaround for you too!

Leonardo

Re: autofs5 early daemonization side effects

[michael]

Leonardo Chiquitto wrote:
>> Jeff Moyer wrote:
>>> Leonardo Chiquitto <leonardo.lists@gmail.com> writes:
>>>
>>>> Hello,
>>>>
>>>> I've been doing some tests with AutoFS5 and I'd like to confirm that
>>>> the behavior I'm seeing during the daemon initialization is expected
>>>> or not.
>>>>
>>>> The problem: when the autofs initscript returns, autofs is not really
>>>> ready.
>>> Strange.  I originally wrote the code to return a status via a pipe, so
>>> that the init script would not return status until the daemon was ready
>>> to service requests.  It also took care of the problem of the init
>>> script returning success when the daemon actually failed.
> 
> The Autofs code is completely right. The problem I'm seeing is being
> caused by startproc, a wrapper to start daemons that some distros
> (like openSUSE) use.
> 
> Applying the following pseudo-patch in the initscript makes everything
> work as it should:
> 
> -    /sbin/startproc $DAEMON $AUTOFS_OPTIONS
> +    $DAEMON $AUTOFS_OPTIONS
> 
> Ian and Jeff, thanks for the help and sorry for the noise. Michael,
> with luck this will be a valid workaround for you too!

Thanks,

That does seem to be working for me.

Michael