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. > 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. > 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. > Btw, are you sure it's Thunar? Yes. Automount tells me it is. When you run it with -d -f it tells you the pid that caused the mount. > I'm using it here and do not observe > this behavior. If you increase AutoFS log level to "debug", you can see > the pid of the process that triggered the mount in the log. Example: > > handle_packet_missing_indirect: token 850, name music, request pid 964 <= Exactly. That's how I *know* it's Thunar. Cheers, b.
Attachment:
signature.asc
Description: OpenPGP digital signature
