Hi,
When using the lookup_program module, we've seen an issue where the
main automount process waits forever for the forked child to produce
output (and quit). This causes whatever processes that require the
automount to wait on autofs_wait.
Coredump of the forked child showed that it was stuck waiting on a
lock when calling setenv (it never went so far as doing the execl):
#0 __lll_lock_wait_private () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:63
#1 0x00007ffff60505ce in __add_to_environ (name=0x55555558b2e0 "autodir", value=0x55555558b300 "/a",
combined=0x0, replace=1) at setenv.c:133
This seems to be caused by the macro_setenv call in lookup_one in
modules/lookup_program.c -- that calls into glibc's setenv, and
depending on when exactly the process was forked, it could be looking
at a locked envlock.
I guess there are two approaches which to fixing the issue and I'd
like to get some thoughts before sending a patch:
1. Not calling out to any environment-mutating functions (clearenv,
putenv, setenv) which can hold the envlock after the initial setup.
In our deployment, the only place this happens is macro_setenv
and the sd_notify call in daemon/automount.c.
2. Avoiding the use of setenv in the forked child (it is MT-Unsafe
anyway). We can copy environ and use something like execle.
I tested both patches about a week ago which seemed to fix the
problem; there are no more deadlocks of this shape.
