I installed file #10477 (`crash-server-added-orphan-action-to-append-args-20060806.patch') after a tiny tweak.

#v+
2006-11-27  Ben Asselstine  <benasselstine@canada.com>
            Thomas Schwinge  <tschwinge@gnu.org>

        * crash.c (trivfs_append_args): Handle CRASH_ORPHANS_HOW.
#v-


This does -- of course -- not yet fix this bug report's main issue.

I tried the patched crash server, and it didn't quite work as expected.

I retried Thomas' example:

#v+
thomas@leibniz:/var/tmp $ cat > crash.c
int main (void) { return (int ) 0; }
thomas@leibniz:/var/tmp $ gcc crash.c
thomas@leibniz:/var/tmp $ ./a.out
Segmentation fault (core dumped)
thomas@leibniz:/var/tmp $ ls -l core
-rw------- 1 thomas root 16912384 Jun 15 20:43 core
thomas@leibniz:/var/tmp $ ls -l /servers/crash
lrwxr-xr-x 1 root root 13 Jun 15 20:42 /servers/crash -> crash-suspend
thomas@leibniz:/var/tmp $ showtrans /servers/crash-suspend
/hurd/crash --suspend
#v-

But I added:

$ fsysopts /servers/crash-suspend  --suspend --orphan-action=suspend

It didn't change the behaviour -- it still dumped core.  but,

$ fsysopts /servers/crash-suspend  --suspend --orphan-action=kill

did.  It suspended the task.

I then tried to attach to the crash server using gdb, but it said that the pid didn't have any children.

Roland commented on bug-hurd:

Make sure it's not just a bug in the option parsing or something.  Check
with fsysopts /servers/crash.  I note that its trivfs_append_args doesn't
show the --orphan-action setting.  You might fix that.

Try fsysopts --orphan-action=suspend and see if that changes the behavior.
If it does, then the problem is in deciding whether it's an orphan.

Then debug the server and see if crash_how is set correctly.  Because
nothing else (that's not dying) depends on it, it is easy to use gdb on crash.
Break in S_crash_dump_task and see what's going on.