6

On most UNIX systems this will not leave a process running:

ssh example.net sleep 1000
<<CTRL-C>>

I have tested this behaviour on

aix
centos
debian
dragonfly
freebsd
hpux
irix
mandriva
miros
netbsd
openbsd
openindiana
qnx
redhat
scosysv
solaris-x86
solaris
suse
tru64
ubuntu
unixware

They all clean up as expected. On HURD the login shell is killed as expected, but the sleep is left running as a child of init. Why? And can it be mitigated?

$ uname -a
GNU hurd 0.5 GNU-Mach 1.4-486/Hurd-0.5 i686-AT386 GNU

$ echo $SHELL
/bin/bash

$ /bin/bash --version
GNU bash, version 4.3.24(1)-release (i486-pc-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
Ole Tange
  • 33,591
  • 31
  • 102
  • 198

1 Answers1

1

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: