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

[Stefan Zegenhagen]

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.