[MiNT] Logout and SIGHUP

[Guido Flohr <gufl0000@stud.uni-sb.de>]

Hi,

I've come across a little problem while doing a logout: When logging out
actually all processes started directly or indirectly from the login shell
should receive a SIGHUP to notify them that their controlling tty is about
to invalidate.  Unless they catch or ignore SIGHUP (for example because
they run nohup) these processes will die.

Apparently this doesn't work with MiNT and should be fixed. I have a
couple of questions about that:

- How does N.AES behave here? Terminating N.AES can be considered logging
out from the GEM console. Thus N.AES should send a SIGHUP to all of its
children. Unfortunately I cannot test that here because after terminating
N.AES I have all but gibberish on my screen.

- What is the right place to fix that SIGHUP problem for a traditional
console login running a traditional shell? I think the shell (at least
bash) sends a SIGHUP to all members of its own process group on
termination but currently almost every spawned process seems to run in its
own process group, i. e. no effect. How should that be fixed? Make the
shell send a SIGHUP to all of its children and its children's children
instead? Or send SIGHUP to all processes that share the shell's
controlling tty (thus saving those children that have disassociated from
their controlling tty)?  Actually the kernel should send a SIGHUP to all
session members when the session leader dies. But: MiNT (in fact the
MiNTLib) emulates sessions by the assumption "pid == pgid -> session
leader", effectively useless because not only most processes run in their
own private process group but are also session leaders from that point of
view.  

- AES again: It is intended (and apart from the graphics problems it also
works) that it is possible to "logout" from GEM by terminating AES. But
whereas for "regular" processes running on a "regular" tty it is tolerable
that they ignore SIGHUP and survive the logout, the same is not tolerable
for GEM applications. Otherwise there will be processes that use a virtual
(and consequently a physical) VDI workstation that is already closed.  
Not to speak of accessories that shouldn't be started more than once.

Therefore in the GEM runlevel there should be a cleanup tool that
unconditionally kills all GEM applications that have survived the AES (it
would be naive to rely on the user having shut down the AES properly, so
please come up with GEM shutdown tools or the like). But how can I find
out whether a program is a GEM application if GEM is not active? Any
ideas?

Another merely theoratical case: There could also be processes that never
registered with the AES but opened and used a virtual VDI workstation.
Less theoretical: GEM applications have not necessarily closed their
VDI workstations on termination (especially if they have been ungracefully
killed with SIGTERM/SIGKILL).  But the supply of virtual workstations is
not a renewable resource.  What about this:

	for (i = 0; i < 32767; v_clsvwk (i++));
	for (i = 0; i < 32767; v_clswk (i++));

Would my cleanup tool be sentenced to death by an MP kernel for that?
Sorry for asking and not trying out myself; I currently cannot test that.

Comments are welcome.  I am not particularly familiar with GEM internals.

Ciao

Guido
-- 
http://stud.uni-sb.de/~gufl0000/
mailto:guido@atari.org