Re: Shells

On Jun 3, 11:22 pm, "Brian K. White" <b...@xxxxxxxxx> wrote:
----- Original Message -----
From: "Bela Lubkin" <f...@xxxxxxxxxx>

Newsgroups: comp.unix.sco.misc
To: <dis...@xxxxxxx>
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...@xxxxxxxxx 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

.

Relevant Pages

  • Re: Synching volumes on logout
    ... > login script is obviously being run and doing a knoppix desktop setup of some ... There must also be some way of a logout script as well. ... You do not say which shell you are using. ... If you are using bash, ...
    (Debian-User)
  • Re: consent to monitoring banner for ssh
    ... Your approach to set the users' shell to a script seem better ... You don't need set the everyone's login shell, ... everyone's login shell to a locally-written perl script. ...
    (RedHat)
  • Re: detect shell script language
    ... In the 'old' days, when a user typed in a command, the interactive shell would immediately pass it off to 'exec' to execute. ... So, on return from exec with an error status, the shell would fork a copy of itself to try and run the script. ... As a result of the above, it was hard to tell whether the script was a Bourne shell or C shell, so the convention was introduced of using the Bourne shell no op command, as the first line in a Bourne shell script. ...
    (Debian-User)
  • Re: Shells
    ... Is there some auto script one could run to get rid of these -sh ... You may need to amend the user's login ... can change the login shell from Bourne to Korn, ... (they would receive SIGHUP and die). ...
    (comp.unix.sco.misc)
  • Re: Restrict login account to SU access only???
    ... >run cron jobs but not login. ... like you have account1 and account2 that you like to su only. ... and put that script to those users shell in passwd file that you like ...
    (comp.sys.sun.admin)