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

[Robert Virding]

The shell might be trapping exits and ignore exit messages or running code which does the same. The minimal case: 

1> process_flag(trap_exit, true).
false

In which case the only guaranteed method to kill it is to send the kill signal. Unfortunately you cannot (must not) assume that code is well-behaved even if it has been written with the best intentions. Erlang's error handling mechanism is based on this assumption.

Robert

----- Original Message -----
> From: "Stefan Zegenhagen" <stefan.zegenhagen@REDACTED>
> To: "Fred Hebert" <mononcqc@REDACTED>
> Cc: erlang-bugs@REDACTED
> Sent: Monday, 6 May, 2013 3:54:35 PM
> Subject: Re: [erlang-bugs] Strange thing in lib/kernel/src/group.erl
> 
> Hi,
> 
> 
> thanks again for the detailed answer.
> 
> 
> > > 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.
> > > 
> > 
> > It is indeed not very clear. My guess would be that you can make
> > assumptions about your part of the communication and protocol, but
> > not
> > the others.
> > 
> > A simpler explanation is probably that sometimes back, there was a
> > problem with either implementation and it was simpler to fix with a
> > kill
> > than by adding other ways to handling code (say, before monitoring
> > was
> > added to the language, but while trap_exits were available).
> > 
> > If this is the case, then there would be no reason to keep things
> > the
> > way they are right now IMO, and it would be possible to go with the
> > other exit.
> 
> I guess we'll have to wait for the OTP team to have a look at this,
> then ;-)
> 
> 
> > > 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.
> > 
> > That is definitely a nice use case and I would be personally more
> > open
> > to allowing that than leaving the 'kill' here. I am however not in
> > the
> > OTP team, and do not know everything that has to do with the shell,
> > so
> > this is only my personal opinion.
> > 
> > A possible workaround if things do not come to fruition would be to
> > add
> > layers of indirection -- a process that monitors the shell and the
> > group.erl process and reports the most useful message. Ideally this
> > would not need to be written, although it might still be needed if
> > you
> > deal with older implementations after the fix.
> 
> I had thought of that as well, but tried to avoid that because
> personally, I do not feel comfortable with this (that our session
> monitor would need to know the PID of the shell's group leader). But
> that's merely a matter of taste and if there is need, it can overrule
> the headaches :-)
> 
> > > 
> > > 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?
> > > 
> > 
> > The two-kill approach should work well in the event where the other
> > process is not trapping exits. In that case, the order of signals
> > should
> > be guaranteed, and the first one will kill the process cleanly.
> > 
> > If the process is trapping exits, though, then the first (non-kill)
> > signal will be converted to a message and you're absolutely
> > unlikely to
> > be able to have the time to process the first one before being
> > killed by
> > the second one.
> 
> Unfortunately, since we want to provide <CTRL>+C interrupt
> possibilities, we need to trap exits.
> 
> 
> > The cleanest solution is obviously to be able to just exit/2 with
> > the
> > right reason.
> > 
> > I don't know if the OTP team has managed to transfer all the
> > changelogs
> > relating to the shells when they moved over to git, but I'd be
> > interested to figure out if the exit(Pid,kill) in there is older
> > than
> > monitors -- if so, it would mean that it was probably a workaround
> > for
> > the io module which is no longer necessary today (because it can
> > monitor
> > without altering links or exits being trapped).
> 
> 
> This would be interesting to know, indeed ;-)
> 
> I'm just wondering if there's a better chance of getting the change
> if
> it is made configurable via "io:setopt([{safe_exit_code, true}])"? In
> any case I would not mind to create the patch.
> 
> 
> 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.
> 
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs
>