Re: Helper for reproducing

On 15/9/25 21:21, Jun Eeo wrote:
> (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:

Thanks for your effort and the problem descriptions.

It would be best if the second patch also had a description.


I try hard to ensure every patch has a description and I also always

add development attribution (Signed-off-by) to patches. Patches can

hang around for ages of before being committed or be implicated

in problems in some way long after they are committed and having at

least something to help work out what was happening at the time is

useful.


Anyway, I'll have a look at these soon as I can get time.


Thanks,

Ian

>
> ----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 ?? ()