make an executable map rerun.

make an executable map rerun.

[Stef Bon]

Hello,

I've been working on a solution to make networkresources available via 
autofs on a dynamic way. After login with help
from ConsoleKit a mountpoint is added to the master file of the 
automounter. This mountpoint is in the homedirectory of the user logging in.

This way I've a browseable network map in my home directory for Windows 
Networks (via cifs), FTP (via curlftpfs/FUSE) and SSH (with sshfs/FUSE). 
Others, like Novell should be possible.

It works with executable maps. Now for some reasons I would like some 
control over rerrunning the executable map, to make the automounter 
refresh the autofs data. Now I do not see how to do that. I reload 
signal does not do that.

Is there a way to do this?

Stef Bon

Re: make an executable map rerun.

[Jeff Moyer]

Stef Bon <stef@bononline.nl> writes:

> Hello,
>
> I've been working on a solution to make networkresources available via 
> autofs on a dynamic way. After login with help
> from ConsoleKit a mountpoint is added to the master file of the 
> automounter. This mountpoint is in the homedirectory of the user logging in.
>
> This way I've a browseable network map in my home directory for Windows 
> Networks (via cifs), FTP (via curlftpfs/FUSE) and SSH (with sshfs/FUSE). 
> Others, like Novell should be possible.

This sounds like interesting work.  Do you have it posted somewhere?

> It works with executable maps. Now for some reasons I would like some 
> control over rerrunning the executable map, to make the automounter 
> refresh the autofs data. Now I do not see how to do that. I reload 
> signal does not do that.
>
> Is there a way to do this?

No caching is done for program maps.  They are consulted for every
single lookup, so you shouldn't have to do anything special.  Is this
not the behaviour you are observing?

Cheers,
Jeff

Re: make an executable map rerun.

[Stef Bon]

Jeff Moyer wrote:
> Stef Bon <stef@bononline.nl> writes:
>
>   
>> Hello,
>>
>> I've been working on a solution to make networkresources available via 
>> autofs on a dynamic way. After login with help
>> from ConsoleKit a mountpoint is added to the master file of the 
>> automounter. This mountpoint is in the homedirectory of the user logging in.
>>
>> This way I've a browseable network map in my home directory for Windows 
>> Networks (via cifs), FTP (via curlftpfs/FUSE) and SSH (with sshfs/FUSE). 
>> Others, like Novell should be possible.
>>     
>
> This sounds like interesting work.  Do you have it posted somewhere?
>   

Yes, look at:

http://linux.bononline.nl/linux/automountsmbshares/index.php
>   
>> It works with executable maps. Now for some reasons I would like some 
>> control over rerrunning the executable map, to make the automounter 
>> refresh the autofs data. Now I do not see how to do that. I reload 
>> signal does not do that.
>>
>> Is there a way to do this?
>>     
>
> No caching is done for program maps.  They are consulted for every
> single lookup, so you shouldn't have to do anything special.  Is this
> not the behaviour you are observing?
>   
No,

after activating the executable map once, the data provided by the 
executable map is kept. I've tested this by
letting the executable map write to an logfile, and it's running seldom.

I can look at the contents of /proc/mounts and here I see the autofs 
tree, which is kept. So I do not understand your remark
saying it is consulted every single lookup. Does the option -browse 
mather here? I'm using that and because this forces the automounter to 
remember the data right?

Stef
> Cheers,
> Jeff
>
>   

Re: make an executable map rerun.

[Jeff Moyer]

Stef Bon <stef@bononline.nl> writes:

> Jeff Moyer wrote:
>> Stef Bon <stef@bononline.nl> writes:
>>
>>   
>>> Hello,
>>>
>>> I've been working on a solution to make networkresources available
>>> via autofs on a dynamic way. After login with help
>>> from ConsoleKit a mountpoint is added to the master file of the
>>> automounter. This mountpoint is in the homedirectory of the user
>>> logging in.
>>>
>>> This way I've a browseable network map in my home directory for
>>> Windows Networks (via cifs), FTP (via curlftpfs/FUSE) and SSH (with
>>> sshfs/FUSE). Others, like Novell should be possible.
>>>     
>>
>> This sounds like interesting work.  Do you have it posted somewhere?
>>   
>
> Yes, look at:
>
> http://linux.bononline.nl/linux/automountsmbshares/index.php
>>   
>>> It works with executable maps. Now for some reasons I would like
>>> some control over rerrunning the executable map, to make the
>>> automounter refresh the autofs data. Now I do not see how to do
>>> that. I reload signal does not do that.
>>>
>>> Is there a way to do this?
>>>     
>>
>> No caching is done for program maps.  They are consulted for every
>> single lookup, so you shouldn't have to do anything special.  Is this
>> not the behaviour you are observing?
>>   
> No,
>
> after activating the executable map once, the data provided by the
> executable map is kept. I've tested this by
> letting the executable map write to an logfile, and it's running seldom.
>
> I can look at the contents of /proc/mounts and here I see the autofs
> tree, which is kept. So I do not understand your remark
> saying it is consulted every single lookup. Does the option -browse
> mather here? I'm using that and because this forces the automounter to
> remember the data right?

