[erlang-bugs] Strange thing in lib/kernel/src/group.erl

[Stefan Zegenhagen]

Hi,

thank you very much for the response.

> The group.erl module is entirely distinct from the shell implementation.
> For example, most shells use shell.erl, but the one used by the SSH
> daemon has a custom one going that's different, and there are also
> concepts such as safe shells.

In fact, we've written our own shell ;-) and provide a command line
interface to view / change device settings after logon.

> In the event that some shell implementation traps exits (and they
> shoulda be expected to do so if they want to handle the 'interrupt'
> signal, which is necessary to deal with some ^G commands such as 'i', in
> any special manner), if the shell is currently blocked in an IO request,
> it will *never* see the 'EXIT' signal given it is busy waiting on
> another message, namely the IO Request's response.

> Because of this specific reason, it might be necessary to kill the
> shell with the 'kill' signal, which cannot be trapped. We just can't
> assume that the other shell will receive it.

Unfortunately, this is only half the truth. I/O requests will usually
not cause the shell to not listen to 'EXIT' requests from the
group_leader() because I/O requests are implemented as message exchange
between those two. Additionally, the io.erl module (which does the I/O
requests), is terribly careful to not miss any exit signal sent by the
group_leader() / I/O channel. It does the following:
 - create a monitor for the group_leader() (or the supplied I/O channel)
 - send an {io_request, *} message to the I/O channel
 - listen for
   * an {io_reply, *}
   * the 'DOWN' message from the process monitor
   * any 'EXIT' message from the I/O channel

If any matching 'DOWN' or 'EXIT' message is received, the correponding
opposite is fetched from the message queue as well and {error,
terminated} is returned to the caller. This is already bad by itself
because it drops the (possibly important) reason of the error.

In conclusion, by using the io module for input/output a shell can never
get stuck in a state where it is unkillable by doing an I/O request.
But it is true that an I/O request blocks the shell for calls/messages
from *OTHER* processes than the I/O channel.

I can see that it might be wanted to get rid of the shell for sure. One
might imagine a case where the shell is trapping exits but "refuses to
die" in response to a trappable exit signal. But then, it is not clear
to me, why the same measure (e.g. exit_shell(kill)) is not taken in the
case where the group.erl's server process is *NOT* executing an I/O
request right now and the shell might truely be blocked by activities
that prevent it from reacting on the exit signal.


But back to the original issue: there are several, discinct reasons why
we might need to forcedly terminate a shell session *AND* to do an
appropriate logging IFF a user is currently logged on (for
security/auditing reasons), e.g.:
 - the serial cable is being unplugged while a user is logged on
 - someone tries to interfere with the system by sending huge amounts
   of binary data over the serial port (possible denial-of-service)
 - ...

Our user_drv.erl replacement exits with an appropriate reason in those
cases and our shell implementation needs to know the exit reason to do
the right thing depending on the situation. This is currently impossible
and I was wondering whether anything could be done about it.

> Now granted, I think it could be possible to send both exit signals
> there (exit_shell(R), exit_shell(kill), exit(R)) just in case in order
> to allow more obvious exit messages, but I'm not sure it would
> necessarily be worth it. Someone from the OTP team (or Robert) could
> voice their opinion there.

Whether this works would certainly depend on the timing. The shell
process should be given enough time to have a chance to process the
first exit signal before being forcedly killed by the second one. Can
this be guaranteed?



Kind regards,

-- 
Dr. Stefan Zegenhagen

arcutronix GmbH
Garbsener Landstr. 10
30419 Hannover
Germany

Tel:   +49 511 277-2734
Fax:   +49 511 277-2709
Email: stefan.zegenhagen@REDACTED
Web:   www.arcutronix.com

*Synchronize the Ethernet*

General Managers: Dipl. Ing. Juergen Schroeder, Dr. Josef Gfrerer -
Legal Form: GmbH, Registered office: Hannover, HRB 202442, Amtsgericht
Hannover; Ust-Id: DE257551767.

Please consider the environment before printing this message.