On Fri, Feb 3, 2023 at 8:24 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Andres Freund <and...@anarazel.de> writes: > > Ugh, I think I might understand what's happening: > > > The signal arrives just after the fork() (within system()). Because we > > have all our processes configure themselves as process group leaders, > > and we signal the entire process group (c.f. signal_child()), both the > > child process and the parent will process the signal. So we'll end up > > doing a proc_exit() in both. As both are trying to remove themselves > > from the same PGPROC etc entry, that doesn't end well. > > Ugh ...
Yuck, but yeah that makes sense. > > I don't see how we can solve that properly as long as we use system(). > > ... but I don't see how that's system()'s fault? Doing the fork() > ourselves wouldn't change anything about that. What if we block signals, fork, then in the child, install the default SIGTERM handler, then unblock, and then exec the shell? If SIGTERM is delivered either before or after exec (but before whatever is loaded installs a new handler) then the child is terminated, but without running the handler. Isn't that what we want here?