OK, I was wrong.  Sorry about that (I was confused with the fact that
program maps don't support the -browse option, since they can't support
map enumeration).  I admit I am not up to speed on v5.  However, it
looks to me like a HUP signal will not cause the service thread for your
mount point to restart unless the actual program map changed.  This
means the cache will still be in tact, as you observed.  I suspect we
should probably clear the cache for any maptype that does not support
enumeration upon receiving a HUP signal.  Ian, what do you think?

Cheers,
Jeff

Re: make an executable map rerun.

[Stef Bon]

Jeff Moyer wrote:
>>
>> I can look at the contents of /proc/mounts and here I see the autofs
>> tree, which is kept. So I do not understand your remark
>> saying it is consulted every single lookup. Does the option -browse
>> mather here? I'm using that and because this forces the automounter to
>> remember the data right?
>>     
>
> OK, I was wrong.  Sorry about that (I was confused with the fact that
> program maps don't support the -browse option, since they can't support
> map enumeration).  I admit I am not up to speed on v5.  However, it
> looks to me like a HUP signal will not cause the service thread for your
> mount point to restart unless the actual program map changed.  This
> means the cache will still be in tact, as you observed.  I suspect we
> should probably clear the cache for any maptype that does not support
> enumeration upon receiving a HUP signal.  Ian, what do you think?
>
> Cheers,
> Jeff
Ok,

question: how does the automounter determine that the acual program map 
has changed?

Futher, it may be a good thing to develop an utility which manages 
mountpoints and related maps.
(like autofsctl)

One of the things is to make executable maps run again and let the 
automounter read the data.
Reloading the configuration is another task.

Stef

Re: make an executable map rerun.

[Ian Kent]

Jeff Moyer wrote:
> Stef Bon <stef@bononline.nl> writes:
> 
>> Jeff Moyer wrote:
>>> Stef Bon <stef@bononline.nl> writes:
>>>
>>>   
>>>> Hello,
>>>>
>>>> I've been working on a solution to make networkresources available
>>>> via autofs on a dynamic way. After login with help
>>>> from ConsoleKit a mountpoint is added to the master file of the
>>>> automounter. This mountpoint is in the homedirectory of the user
>>>> logging in.
>>>>
>>>> This way I've a browseable network map in my home directory for
>>>> Windows Networks (via cifs), FTP (via curlftpfs/FUSE) and SSH (with
>>>> sshfs/FUSE). Others, like Novell should be possible.
>>>>     
>>> This sounds like interesting work.  Do you have it posted somewhere?
>>>   
>> Yes, look at:
>>
>> http://linux.bononline.nl/linux/automountsmbshares/index.php
>>>   
>>>> It works with executable maps. Now for some reasons I would like
>>>> some control over rerrunning the executable map, to make the
>>>> automounter refresh the autofs data. Now I do not see how to do
>>>> that. I reload signal does not do that.
>>>>
>>>> Is there a way to do this?
>>>>     
>>> No caching is done for program maps.  They are consulted for every
>>> single lookup, so you shouldn't have to do anything special.  Is this
>>> not the behaviour you are observing?
>>>   
>> No,
>>
>> after activating the executable map once, the data provided by the
>> executable map is kept. I've tested this by
>> letting the executable map write to an logfile, and it's running seldom.
>>
>> I can look at the contents of /proc/mounts and here I see the autofs
>> tree, which is kept. So I do not understand your remark
>> saying it is consulted every single lookup. Does the option -browse
>> mather here? I'm using that and because this forces the automounter to
>> remember the data right?

It just means that autofs won't delete mount point directories after
they expire. Actually, this case looks like another problem, in that
we'll get directories that being retained that are no longer valid. Oh
well, that's something for another day.

Anyway, if the entry isn't a multi-mount (in which case it must not be
forgotten until it expires away) then it will be deleted from the cache
and the program map consulted again if the cache entry is older than the
negative timeout. Maybe making the negative timeout smaller would do
what you need, hopefully without causing other issues. The default
negative timeout is 60 seconds.

> 
> OK, I was wrong.  Sorry about that (I was confused with the fact that
> program maps don't support the -browse option, since they can't support
> map enumeration).  I admit I am not up to speed on v5.  However, it
> looks to me like a HUP signal will not cause the service thread for your
> mount point to restart unless the actual program map changed.  This
> means the cache will still be in tact, as you observed.  I suspect we
> should probably clear the cache for any maptype that does not support
> enumeration upon receiving a HUP signal.  Ian, what do you think?

