On Thu, Oct 11, 2012 at 11:48 AM, Brian J. Murrell <brian@xxxxxxxxxxxxxxx> wrote: > On 12-10-11 10:32 AM, Leonardo Chiquitto wrote: >> >> I guess this means Thunar is not accessing any files in /home/shared >> during the 300 seconds timeout. > > But it has to be. Look at the variability of the gap between mount and > unmount commands and the very short time between umount and mount > commands. That the latter is sooooo short means that Thunar has to be > accessing very frequently or it is accessing it (only) after the umount > for some reason. I'm not even sure how it would know that it was > unmounted without "polling" it and then we are back to it accessing it > quite frequently. That's easy: it can monitor the list of mounted file systems (/etc/mtab, /proc/mounts) and react to changes in these files. >> What happens if you increase the >> timeout to 450 or 600 seconds? > > I have not tried that yet as I fully expect to see the same results. I > can try of course. I expect the same results to, but what if Thunar checks the mounted file system every 5 minutes too? That means it would try to access the file system roughly after the unmount. >> Another thing I'd do is to run strace >> against Thunar to discover whether it's not reacting exactly to the >> unmount and doing something in that mount point that triggers the >> mount again. > > Yeah, I have tried that already but it's a constantly busy process. > Many, many syscalls per second, every second, even when you filter out > the very noisiest of them. You can filter by path: strace -y -P /home/shared Leonardo -- To unsubscribe from this list: send the line "unsubscribe autofs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
