What should happen when a remote session is unceremoniously killed - Unix

This is a discussion on What should happen when a remote session is unceremoniously killed - Unix ; Is there any standard/common practice on what should happen to child processes of a session initiated by telnet/rlogin If a user telnets from machine foo to machine bar. Machine bar starts a telnet process which starts a login process which ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: What should happen when a remote session is unceremoniously killed

  1. What should happen when a remote session is unceremoniously killed

    Is there any standard/common practice on what should happen to child
    processes of a session initiated by telnet/rlogin

    If a user telnets from machine foo to machine bar. Machine bar starts
    a telnet process which starts a login process which starts a shell and
    the user then starts a applicationX

    machine bar:
    in.telnetd
    |_login
    |_shell
    |_applicationX

    Now if the telnet process is killed on machine foo(source of the
    telnet) I've found that telnet dies on bar and init inherits login. No
    signals are sent at all to applicationX (ie SIGHUP)
    machine bar becomes:

    init
    |_login
    |_shell
    |_applicationX


    This causes applicationX problems (bad code) as it is reading from
    stdin, in a loop, which returns EOF now (unchecked return) and then
    writes a BEL to stderr which was freopened to a file (this causes the
    disk to fill pretty quickly)

    applicationX has signal handlers for SIGHUP, SIGINT, SIGTERM, SIGQUIT,
    SIGABRT and ignores SIGCLD, SIGPIPE but not one of those signal
    handlers are called.

    Is there any way for the applicationX to know the session was killed
    or is the fact stdin is now closed and read's return EOF enough to
    assume the applicationX is not in a good state to run.

    Replicated this on Unixware7.1 and Linux 2.6.18


    Adrian


  2. Re: What should happen when a remote session is unceremoniously killed

    Adrian wrote:
    > Is there any standard/common practice on what should happen to child
    > processes of a session initiated by telnet/rlogin
    >
    > If a user telnets from machine foo to machine bar. Machine bar starts
    > a telnet process which starts a login process which starts a shell and
    > the user then starts a applicationX
    >
    > machine bar:
    > in.telnetd
    > |_login
    > |_shell
    > |_applicationX
    >
    > Now if the telnet process is killed on machine foo(source of the
    > telnet) I've found that telnet dies on bar and init inherits login. No
    > signals are sent at all to applicationX (ie SIGHUP)
    > machine bar becomes:
    >
    > init
    > |_login
    > |_shell
    > |_applicationX
    >
    >
    > This causes applicationX problems (bad code) as it is reading from
    > stdin, in a loop, which returns EOF now (unchecked return) and then
    > writes a BEL to stderr which was freopened to a file (this causes the
    > disk to fill pretty quickly)
    >
    > applicationX has signal handlers for SIGHUP, SIGINT, SIGTERM, SIGQUIT,
    > SIGABRT and ignores SIGCLD, SIGPIPE but not one of those signal
    > handlers are called.
    >
    > Is there any way for the applicationX to know the session was killed
    > or is the fact stdin is now closed and read's return EOF enough to
    > assume the applicationX is not in a good state to run.
    >
    > Replicated this on Unixware7.1 and Linux 2.6.18
    >
    >
    > Adrian


    Let me get this straight. You get an END OF FILE condition and you continue to
    read from the file. Do I have that correct?

    Now it would seem to me the prudent thing to do is to make sure you are still
    connected to a interactive terminal before you tried to read again. Do you
    think that might be prudent? man (3) isatty

    Gosh what if someone piped input to the program? How would it know it was at a
    real END OF FILE vs one that generated by a EOF character on an interactive
    terminal?

    Now if your question was from an administrators point, how do I keep programmers
    bugs from screwing with my system, I don't have an answer on this one. You
    could try a profanity filled meeting where you lay down the law, or insisting on
    a charge number for the time to clean up his mess, or maybe even a chat with his
    boss.




  3. Re: What should happen when a remote session is unceremoniously killed

    > Let me get this straight. You get an END OF FILE condition and you continue to
    > read from the file. Do I have that correct?

    Lol the joy of working with 15 year old code

    > Now it would seem to me the prudent thing to do is to make sure you are still
    > connected to a interactive terminal before you tried to read again. Do you
    > think that might be prudent? man (3) isatty

    Wont help - program is a interactive menu driven thing so has to be
    started with a term
    >
    > Gosh what if someone piped input to the program? How would it know it was at a
    > real END OF FILE vs one that generated by a EOF character on an interactive
    > terminal?
    >
    > Now if your question was from an administrators point, how do I keep programmers
    > bugs from screwing with my system, I don't have an answer on this one. You
    > could try a profanity filled meeting where you lay down the law, or insisting on
    > a charge number for the time to clean up his mess, or maybe even a chat with his
    > boss.- Hide quoted text -

    What I want to know is why there are no signals to a program when the
    session that owns them is killed. Is it a telnet implementation
    problem. This cant be the only program thats had this issue - network
    connections are exactly guranteed. How do other unix programs handle
    graceful shutdown when there parent telnet/rlogin session dies

    Adrian


  4. Re: What should happen when a remote session is unceremoniously killed

    Adrian wrote:
    >> Let me get this straight. You get an END OF FILE condition and you continue to
    >> read from the file. Do I have that correct?

    > Lol the joy of working with 15 year old code
    >
    >> Now it would seem to me the prudent thing to do is to make sure you are still
    >> connected to a interactive terminal before you tried to read again. Do you
    >> think that might be prudent? man (3) isatty

    > Wont help - program is a interactive menu driven thing so has to be
    > started with a term
    >> Gosh what if someone piped input to the program? How would it know it was at a
    >> real END OF FILE vs one that generated by a EOF character on an interactive
    >> terminal?
    >>
    >> Now if your question was from an administrators point, how do I keep programmers
    >> bugs from screwing with my system, I don't have an answer on this one. You
    >> could try a profanity filled meeting where you lay down the law, or insisting on
    >> a charge number for the time to clean up his mess, or maybe even a chat with his
    >> boss.- Hide quoted text -

    > What I want to know is why there are no signals to a program when the
    > session that owns them is killed. Is it a telnet implementation
    > problem. This cant be the only program thats had this issue - network
    > connections are exactly guranteed. How do other unix programs handle
    > graceful shutdown when there parent telnet/rlogin session dies


    Consider what the sequence of events is if the user puts the job in the
    background and then logs off.

    The program has a bug. It reads past EOF. Fix the program.

    And consider this. Hangup is a hardware event (frequently a real hardware
    interrupt that a device driver has to handle) generated when the modem hangs up.
    Why would you expect a network connection to generate a hardware event?

  5. Re: What should happen when a remote session is unceremoniously killed

    > Consider what the sequence of events is if the user puts the job in the
    > background and then logs off.

    When you logoff SIGHUP is sent to all processes so is trapped already

    > The program has a bug. It reads past EOF. Fix the program.

    Not disagreeing. But I want to deterime what has happened so hence the
    question about what a closed session is supposed to do

    > And consider this. Hangup is a hardware event (frequently a real hardware
    > interrupt that a device driver has to handle) generated when the modem hangs up.
    > Why would you expect a network connection to generate a hardware event?

    See http://en.wikipedia.org/wiki/SIGHUP
    Section Modern Usage

    >From Open Unix Standard

    http://www.opengroup.org/onlinepubs/...bd_chap11.html
    11.1.10 Modem Disconnect
    If a modem disconnect is detected by the terminal interface for a
    controlling terminal, and if CLOCAL is not set in the c_cflag field
    for the terminal (see Control Modes), the SIGHUP signal shall be sent
    to the controlling process for which the terminal is the controlling
    terminal. Unless other arrangements have been made, this shall cause
    the controlling process to terminate (see exit()). Any subsequent read
    from the terminal device shall return the value of zero, indicating
    end-of-file; see read(). Thus, processes that read a terminal file and
    test for end-of-file can terminate appropriately after a disconnect.
    If the EIO condition as specified in read() also exists, it is
    unspecified whether on EOF condition or [EIO] is returned. Any
    subsequent write() to the terminal device shall return -1, with errno
    set to [EIO], until the device is closed.

    To me it looks like the standards havent quite caught up with network
    connection rather then serial. But it seems network generally emulates
    serial.

    Adrian


  6. Re: What should happen when a remote session is unceremoniously killed

    Barry Margolin wrote:
    > In article <17-dnUAEjOgLeqzanZ2dnUVZ_vyinZ2d@championbroadband.co m>,
    > Golden California Girls wrote:
    >
    >> And consider this. Hangup is a hardware event (frequently a real hardware
    >> interrupt that a device driver has to handle) generated when the modem hangs
    >> up.
    >> Why would you expect a network connection to generate a hardware event?


    > Because telnet is supposed to be emulating a hardware terminal
    > connection. Closing the network connection is analogous to hanging up a
    > modem, so it should have the same effect as far as the application is
    > concerned.


    Specifically, in this case, when telnetd dies, I believe it should either
    explicitly or implicitly end up closing the master side of the pty. And
    that should (hopefully I've got the details right) cause the session leader
    for that terminal to receive SIGHUP. If the session leader is a shell,
    it should send a SIGHUP to the foreground process group, i.e. the program
    which is running amok in this case.

    It seems to me that although the program is not extremely well designed
    (getting EOF and continuing to read), it should get a SIGHUP and should
    thus die anyway. It's not a great design, but it should do the trick
    after an indeterminate amount of spinning in repeated calls to read()
    while waiting for the SIGHUP to arrive.

    So I would be looking for what has gone wrong with this process. Is the
    shell getting the SIGHUP and failing to send it along? Has something
    detached itself from the terminal somewhere along the way? Is the master
    side of the pty not getting closed for some reason (maybe telnetd lets go
    of the pty but something else still has it open)? Is there an exec()
    involved so that a process is replacing the shell but does not know how
    to manage its own children[1]?

    I personally would attack this problem by telnet-ing to the machine,
    starting a shell, and then running "sleep 10000". Then I'd kill the
    telnet client and see if the sleep dies. If it does, I'd study the
    relationship of process groups, process ids, session leaders, etc.
    and compare the tree with the sleep against the tree where the interactive
    program isn't getting the SIGHUP. Something may be amiss in the relationship
    between them.

    I'd probably use a command like (on Linux)...

    ps -e -H -o pid,ppid,pgrp,sess,tty,comm

    .... to look at each tree and see if all the pieces have the same relationship
    to each other.

    - Logan


    [1] When a program's parent is a shell and the program fork()s a lot,
    the children stay in the process group, and the shell manages them
    as a unit when the shell gets the SIGHUP. But if the program
    replaces the shell via exec(), and if the program doesn't know to
    pass the SIGHUP on, the children will linger when the terminal closes.


  7. Re: What should happen when a remote session is unceremoniously killed

    Barry Margolin wrote:
    > In article <17-dnUAEjOgLeqzanZ2dnUVZ_vyinZ2d@championbroadband.co m>,
    > Golden California Girls wrote:
    >
    >> And consider this. Hangup is a hardware event (frequently a real hardware
    >> interrupt that a device driver has to handle) generated when the modem hangs
    >> up.
    >> Why would you expect a network connection to generate a hardware event?

    >
    > Because telnet is supposed to be emulating a hardware terminal
    > connection. Closing the network connection is analogous to hanging up a
    > modem, so it should have the same effect as far as the application is
    > concerned.
    >


    It is like this, the telnet daemon has a port open. When the port closes the
    system properly notifies the daemon that a port has closed, not that the
    controlling terminal has hung up, after all the daemon doesn't have a
    controlling terminal.

    The question then is, should the daemon send a SIGHUP? The Telnet standard says
    no. Because, quoting the telnet man page on my system under the logout command:
    "If the remote side also supports the concept of suspending a user's session
    for later reattachment, the logout argument indicates that you should terminate
    the session immediately." So it appears as if some versions can detach and then
    reattach. Sending a SIGHUP would be wrong.

    In any case the OP is free to write his telnet daemon to send SIGHUP when the
    connection closes.

    He might want to see what SSH does before he goes that far as he may have a
    simple answer to his problem.

  8. Re: What should happen when a remote session is unceremoniously killed

    In article ,
    Golden California Girls wrote:

    > Barry Margolin wrote:
    > > In article <17-dnUAEjOgLeqzanZ2dnUVZ_vyinZ2d@championbroadband.co m>,
    > > Golden California Girls wrote:
    > >
    > >> And consider this. Hangup is a hardware event (frequently a real hardware
    > >> interrupt that a device driver has to handle) generated when the modem
    > >> hangs
    > >> up.
    > >> Why would you expect a network connection to generate a hardware event?

    > >
    > > Because telnet is supposed to be emulating a hardware terminal
    > > connection. Closing the network connection is analogous to hanging up a
    > > modem, so it should have the same effect as far as the application is
    > > concerned.
    > >

    >
    > It is like this, the telnet daemon has a port open. When the port closes the
    > system properly notifies the daemon that a port has closed, not that the
    > controlling terminal has hung up, after all the daemon doesn't have a
    > controlling terminal.


    The daemon doesn't have a controlling terminal, but the login session
    that was started by the daemon does. Its controlling terminal is a pty
    connected to the daemon.

    >
    > The question then is, should the daemon send a SIGHUP?


    Closing the master side of a pty should send a SIGHUP to the session
    leader associated with the slave side.

    > The Telnet standard
    > says
    > no. Because, quoting the telnet man page on my system under the logout
    > command:
    > "If the remote side also supports the concept of suspending a user's session
    > for later reattachment, the logout argument indicates that you should
    > terminate
    > the session immediately." So it appears as if some versions can detach and
    > then
    > reattach. Sending a SIGHUP would be wrong.


    Why are you mentioning this section of the man page? No one ever
    mentioned the logout command. And Unix doesn't support the concept of
    suspending a user's session for later reattachment, so the case that
    this paragraph refers to doesn't apply.



    >
    > In any case the OP is free to write his telnet daemon to send SIGHUP when the
    > connection closes.
    >
    > He might want to see what SSH does before he goes that far as he may have a
    > simple answer to his problem.


    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  9. Re: What should happen when a remote session is unceremoniously killed

    Barry Margolin wrote:

    > Why are you mentioning this section of the man page? No one ever
    > mentioned the logout command. And Unix doesn't support the concept of
    > suspending a user's session for later reattachment, so the case that
    > this paragraph refers to doesn't apply.


    Because Telent did when Telnet was written. Also if that man section is around,
    no reason to think some of the code in the daemon isn't there waiting for the
    right bug to strike. It is the Telnet daemon that isn't doing what the OP
    wants. He might want to find a different version that works like he wants. Or
    maybe test SSH instead.

    Speaking of detach and reattach, I'm wondering if that couldn't be implemented.
    After all, Unix need only see that the user has walked away from the terminal,
    output stopped and no input. The daemon would get the reattach request, all it
    needs do is reattach the pty to the port and it owns both.

  10. Re: What should happen when a remote session is unceremoniously killed

    On Nov 8, 9:37 pm, Golden California Girls
    wrote:

    > Speaking of detach and reattach, I'm wondering if that couldn't be implemented.
    > After all, Unix need only see that the user has walked away from the terminal,
    > output stopped and no input. The daemon would get the reattach request, all it
    > needs do is reattach the pty to the port and it owns both.


    Done and done, though not in telnet.

    http://www.gnu.org/software/screen/

    This is one of my "essential" pieces of Unix software that gets
    immediately installed on every system where I get an account.


+ Reply to Thread