Shells - SCO

This is a discussion on Shells - SCO ; Hello All, Under SCO Unix 5.0.7 how does one get rid of shells (-sh) left behind when people rlogin/telnet into sco from windows and then shutdown PC or close application without login out , Do these consume the pttys untill ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Shells

  1. Shells

    Hello All,

    Under SCO Unix 5.0.7 how does one get rid of shells (-sh) left behind
    when people rlogin/telnet into sco from windows and then shutdown PC
    or close application without login out , Do these consume the pttys
    untill the system limit is reached and then no one can log in without
    rebooting server ?
    Is there some auto script one could run to get rid of these -sh

    #ps -ef

    root 2133 2083 2 23:43:46 ttyp0 00:00:00 su
    test 1919 1 72 22:38:14 ttyp2 00:29:50 -sh
    test 1957 1 71 22:48:19 ttyp3 00:28:56 -sh


    # who
    root ttyp0 Jun 1 23:35
    #

    note who does not show "test" logged in but ps -ef shows these shells
    running , would they just run at infintum ?
    should not these hangup on close and should not shell die ?


    Many thanks
    Dnix


  2. Re: Shells

    Dnix wrote:
    > Hello All,
    >
    > Under SCO Unix 5.0.7 how does one get rid of shells (-sh) left behind
    > when people rlogin/telnet into sco from windows and then shutdown PC
    > or close application without login out , Do these consume the pttys
    > untill the system limit is reached and then no one can log in without
    > rebooting server ?
    > Is there some auto script one could run to get rid of these -sh
    >
    > #ps -ef
    >
    > root 2133 2083 2 23:43:46 ttyp0 00:00:00 su
    > test 1919 1 72 22:38:14 ttyp2 00:29:50 -sh
    > test 1957 1 71 22:48:19 ttyp3 00:28:56 -sh
    >
    >
    > # who
    > root ttyp0 Jun 1 23:35
    > #
    >
    > note who does not show "test" logged in but ps -ef shows these shells
    > running , would they just run at infintum ?
    > should not these hangup on close and should not shell die ?


    I can't remember the details. You may need to amend the user's login
    scripts to trap a hangup (or other) signal and exit. If necessary you
    can change the login shell from Bourne to Korn, csh or some other shell
    that offers the features needed. I have done this some years ago under
    OSR507 for telnet connections from PCs.



  3. Re: Shells

    "RedGrittyBrick" wrote:

    > Dnix wrote:


    > > Under SCO Unix 5.0.7 how does one get rid of shells (-sh) left behind
    > > when people rlogin/telnet into sco from windows and then shutdown PC
    > > or close application without login out , Do these consume the pttys
    > > untill the system limit is reached and then no one can log in without
    > > rebooting server ?
    > > Is there some auto script one could run to get rid of these -sh
    > >
    > > #ps -ef
    > >
    > > root 2133 2083 2 23:43:46 ttyp0 00:00:00 su
    > > test 1919 1 72 22:38:14 ttyp2 00:29:50 -sh
    > > test 1957 1 71 22:48:19 ttyp3 00:28:56 -sh
    > >
    > > # who
    > > root ttyp0 Jun 1 23:35
    > >
    > > note who does not show "test" logged in but ps -ef shows these shells
    > > running , would they just run at infintum ?
    > > should not these hangup on close and should not shell die ?

    >
    > I can't remember the details. You may need to amend the user's login
    > scripts to trap a hangup (or other) signal and exit. If necessary you
    > can change the login shell from Bourne to Korn, csh or some other shell
    > that offers the features needed. I have done this some years ago under
    > OSR507 for telnet connections from PCs.


    In fact the shell would normally exit under the described conditions
    (they would receive SIGHUP and die). The `ps` output shows large
    numbers (72, 71) in the "C" column, showing that both of those shells
    are not just lingering, they're spinning in tight CPU loops. This can
    happen if the script they were running _does_ trap SIGHUP, and then does
    something stupid with it.

    The original poster should examine what those users / shells are
    running, make sure it has sensible SIGHUP handling. One way to make it
    "sensible" is to just remove the SIGHUP handler so the shell's normal
    behavior comes through.

    `lsof -p1919,1957` might be useful to show what scripts are being run.

    `trace -p1919` or `truss -p1919` might be useful to see what the
    processes are doing in those loops. (Both are system calls tracers in
    OSR507 -- `truss` in the base OS, `trace` in the devsys. Both are
    moderately defective, they tend to do things like mistakenly kill the
    process being traced. But since the original poster apparently has an
    ongoing supply of these rogue processes, that shouldn't be a problem
    here. Try both until you know which one is less allergic to this
    particular situation.)

    >Bela<


  4. Re: Shells

    Many thanks Bela ,

    It was, in fact, me testing terminal emulation , remote admin through
    telnet/rlogin .
    I was trying to find a good terminal emulation for running SCOADMIN ,
    and at times I would get garbled screens and had to disconnect
    especially with scoansi the whole scoadmin would just show wierd
    chars , and could not find menu , so had to disconnect and ending up
    wondering whether this would happen with normal uses when I went
    live , thanks for clarifying the situation

    Dnix


  5. Re: Shells

    On Sat, 2 Jun 2007, Dnix wrote:

    > Many thanks Bela ,
    >
    > It was, in fact, me testing terminal emulation , remote admin through
    > telnet/rlogin .
    > I was trying to find a good terminal emulation for running SCOADMIN ,
    > and at times I would get garbled screens and had to disconnect
    > especially with scoansi the whole scoadmin would just show wierd
    > chars , and could not find menu , so had to disconnect and ending up
    > wondering whether this would happen with normal uses when I went
    > live , thanks for clarifying the situation


    If you're looking for a good telnet, please try Anzio, from the site
    below.

    Regards,
    .....Bob Rasmussen, President, Rasmussen Software, Inc.

    personal e-mail: ras@anzio.com
    company e-mail: rsi@anzio.com
    voice: (US) 503-624-0360 (9:00-6:00 Pacific Time)
    fax: (US) 503-624-0760
    web: http://www.anzio.com

  6. Re: Shells


    ----- Original Message -----
    From: "Bela Lubkin"
    Newsgroups: comp.unix.sco.misc
    To:
    Sent: Saturday, June 02, 2007 4:53 PM
    Subject: Re: Shells


    > "RedGrittyBrick" wrote:
    >
    >> Dnix wrote:

    >
    >> > Under SCO Unix 5.0.7 how does one get rid of shells (-sh) left behind
    >> > when people rlogin/telnet into sco from windows and then shutdown PC
    >> > or close application without login out , Do these consume the pttys
    >> > untill the system limit is reached and then no one can log in without
    >> > rebooting server ?
    >> > Is there some auto script one could run to get rid of these -sh
    >> >
    >> > #ps -ef
    >> >
    >> > root 2133 2083 2 23:43:46 ttyp0 00:00:00 su
    >> > test 1919 1 72 22:38:14 ttyp2 00:29:50 -sh
    >> > test 1957 1 71 22:48:19 ttyp3 00:28:56 -sh
    >> >
    >> > # who
    >> > root ttyp0 Jun 1 23:35
    >> >
    >> > note who does not show "test" logged in but ps -ef shows these shells
    >> > running , would they just run at infintum ?
    >> > should not these hangup on close and should not shell die ?

    >>
    >> I can't remember the details. You may need to amend the user's login
    >> scripts to trap a hangup (or other) signal and exit. If necessary you
    >> can change the login shell from Bourne to Korn, csh or some other shell
    >> that offers the features needed. I have done this some years ago under
    >> OSR507 for telnet connections from PCs.

    >
    > In fact the shell would normally exit under the described conditions
    > (they would receive SIGHUP and die). The `ps` output shows large
    > numbers (72, 71) in the "C" column, showing that both of those shells
    > are not just lingering, they're spinning in tight CPU loops. This can
    > happen if the script they were running _does_ trap SIGHUP, and then does
    > something stupid with it.
    >
    > The original poster should examine what those users / shells are
    > running, make sure it has sensible SIGHUP handling. One way to make it
    > "sensible" is to just remove the SIGHUP handler so the shell's normal
    > behavior comes through.
    >
    > `lsof -p1919,1957` might be useful to show what scripts are being run.
    >
    > `trace -p1919` or `truss -p1919` might be useful to see what the
    > processes are doing in those loops. (Both are system calls tracers in
    > OSR507 -- `truss` in the base OS, `trace` in the devsys. Both are
    > moderately defective, they tend to do things like mistakenly kill the
    > process being traced. But since the original poster apparently has an
    > ongoing supply of these rogue processes, that shouldn't be a problem
    > here. Try both until you know which one is less allergic to this
    > particular situation.)
    >
    >>Bela<


    Somehow a reply of mine completely got lost.
    I pointed out that his who/ps output only showed idle 30 minutes, and that
    "man telnetd" says that, by default, after 2 hours 10 minutes idle sessions
    will be closed (presumably sending HUP or TERM or something to all children.
    So maybe theres no problem if thats good enough. And that that was just
    telnetd, and other login/tty providing daemons (rlogin, ssh , scp, facetwin)
    have different default behaviours, different cofiguration options available,
    and different methods of applying those controls.

    ....I think I know what happened now and that post may appear tomorrow. But
    thats the gist of it.

    Also I mentioned the existence of idleout which works at a completely
    different level and is just a script that runs "who" at it's heart, and so
    if who doesn't show these stale processes then idleout is not the fix he's
    looking for. Just trying to be complete.

    Brian K. White brian@aljex.com http://www.myspace.com/KEYofR
    +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
    filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!


  7. Re: Shells

    On Jun 3, 11:22 pm, "Brian K. White" wrote:
    > ----- Original Message -----
    > From: "Bela Lubkin"
    >
    > Newsgroups: comp.unix.sco.misc
    > To:
    > Sent: Saturday, June 02, 2007 4:53 PM
    > Subject: Re: Shells
    >
    > > "RedGrittyBrick" wrote:

    >
    > >> Dnix wrote:

    >
    > >> > Under SCO Unix 5.0.7 how does one get rid of shells (-sh) left behind
    > >> > when people rlogin/telnet into sco from windows and then shutdown PC
    > >> > or close application without login out , Do these consume the pttys
    > >> > untill the system limit is reached and then no one can log in without
    > >> > rebooting server ?
    > >> > Is there some auto script one could run to get rid of these -sh

    >
    > >> > #ps -ef

    >
    > >> > root 2133 2083 2 23:43:46 ttyp0 00:00:00 su
    > >> > test 1919 1 72 22:38:14 ttyp2 00:29:50 -sh
    > >> > test 1957 1 71 22:48:19 ttyp3 00:28:56 -sh

    >
    > >> > # who
    > >> > root ttyp0 Jun 1 23:35

    >
    > >> > note who does not show "test" logged in but ps -ef shows these shells
    > >> > running , would they just run at infintum ?
    > >> > should not these hangup on close and should not shell die ?

    >
    > >> I can't remember the details. You may need to amend the user's login
    > >> scripts to trap a hangup (or other) signal and exit. If necessary you
    > >> can change the login shell from Bourne to Korn, csh or some other shell
    > >> that offers the features needed. I have done this some years ago under
    > >> OSR507 for telnet connections from PCs.

    >
    > > In fact the shell would normally exit under the described conditions
    > > (they would receive SIGHUP and die). The `ps` output shows large
    > > numbers (72, 71) in the "C" column, showing that both of those shells
    > > are not just lingering, they're spinning in tight CPU loops. This can
    > > happen if the script they were running _does_ trap SIGHUP, and then does
    > > something stupid with it.

    >
    > > The original poster should examine what those users / shells are
    > > running, make sure it has sensible SIGHUP handling. One way to make it
    > > "sensible" is to just remove the SIGHUP handler so the shell's normal
    > > behavior comes through.

    >
    > > `lsof -p1919,1957` might be useful to show what scripts are being run.

    >
    > > `trace -p1919` or `truss -p1919` might be useful to see what the
    > > processes are doing in those loops. (Both are system calls tracers in
    > > OSR507 -- `truss` in the base OS, `trace` in the devsys. Both are
    > > moderately defective, they tend to do things like mistakenly kill the
    > > process being traced. But since the original poster apparently has an
    > > ongoing supply of these rogue processes, that shouldn't be a problem
    > > here. Try both until you know which one is less allergic to this
    > > particular situation.)

    >
    > >>Bela<

    >
    > Somehow a reply of mine completely got lost.
    > I pointed out that his who/ps output only showed idle 30 minutes, and that
    > "man telnetd" says that, by default, after 2 hours 10 minutes idle sessions
    > will be closed (presumably sending HUP or TERM or something to all children.
    > So maybe theres no problem if thats good enough. And that that was just
    > telnetd, and other login/tty providing daemons (rlogin, ssh , scp, facetwin)
    > have different default behaviours, different cofiguration options available,
    > and different methods of applying those controls.
    >
    > ...I think I know what happened now and that post may appear tomorrow. But
    > thats the gist of it.
    >
    > Also I mentioned the existence of idleout which works at a completely
    > different level and is just a script that runs "who" at it's heart, and so
    > if who doesn't show these stale processes then idleout is not the fix he's
    > looking for. Just trying to be complete.
    >
    > Brian K. White b...@aljex.com http://www.myspace.com/KEYofR
    > +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
    > filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!


    You might consider switching to SSH. Besides all the security
    advantages, it can be configured with TCPKeepAlive so the server
    immediately "notices" that the clients are dead. See sshd_config(5).

    --RLR


  8. Re: Shells


    ----- Original Message -----
    From: "ThreeStar"
    Newsgroups: comp.unix.sco.misc
    To:
    Sent: Monday, June 04, 2007 10:52 AM
    Subject: Re: Shells


    > On Jun 3, 11:22 pm, "Brian K. White" wrote:
    >> ----- Original Message -----
    >> From: "Bela Lubkin"
    >>
    >> Newsgroups: comp.unix.sco.misc
    >> To:
    >> Sent: Saturday, June 02, 2007 4:53 PM
    >> Subject: Re: Shells
    >>
    >> > "RedGrittyBrick" wrote:

    >>
    >> >> Dnix wrote:

    >>
    >> >> > Under SCO Unix 5.0.7 how does one get rid of shells (-sh) left
    >> >> > behind
    >> >> > when people rlogin/telnet into sco from windows and then shutdown PC
    >> >> > or close application without login out , Do these consume the pttys
    >> >> > untill the system limit is reached and then no one can log in
    >> >> > without
    >> >> > rebooting server ?
    >> >> > Is there some auto script one could run to get rid of these -sh

    >>
    >> >> > #ps -ef

    >>
    >> >> > root 2133 2083 2 23:43:46 ttyp0 00:00:00 su
    >> >> > test 1919 1 72 22:38:14 ttyp2 00:29:50 -sh
    >> >> > test 1957 1 71 22:48:19 ttyp3 00:28:56 -sh

    >>
    >> >> > # who
    >> >> > root ttyp0 Jun 1 23:35

    >>
    >> >> > note who does not show "test" logged in but ps -ef shows these
    >> >> > shells
    >> >> > running , would they just run at infintum ?
    >> >> > should not these hangup on close and should not shell die ?

    >>
    >> >> I can't remember the details. You may need to amend the user's login
    >> >> scripts to trap a hangup (or other) signal and exit. If necessary you
    >> >> can change the login shell from Bourne to Korn, csh or some other
    >> >> shell
    >> >> that offers the features needed. I have done this some years ago under
    >> >> OSR507 for telnet connections from PCs.

    >>
    >> > In fact the shell would normally exit under the described conditions
    >> > (they would receive SIGHUP and die). The `ps` output shows large
    >> > numbers (72, 71) in the "C" column, showing that both of those shells
    >> > are not just lingering, they're spinning in tight CPU loops. This can
    >> > happen if the script they were running _does_ trap SIGHUP, and then
    >> > does
    >> > something stupid with it.

    >>
    >> > The original poster should examine what those users / shells are
    >> > running, make sure it has sensible SIGHUP handling. One way to make it
    >> > "sensible" is to just remove the SIGHUP handler so the shell's normal
    >> > behavior comes through.

    >>
    >> > `lsof -p1919,1957` might be useful to show what scripts are being run.

    >>
    >> > `trace -p1919` or `truss -p1919` might be useful to see what the
    >> > processes are doing in those loops. (Both are system calls tracers in
    >> > OSR507 -- `truss` in the base OS, `trace` in the devsys. Both are
    >> > moderately defective, they tend to do things like mistakenly kill the
    >> > process being traced. But since the original poster apparently has an
    >> > ongoing supply of these rogue processes, that shouldn't be a problem
    >> > here. Try both until you know which one is less allergic to this
    >> > particular situation.)

    >>
    >> >>Bela<

    >>
    >> Somehow a reply of mine completely got lost.
    >> I pointed out that his who/ps output only showed idle 30 minutes, and
    >> that
    >> "man telnetd" says that, by default, after 2 hours 10 minutes idle
    >> sessions
    >> will be closed (presumably sending HUP or TERM or something to all
    >> children.
    >> So maybe theres no problem if thats good enough. And that that was just
    >> telnetd, and other login/tty providing daemons (rlogin, ssh , scp,
    >> facetwin)
    >> have different default behaviours, different cofiguration options
    >> available,
    >> and different methods of applying those controls.
    >>
    >> ...I think I know what happened now and that post may appear tomorrow.
    >> But
    >> thats the gist of it.
    >>
    >> Also I mentioned the existence of idleout which works at a completely
    >> different level and is just a script that runs "who" at it's heart, and
    >> so
    >> if who doesn't show these stale processes then idleout is not the fix
    >> he's
    >> looking for. Just trying to be complete.
    >>
    >> Brian K. White b...@aljex.com http://www.myspace.com/KEYofR
    >> +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
    >> filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!

    >
    > You might consider switching to SSH. Besides all the security
    > advantages, it can be configured with TCPKeepAlive so the server
    > immediately "notices" that the clients are dead. See sshd_config(5).


    The obvious security differeces aside, the stock telnetd already does that.
    The 2 hour 10 minute time is just what the various default timings all add
    up to.
    After 7200 seconds it starts sending keepalive probes which the client is
    supposed to acknowledge, sending one probe every 75 seconds, sending 8
    probes before giving up.
    All those numbers are configurable though, and, generally you want it
    somewhat loose like that to allow for normal network congestion and
    transient breaks.

    Brian K. White brian@aljex.com http://www.myspace.com/KEYofR
    +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
    filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!



+ Reply to Thread