Not really, due to possible active multi-mounts.
The multi-mounts entries are the reason we have to wait until the mount
isn't busy.

Ian

Re: make an executable map rerun.

[Stef Bon]

Ian Kent wrote:
>>> No,
>>>
>>> after activating the executable map once, the data provided by the
>>> executable map is kept. I've tested this by
>>> letting the executable map write to an logfile, and it's running seldom.
>>>
>>> I can look at the contents of /proc/mounts and here I see the autofs
>>> tree, which is kept. So I do not understand your remark
>>> saying it is consulted every single lookup. Does the option -browse
>>> mather here? I'm using that and because this forces the automounter to
>>> remember the data right?
>>>       
>
> It just means that autofs won't delete mount point directories after
> they expire. Actually, this case looks like another problem, in that
> we'll get directories that being retained that are no longer valid. Oh
> well, that's something for another day.
>   
I'm checking I understand your reaction. You point at the browse option 
which forces autofs to
not delete mount point directories.
> Anyway, if the entry isn't a multi-mount (in which case it must not be
> forgotten until it expires away) then it will be deleted from the cache
> and the program map consulted again if the cache entry is older than the
> negative timeout. Maybe making the negative timeout smaller would do
> what you need, hopefully without causing other issues. The default
> negative timeout is 60 seconds.
>   
I will try this, but I'm using executable maps which produce a 
multi-mount map.
>   
>> OK, I was wrong.  Sorry about that (I was confused with the fact that
>> program maps don't support the -browse option, since they can't support
>> map enumeration).  I admit I am not up to speed on v5.  However, it
>> looks to me like a HUP signal will not cause the service thread for your
>> mount point to restart unless the actual program map changed.  This
>> means the cache will still be in tact, as you observed.  I suspect we
>> should probably clear the cache for any maptype that does not support
>> enumeration upon receiving a HUP signal.  Ian, what do you think?
>>     
>
> Not really, due to possible active multi-mounts.
> The multi-mounts entries are the reason we have to wait until the mount
> isn't busy.
>   
Ok, checking again here. You mean the case that one of the mountentries, 
part of the multi-mount map
is used (is: mounted) makes that the whole map is not refreshed.

Thanks for your reaction,

Stef Bon

Re: make an executable map rerun.

[Ian Kent]

On Thu, 2009-03-26 at 09:35 +0100, Stef Bon wrote:
> Ian Kent wrote:
> >>> No,
> >>>
> >>> after activating the executable map once, the data provided by the
> >>> executable map is kept. I've tested this by
> >>> letting the executable map write to an logfile, and it's running seldom.
> >>>
> >>> I can look at the contents of /proc/mounts and here I see the autofs
> >>> tree, which is kept. So I do not understand your remark
> >>> saying it is consulted every single lookup. Does the option -browse
> >>> mather here? I'm using that and because this forces the automounter to
> >>> remember the data right?
> >>>       
> >
> > It just means that autofs won't delete mount point directories after
> > they expire. Actually, this case looks like another problem, in that
> > we'll get directories that being retained that are no longer valid. Oh
> > well, that's something for another day.
> >   
> I'm checking I understand your reaction. You point at the browse option 
> which forces autofs to
> not delete mount point directories.

Yes.
My other comment relates to the cleanup of these directories.
I'm not sure it is important just yet.

> > Anyway, if the entry isn't a multi-mount (in which case it must not be
> > forgotten until it expires away) then it will be deleted from the cache
> > and the program map consulted again if the cache entry is older than the
> > negative timeout. Maybe making the negative timeout smaller would do
> > what you need, hopefully without causing other issues. The default
> > negative timeout is 60 seconds.
> >   
> I will try this, but I'm using executable maps which produce a 
> multi-mount map.

Which is fine except that, if the multi-mount entry is active, as in
hasn't been expired away, the map entry for it cannot be updated.

Last time I considered this I concluded it there were too many potential
consistency problems with allowing the entry to change while it was
mounted. If that has to change it will be hard to to, if it can be done
at all.

> >   
> >> OK, I was wrong.  Sorry about that (I was confused with the fact that
> >> program maps don't support the -browse option, since they can't support
> >> map enumeration).  I admit I am not up to speed on v5.  However, it
> >> looks to me like a HUP signal will not cause the service thread for your
> >> mount point to restart unless the actual program map changed.  This
> >> means the cache will still be in tact, as you observed.  I suspect we
> >> should probably clear the cache for any maptype that does not support
> >> enumeration upon receiving a HUP signal.  Ian, what do you think?
> >>     
> >
> > Not really, due to possible active multi-mounts.
> > The multi-mounts entries are the reason we have to wait until the mount
> > isn't busy.
> >   
> Ok, checking again here. You mean the case that one of the mountentries, 
> part of the multi-mount map
> is used (is: mounted) makes that the whole map is not refreshed.
> 
> Thanks for your reaction,
> 
> Stef Bon
>