On Thu, 2012-10-04 at 22:42 -0300, Leonardo Chiquitto wrote:
> 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?
But nevertheless there should be an alarm delete somewhere in there but
there isn't and the same applies to the prune (SIGUSR1) at least.
Ian
--
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
