Hi,
>From time to time I stumble with an instance of the automounter logging
more messages than it normally does. These messages are the result of
the expiration thread running and should appear every timeout/4 seconds
once for each automounted path:
automount[8430]: st_expire: state 1 path /s
automount[8430]: expire_proc: exp_proc = 140472501561088 path /s
automount[8430]: expire_cleanup: got thid 140472501561088 path /s stat 0
automount[8430]: expire_cleanup: sigchld: exp 140472501561088
finished, switching from 2 to 1
automount[8430]: st_ready: st_ready(): state = 2 path /s
In the cases I've found, the frequency of execution of the expiration thread
is much higher than usual. I've debugged this today and discovered that
every time a SIGHUP is sent to the daemon, a new timeout alarm is added.
This alarm will then run forever every timeout/4 seconds. If you send many
SIGHUPs you'll notice that soon enough the automounter will be running
the expiration thread all the time.
The code that adds this alarm is in do_readmap_cleanup():
323 static void do_readmap_cleanup(void *arg)
324 {
325 struct readmap_args *ra;
326 struct autofs_point *ap;
327
328 ra = (struct readmap_args *) arg;
329
330 ap = ra->ap;
331
332 st_mutex_lock();
333
334 ap->readmap_thread = 0;
335 st_set_done(ap);
336 if (!ap->submount)
337 alarm_add(ap, ap->exp_runfreq); <= here
338 st_ready(ap);
339
340 st_mutex_unlock();
341
342 free(ra);
343
344 return;
345 }
Besides the SIGHUP case, this problem can also be triggered by adding a
new key to a file map and then trying to mount it. The lookup failure will
cause a map re-read and then a new alarm will be added.
This part of the code is very old and I couldn't figure out why it needs to
add the alarm at that point. Ian, could you help?
Thanks,
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
