On Sat, 29 Jan 2005, Pavel Troller wrote:
Hi Ian! It's unbelievable: IT WORKS!!!!
It took me a while to pick it first time.
Your the second win with this patch. What I don't understand is why all of a sudden it starts happening.
In 3 sec intervals, the following now appears in the log:
Jan 29 13:19:28 arcus automount[13950]: sig 14 switching from 1 to 2 Jan 29 13:19:28 arcus automount[13950]: get_pkt: state 1, next 2 Jan 29 13:19:28 arcus automount[13950]: st_expire(): state = 1 Jan 29 13:19:28 arcus automount[13950]: expire_proc: exp_proc=14094 Jan 29 13:19:28 arcus automount[13950]: handle_child: got pid 14094, sig 0 (0), stat 0 Jan 29 13:19:28 arcus automount[13950]: sigchld: exp 14094 finished, switching from 2 to 1 Jan 29 13:19:28 arcus automount[13950]: get_pkt: state 2, next 1 Jan 29 13:19:28 arcus automount[13950]: st_ready(): state = 2
And if there is a filesystem to umount, it's umounted in a flash! I even changed the timeout to my favourite 3 seconds and it works too! I can't explain it to myself: How such a simple change in the sequence of the code can have such a big impact ?
It's a classic race. I think the state is ending up not being set correctly as signals are being unlocked to early. Consequently, automount doesn't pass through the right places to set the alarm for the expire.
Ian
_______________________________________________ autofs mailing list [email protected] http://linux.kernel.org/mailman/listinfo/autofs
