Shell – What killed tty main process suddenly

Inside the Hurd FAQ you can find some information about this case:

?? What is the login shell?

{MB} The Hurd has the concept of a not-logged in user. This user has neither user ids nor groups ids. This stems from the fact that the Hurd supports uid and gid sets and one possibility is, of course, the empty set. Rather than deny access in this case, filesystems in the Hurd offer a fourth permission triplet (i.e. rwx) which is used to determine the privileges for users with no credentials. This, however, needs to be enabled on a file by file basis. By default, the `other' permission triplet is used.

The Hurd login shell is a shell running with neither uids nor gids. To restrict access to your files, either enable and change the fourth permission triplet or change the login shell of the 'login' user in the password file to '/bin/loginpr' which implements the standard login prompt.

And remember, Hurd is not UNIX. Its a replacement for the UNIX kernel, using the Match Microkernel, so, many of the concepts from UNIX are not applicable to Hurd.

Mach is a micro-kernel, written at Carnegie Mellon University. A more descriptive term might be a greatest-common-factor kernel, since it provides facilities common to all ``real'' operating systems, such as memory management, inter-process communication, processes, and a bunch of other stuff. Unfortunately, the system calls used to access these facilities are only vaguely related to the familiar and cherished Unix system calls. There are no "fork", "wait", or "sleep" system-calls, no SIGHUPs, nothing like that. All this makes it rather difficult to, say, port GNU Emacs to a Mach box.

References:

• GNU Hurd FAQ inlined
• GNU Hurd Documentation - Authentication

The process your cmd is supposed to be run in will be killed by the SIGHUP signal between the fork() and the exec(), and any nohup wrapper or other stuff will have no chance to run and have any effect. (You can check that with strace)

Instead of nohup, you should set SIGHUP to SIG_IGN (ignore) in the parent shell before executing your background command; if a signal handler is set to "ignore" or "default", that disposition will be inherited through fork() and exec(). Example:

#! /bin/sh
trap '' HUP    # ignore SIGHUP
xclock &
trap - HUP     # back to default

Or:

#! /bin/sh
(trap '' HUP; xclock &)

If you run this script with xfce4-terminal -H -x script.sh, the background command (xclock &) will not be killed by the SIGHUP sent when script.sh terminates.

When a session leader (a process that "owns" the controlling terminal, script.sh in your case) terminates, the kernel will send a SIGHUP to all processes from its foreground process group; but set -m will enable job control and commands started with & will be put in a background process group, and they won't signaled by SIGHUP.

If job control is not enabled (the default for a non-interactive script), commands started with & will be run in the same foreground process group, and the "background" mode will be faked by redirecting their input from /dev/null and letting them ignore SIGINT and SIGQUIT.

Processes started this way from a script which once run as a foreground job but which has already exited won't be signaled with SIGHUP either, since their process group (inherited from their dead parent) is no longer the foreground one on the terminal.

Extra notes:

The "hold mode" seems to be different between xterm and xfce4-terminal (and probably other vte-based terminals). While the former will keep the master side of the pty open, the latter will tear it off after the program run with -e or -x has exited, causing any write to the slave side to fail with EIO. xterm will also ignore WM_DELETE_WINDOW messages (ie it won't close) while there are still processes from the foreground process group running.