Sorry for my previous mail with missing parts...

Ian Kent wrote:
On Fri, 2010-10-22 at 17:19 +0200, Erwan Loaëc wrote:
Hello,

Sorry for the time, but before posting again I've upgrade every production servers with newest autofs4 module (with last patch) and last

What does "newest autofs4 module" mean exactly?


Yes it is not the "newest module" but the module recompiled with the patch autofs4-2.6.26-v5-update-20090903.patch


automount with all patch EXCEPT these:

autofs-5.0.5-fix-restart.patch
autofs-5.0.5-fix-status-privilege-error.patch
autofs-5.0.4-always-read-file-maps-mount-lookup-map-read-fix.patch
autofs-5.0.5-fix-direct-map-not-updating-on-reread.patch
autofs-5.0.5-add-external-bind-method.patch
autofs-5.0.5-fix-add-simple-bind-auth.patch
autofs-5.0.5-add-dump-maps-option.patch
autofs-5.0.5-fix-submount-shutdown-wait.patch


Today I had the same behaviour than the issue explained my previous mail.

--------------------
Oct 22 16:44:06 SERVERNAME automount[2665]: umount_autofs_offset: couldn't get ioctl fd for offset /cifs/XXXXXXX/volume: No such file or directory Oct 22 16:44:06 SERVERNAME automount[2665]: handle_packet_missing_direct:1363: can't find map entry for (20,3548545)
--------------------

This could be caused by a umount returning success when in fact it
didn't succeed with the umount. Are you sure umount is returning correct
status?

Unfortunaly the last case occured on production server with debug disable. I can't find more information in logfile...

But, as I've explained in my previous mail, this could logical with the bad sequence found in my previous case:

*Call to the share /cifs/XXXXXXX/volume
*Mount /cifs/XXXXXXX/volume expiring
*New call to the share /cifs/XXXXXXX/volume
*Umount /cifs/XXXXXXX/volume

In this case, obviously the umount fail because the mount is "in use".

The other problem is the total freeze of the filesystem calls to /cifs/... All IO are blocked since automount is killed/start.


Do you know if it should be fixed with the patch I've not already apply ?

Doubt it.
I think it's either a kernel or status return from umount problem.

Server where issue occurs today:
kernel: 2.6.26-2-amd64
autofs 5.0.5

Regards,

--
Erwan


Ian Kent wrote:
On Mon, 2010-09-20 at 09:58 +0800, Ian Kent wrote:
On Thu, 2010-08-26 at 12:39 +0200, Erwan Loaëc wrote:
Hello everybody!

Versions used:
- Autofs 5.0.5 with all patchs
- Kernel 2.6.26-2-686
This is going to get very difficult if you can't tell me what autofs
patches have been applied to this kernel.

/etc/auto.master:
/cifs /etc/auto.cifs --timeout=60

(the timeout is small to make easier to reproduce the issue after I've enable debug)

There is an issue which occurred regularly (in August, it happens 3 times). It seems that when a mount expires, and the same mount is called a the "same" time, automount hangs.

Please take a look to my debug log (in attachment), this is the debug log when the problem occurred.

Scenario:

Line 121 (10h10m40s) : Call to the share /cifs/SERV2/TM_termoz
Line 351 (10h11m42s) : Mount /cifs/SERV2/TM_termoz expiring
Line 356 (10h11m42s) : New call to the share /cifs/SERV2/TM_termoz
Line 401 (10h11m42s) : Umount /cifs/SERV2/TM_termoz with error

Then, obviously it cannot remove directory /cifs/SERV2

The automount hangs after this, so each I/O on /cifs/SERV2/TM_termoz hangs too...

If you want to check debug file through your browser: http://paste-it.net/public/n1e7286/
That looks like a particularly nasty bug.
I'll have to think about this one for a while and try and work out what
is happening.

Otherwise, attachment :)

Is anyone has suggestions about my problem...

Thanks!

[...CUT...]
_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs

_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs



_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs

Reply via email to