Helper for reproducing

(Apologies for the spam!)

One way to easily reproduce the issue is to run the autofs service
as a systemd unit (i.e. with the --systemd-service flag set), compile
this and add to LD_PRELOAD in the unit:

----8<----
#define _GNU_SOURCE
#include <dlfcn.h>
#include <stdio.h>
#include <stdlib.h>

int
sd_notify(int unset_environment, const char* state)
{
	fprintf(stderr, "sd_notify(%d, %s)\n", unset_environment, state);
	int (*fn)(int, const char*) = dlsym(RTLD_NEXT, "sd_notify");
	int rv = (*fn)(0, state);
	fprintf(stderr, "doing the unsetenv loop\n");
	if (unset_environment)
		while (1)
			unsetenv("NOTIFY_SOCKET");
	return rv;
}
---->8----

That helper just makes the unsetenv in sd_notify a bit more apparent:

----8<----
_public_ int sd_pid_notify_with_fds(
                pid_t pid,
                int unset_environment,
                const char *state,
                const int *fds,
                unsigned n_fds) {
        // bunch of work
finish:
        if (unset_environment)
                unsetenv("NOTIFY_SOCKET");

        return r;
}

// ...

_public_ int sd_notify(int unset_environment, const char *state) {
        return sd_pid_notify_with_fds(0, unset_environment, state, NULL, 0);
}
---->8----

At least in my version of glibc -- this produced the same coredump
deadlocks we were seeing in production. If you trigger an automount,
the systemd service should then look like:

    $ systemctl status autofs
    ● autofs.service - Automount daemon
       Loaded: loaded (/usr/lib/systemd/system/autofs.service; enabled; vendor preset: disabled)
       Active: active (running) since Mon 2025-09-15 13:07:30 BST; 31min ago
     Main PID: 3115468 (automount)
        Tasks: 15 (limit: 615964)
       Memory: 4.5M
       CGroup: /system.slice/autofs.service
               ├─3115468 /usr/sbin/automount --systemd-service --dont-check-daemon -n 1 -t 0 /tmp/my-config
               └─3115724 /usr/sbin/automount --systemd-service --dont-check-daemon -n 1 -t 0 /tmp/my-config

(i.e. the child process remains stuck forever). The stack trace in the
child process should then be something like:

(gdb) bt
#0  __lll_lock_wait_private () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:63
#1  0x00007f110f6505ce in __add_to_environ (name=0x55f89b8643c0 "autodir", value=0x55f89b8643e0 "/a",
    combined=0x0, replace=1) at setenv.c:133
#2  0x0000002600000025 in ?? ()
#3  0x00007f10df7fb4f0 in ?? ()
#4  0x00007f1110e10540 in ?? () at dl-open.c:200 from /lib64/ld-linux-x86-64.so.2
#5  0x00007f10df7fb460 in ?? ()
#6  0x0000000000000000 in ?? ()