(In reply to comment #0)
> Description of problem:

I've read through this a few times over the last several days and
even though there's plenty of information I not quite sure what
the problem really is.

> [root@hubbitus maps]# LANG=C ll -R /etc/auto.master.d
> /etc/auto.master.d:
> total 12
> -rw-r--r-- 1 root root  386 May  9 15:29 m-n-p-y.autofs
> drwxr-xr-x 2 root root 4096 May  9 14:48 maps
> -rw-r--r-- 1 root root  132 May  9 15:29 nas-dmp.autofs
> 
> /etc/auto.master.d/maps:
> total 8
> -rw-r--r-- 1 root root 162 May  9 14:48 m-n-p-y.map
> -rw-r--r-- 1 root root  45 May  9 14:43 nas-dmp.map
> 
> [root@hubbitus maps]# cat /etc/auto.master.d/m-n-p-y.autofs
> e10fdeb5fc04f32fbbb50402d3c9f0dcdd688c85
> /mnt/net /etc/auto.master.d/maps/m-n-p-y.map
> users,guest,uid=500,gid=500,file_mode=0666,dir_mode=0777,iocharset=utf8
> --timeout=300
> [root@hubbitus maps]# cat /etc/auto.master.d/nas-dmp.autofs
> /mnt/net /etc/auto.master.d/maps/nas-dmp.map
> users,guest,uid=500,gid=500,file_mode=0666,dir_mode=0777,iocharset=utf8
> --timeout=300
> 
> Note, both describe one mountpoint /mnt/net

Right, the maps included here are meant to be master map fragments
and so should be subject to the same rules as when they are placed
directly in the master map.

Indirect maps aren't allowed to have multiple map sources.

> 
> Map-files map different directories there:
> [root@hubbitus maps]# cat /etc/auto.master.d/maps/m-n-p-y.map
> m -fstype=cifs ://192.168.100.199/maps
> n -fstype=cifs ://192.168.100.199/distr
> p -fstype=cifs ://192.168.100.199/Share
> y -fstype=cifs ://192.168.100.199/updater
> [root@hubbitus maps]# cat /etc/auto.master.d/maps/nas-dmp.map
> dmp -fstype=cifs ://192.168.100.240/all/dmp
> 
> automount colect and correctly parse both:
> [root@hubbitus maps]# automount -m | grep 'Mount point: /mnt/net' -A1000
> Mount point: /mnt/net
> 
> source(s):
> 
>   instance type(s): file 
>   map: /etc/auto.master.d/maps/m-n-p-y.map
>   arguments: users guest uid=500 gid=500 file_mode=0666 dir_mode=0777
> iocharset=utf8 
> 
>   p | -fstype=cifs ://192.168.100.199/Share
>   y | -fstype=cifs ://192.168.100.199/updater
>   m | -fstype=cifs ://192.168.100.199/maps
>   n | -fstype=cifs ://192.168.100.199/distr
> 
>   instance type(s): file 
>   map: /etc/auto.master.d/maps/nas-dmp.map
>   arguments: users guest uid=500 gid=500 file_mode=0666 dir_mode=0777
> iocharset=utf8 
> 
>   dmp | -fstype=cifs ://192.168.100.240/all/dmp

This function just reads and does some simple parsing of what it
gets. It doesn't do full validation.

This is misleading as it implies the second map instance of
/mnt/net is allowed when it isn't.

Not sure I have enough context to make that sort of determination
within this function but I agree it isn't correct.

> 
> But when I start ayutofs I got error:
> [root@hubbitus maps]# systemctl restart autofs.service
> 
> [root@hubbitus maps]# systemctl status autofs.service
> autofs.service - Automounts filesystems on demand
>    Loaded: loaded (/usr/lib/systemd/system/autofs.service; disabled)
>    Active: active (running) since Чт. 2013-05-09 15:43:37 MSK; 13s ago
>   Process: 1687 ExecStart=/usr/sbin/automount $OPTIONS --pid-file
> /run/autofs.pid (code=exited, status=0/SUCCESS)
>  Main PID: 1691 (automount)
>    CGroup: name=systemd:/system/autofs.service
>            └─1691 /usr/sbin/automount --pid-file /run/autofs.pid
> 
> мая 09 15:43:37 hubbitus systemd[1]: Started Automounts filesystems on
> demand.
> мая 09 15:43:37 hubbitus automount[1691]: key "dmp" not found in map
> source(s).
> мая 09 15:43:37 hubbitus automount[1691]: key "s" not found in map source(s).
> 
> Additionally I can't understand why 'key "s" not found in map source'
> triggered. I had not found description where it sees it ti report what it
> should be defined such key at all.

Those messages are telling you that automount received a lookup
for a directory, what automount is calling the key, and that key
was not present in the map which is accurate as far as I can see.

Just because you have not defined a key "s" in the map  doesn't
mean that some application can't attempt to access "s" within
the /mnt/net directory.

Ian

(In reply to comment #1)
> (In reply to comment #0)

> > Note, both describe one mountpoint /mnt/net
> 
> Right, the maps included here are meant to be master map fragments
> and so should be subject to the same rules as when they are placed
> directly in the master map.
> 
> Indirect maps aren't allowed to have multiple map sources.
> 
...
> > 
> >   dmp | -fstype=cifs ://192.168.100.240/all/dmp
> 
> This function just reads and does some simple parsing of what it
> gets. It doesn't do full validation.
> 
> This is misleading as it implies the second map instance of
> /mnt/net is allowed when it isn't.
> 
> Not sure I have enough context to make that sort of determination
> within this function but I agree it isn't correct.

Autofs service actually is just call automount (/lib/systemd/system/autofs.service):
ExecStart=/usr/sbin/automount $OPTIONS --pid-file /run/autofs.pid

So if automount in dump show parsed keys, but do not mount them it is bug in any case in one of places.

> This is misleading as it implies the second map instance of
> /mnt/net is allowed when it isn't.
Why not? I have not found such in man. Could you please point me on such statement in documentation?

> > Additionally I can't understand why 'key "s" not found in map source'
> > triggered. I had not found description where it sees it ti report what it
> > should be defined such key at all.
> 
> Those messages are telling you that automount received a lookup
> for a directory, what automount is calling the key, and that key
> was not present in the map which is accurate as far as I can see.
> 
> Just because you have not defined a key "s" in the map  doesn't
> mean that some application can't attempt to access "s" within
> the /mnt/net directory.

Strange.

[root@hubbitus ~]# ls /mnt/net/
dmp  m  n  ovh  p  s  smb  y
[root@hubbitus ~]# ls /mnt/net/s
[root@hubbitus ~]# rmdir /mnt/net/s
[root@hubbitus ~]# ls /mnt/net/s
ls: cannot access /mnt/net/s: No such file or directory
[root@hubbitus ~]# ls /mnt/net/
dmp  m  n  ovh  p  smb  y
[root@hubbitus ~]#
[root@hubbitus ~]# systemctl restart autofs.service
[root@hubbitus ~]# systemctl status autofs.service
autofs.service - Automounts filesystems on demand
   Loaded: loaded (/usr/lib/systemd/system/autofs.service; disabled)
   Active: active (running) since Пт. 2013-05-10 21:45:46 MSK; 19s ago
  Process: 13922 ExecStart=/usr/sbin/automount $OPTIONS --pid-file /run/autofs.pid (code=exited, status=0/SUCCESS)
 Main PID: 13924 (automount)
   CGroup: name=systemd:/system/autofs.service
           └─13924 /usr/sbin/automount --pid-file /run/autofs.pid

мая 10 21:45:46 hubbitus systemd[1]: Starting Automounts filesystems on demand...
мая 10 21:45:46 hubbitus systemd[1]: Started Automounts filesystems on demand.
мая 10 21:45:46 hubbitus automount[13924]: key "s" not found in map source(s).

(In reply to comment #2)
> > > Note, both describe one mountpoint /mnt/net
> > 
> > Right, the maps included here are meant to be master map fragments
> > and so should be subject to the same rules as when they are placed
> > directly in the master map.
> > 
> > Indirect maps aren't allowed to have multiple map sources.
> > 
> ...
> > > 
> > >   dmp | -fstype=cifs ://192.168.100.240/all/dmp
> > 
> > This function just reads and does some simple parsing of what it
> > gets. It doesn't do full validation.
> > 
> > This is misleading as it implies the second map instance of
> > /mnt/net is allowed when it isn't.
> > 
> > Not sure I have enough context to make that sort of determination
> > within this function but I agree it isn't correct.
> 
> Autofs service actually is just call automount
> (/lib/systemd/system/autofs.service):
> ExecStart=/usr/sbin/automount $OPTIONS --pid-file /run/autofs.pid
> 
> So if automount in dump show parsed keys, but do not mount them it is bug in
> any case in one of places.

systemd doesn't have anything to do with this.
automount does mount /mnt/net but ignores duplicate entries in the
master map for indirect mounts.

I've already said that the map dumping function isn't doing what it
should be doing but I also said I'm not sure I have enough context
within the dump maps function to identify duplicates and issue an
informative message.

I'll have a look and see what I can do.

> 
> > This is misleading as it implies the second map instance of
> > /mnt/net is allowed when it isn't.
> Why not? I have not found such in man. Could you please point me on such
> statement in documentation?

I don't think the documentation says that explicitly. But the
documentation doesn't say you can have multiple entries for
direct maps either although you can.

Very early in the version 5 development multiple indirect map
entries were allowed.

There was some discussion about it but I can't remember now what
the actual problem was. Since one of the goals for version 5 was to
behave the same as Solaris autofs as much as we could and that didn't
allow multiple indirect map entries the functionality was removed.
Now, since so much has changed, to add it back would be quite
difficult and then there's the change in behaviour that was a
problem in the beginning to consider.

> 
> > > Additionally I can't understand why 'key "s" not found in map source'
> > > triggered. I had not found description where it sees it ti report what it
> > > should be defined such key at all.
> > 
> > Those messages are telling you that automount received a lookup
> > for a directory, what automount is calling the key, and that key
> > was not present in the map which is accurate as far as I can see.
> > 
> > Just because you have not defined a key "s" in the map  doesn't
> > mean that some application can't attempt to access "s" within
> > the /mnt/net directory.
> 
> Strange.
> 
> [root@hubbitus ~]# ls /mnt/net/
> dmp  m  n  ovh  p  s  smb  y
> [root@hubbitus ~]# ls /mnt/net/s
> [root@hubbitus ~]# rmdir /mnt/net/s
> [root@hubbitus ~]# ls /mnt/net/s
> ls: cannot access /mnt/net/s: No such file or directory
> [root@hubbitus ~]# ls /mnt/net/
> dmp  m  n  ovh  p  smb  y
> [root@hubbitus ~]#
> [root@hubbitus ~]# systemctl restart autofs.service
> [root@hubbitus ~]# systemctl status autofs.service
> autofs.service - Automounts filesystems on demand
>    Loaded: loaded (/usr/lib/systemd/system/autofs.service; disabled)
>    Active: active (running) since Пт. 2013-05-10 21:45:46 MSK; 19s ago
>   Process: 13922 ExecStart=/usr/sbin/automount $OPTIONS --pid-file
> /run/autofs.pid (code=exited, status=0/SUCCESS)
>  Main PID: 13924 (automount)
>    CGroup: name=systemd:/system/autofs.service
>            └─13924 /usr/sbin/automount --pid-file /run/autofs.pid
> 
> мая 10 21:45:46 hubbitus systemd[1]: Starting Automounts filesystems on
> demand...
> мая 10 21:45:46 hubbitus systemd[1]: Started Automounts filesystems on
> demand.
> мая 10 21:45:46 hubbitus automount[13924]: key "s" not found in map
> source(s).

I don't see that.

I'll need to duplicate more closely the map entries your using
and see if I can reproduce it.

Ian

(In reply to comment #3)
> > 
> > мая 10 21:45:46 hubbitus systemd[1]: Starting Automounts filesystems on
> > demand...
> > мая 10 21:45:46 hubbitus systemd[1]: Started Automounts filesystems on
> > demand.
> > мая 10 21:45:46 hubbitus automount[13924]: key "s" not found in map
> > source(s).
> 
> I don't see that.
> 
> I'll need to duplicate more closely the map entries your using
> and see if I can reproduce it.

I can't reproduce this.

Can you post a full debug log please.

You can get a debug log by ensuring that facility daemon is being
recorded in syslog. I do that by adding a line like:

daemon.*                /var/log/debug

to rsyslog.conf, then create /var/log/debug and restart rsyslog.

Then set LOGGING="debug" in /etc/sysconfig/autofs.

(In reply to comment #3)
> (In reply to comment #2)
> 
> I've already said that the map dumping function isn't doing what it
> should be doing but I also said I'm not sure I have enough context
> within the dump maps function to identify duplicates and issue an
> informative message.
> 
> I'll have a look and see what I can do.

> > > This is misleading as it implies the second map instance of
> > > /mnt/net is allowed when it isn't.
> > Why not? I have not found such in man. Could you please point me on such
> > statement in documentation?
> 
> I don't think the documentation says that explicitly. But the
> documentation doesn't say you can have multiple entries for
> direct maps either although you can.
> 
> Very early in the version 5 development multiple indirect map
> entries were allowed.
> 
> There was some discussion about it but I can't remember now what
> the actual problem was. Since one of the goals for version 5 was to
> behave the same as Solaris autofs as much as we could and that didn't
> allow multiple indirect map entries the functionality was removed.
> Now, since so much has changed, to add it back would be quite
> difficult and then there's the change in behaviour that was a
> problem in the beginning to consider.

In such case it will be more than desire have such checks and catch in dump function to avoid similar confusions.

In any case, thank you very much for the ansvers and help.

Created attachment 746634 [details]
/var/log/debug

(In reply to comment #4)
> (In reply to comment #3)
> I can't reproduce this.
> 
> Can you post a full debug log please.
> 
> You can get a debug log by ensuring that facility daemon is being
> recorded in syslog. I do that by adding a line like:
> 
> daemon.*                /var/log/debug
> 
> to rsyslog.conf, then create /var/log/debug and restart rsyslog.
> 
> Then set LOGGING="debug" in /etc/sysconfig/autofs.
It was just a note...
If you so kind to look on it too, may be it have worth to splitout in separate bug?

/var/log/debug file attached.

(In reply to comment #5)
> 
> > > > This is misleading as it implies the second map instance of
> > > > /mnt/net is allowed when it isn't.
> > > Why not? I have not found such in man. Could you please point me on such
> > > statement in documentation?
> > 
> > I don't think the documentation says that explicitly. But the
> > documentation doesn't say you can have multiple entries for
> > direct maps either although you can.
> > 
> > Very early in the version 5 development multiple indirect map
> > entries were allowed.
> > 
> > There was some discussion about it but I can't remember now what
> > the actual problem was. Since one of the goals for version 5 was to
> > behave the same as Solaris autofs as much as we could and that didn't
> > allow multiple indirect map entries the functionality was removed.
> > Now, since so much has changed, to add it back would be quite
> > difficult and then there's the change in behaviour that was a
> > problem in the beginning to consider.
> 
> In such case it will be more than desire have such checks and catch in dump
> function to avoid similar confusions.

Yep, I'm working on that now and I'll add something to the man page
of auto.master(5).

Created attachment 747085 [details]
Patch - make dump maps check for duplicate indirect mounts

Created attachment 747087 [details]
Patch - document allowed map sources in auto.master(5)

(In reply to comment #6)
> Created attachment 746634 [details]
> /var/log/debug

snip ...

> > 
> > Then set LOGGING="debug" in /etc/sysconfig/autofs.
> It was just a note...
> If you so kind to look on it too, may be it have worth to splitout in
> separate bug?
> 
> /var/log/debug file attached.

I've had a look at the debug log.

First thing is autofs wasn't shutdown cleanly when you shut it down.

That normally just means that one or more mounts were in use at the
time and autofs should re-connect to those active mounts when it
starts again.

That shouldn't be a problem but can result in unexpected behaviour
at times. For example, when an autofs mount is busy it doesn't get
umounted at shutdown so any previously created mount point directories,
that for whatever reason weren't removed at umount or shutdown, will
remain and can lead to lookups like what you see here.

Another possibility is that some process is attempting to access
/mnt/net/s, perhaps because diectory "s" exists due to the above
and it is scanning the directory or because the process is trying
to access the specific path /mnt/net/s. Whatever the reason is the
kernel is duty bound to call back to the daemon with the directory
as the key.

Note that for this to happen with indirect mounts (like this) the
directory doesn't need to already exist to trigger a callback. In
this case there's no way for the kernel to know if the key is
valid or not and it must call back to the daemon.

If you do have a bad directory in /mnt/net then shut down autofs,
ensure any remaining mount points are not in use then manually
umount all the remaining autofs mananged mounts in dependency order,
including the autofs mount itself, /mnt/net, in this case. The goal
is to get the base autofs mount umounted before starting autofs
again.

That will clean up any old mount point directories because the
autofs file system is memory based.

The other way to reset the autofs mount is, of course, to
schedule a reboot of the system.

It's true that this shouldn't happen but it does from time to time.
I do work to improve it when I get reports that lead to a reason
for it happening but even then it can be hard to work out why it
happened. It's virtually impossible to guess what may have happened
previously to cause it when there isn't a reported way to reproduce
it.

Ian

autofs-5.0.7-16.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/autofs-5.0.7-16.fc19

autofs-5.0.7-16.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/autofs-5.0.7-16.fc18

Ian thank you vry much for you effort and deep explanation. Reboot helps me.

Package autofs-5.0.7-16.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing autofs-5.0.7-16.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-8061/autofs-5.0.7-16.fc18
then log in and leave karma (feedback).

autofs-5.0.7-17.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/autofs-5.0.7-17.fc19

autofs-5.0.7-19.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/autofs-5.0.7-19.fc19

autofs-5.0.7-20.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/autofs-5.0.7-20.fc19

autofs-5.0.7-21.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/autofs-5.0.7-21.fc19

autofs-5.0.7-22.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/autofs-5.0.7-22.fc19

autofs-5.0.7-23.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/autofs-5.0.7-23.fc19

autofs-5.0.7-23.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.