Users Process still active after logging out
Jim Simpson
connecting to a scounix server over tcpip network, user ends session by
closing the window before logging off. The user is not listed by Who but the
processes this user started are still active and the ttyp is still in use
therefore the number of users are increasing over time until the server is
shutdown
Any help would be gratefully received
Jim
Scotland
Karel Adams
"Jim Simpson" <j...@hcsltd.com> schreef in bericht news:9nqncg$2nd$1...@uranium.btinternet.com...
> Can anyone help?
> connecting to a scounix server over tcpip network, user ends session by
> closing the window before logging off. The user is not listed by Who but the
> processes this user started are still active and the ttyp is still in use
> therefore the number of users are increasing over time until the server is
> shutdown
All of this is perfectly normal and to be expected.
Where you write 'logging off' you obviously mean
'logging out of winshit'. However by just closing
their (telnet?) window, users do not quit the
application and so their invocation of the app
keeps hanging round eternally.
If you had expected anything else you might wish
to take some thinking/learning.
Correct sequence for your users is to
1) properly any application they have running
2) leave unix (ctrl-d or 'exit' at the $ prompt),
this will make the ΔΎ$ telnet say 'connection to host lost'
3) close the telnet window
If your situation is different, please excuse me for not
having read so from your cryptic description.
>
> Any help would be gratefully received
>
> Jim
> Scotland
(inclined to rude jesting about football figures
but will restrain myself on grounds of good manners
(no I'm not a sports addict at all (neither a nationalist)))
John DuBois
Jim Simpson <j...@hcsltd.com> wrote:
>connecting to a scounix server over tcpip network, user ends session by
>closing the window before logging off. The user is not listed by Who but the
>processes this user started are still active and the ttyp is still in use
>therefore the number of users are increasing over time until the server is
>shutdown
If the user isn't listed by 'who', it indicates that the system detected the
terminated connection and logged the user out. In this case, a hangup signal
is sent to the user's processes. However, poorly written applications are free
to ignore that signal or even to arrange that no such signal is sent at logout
time. Without further information, all we can say is that the culprits most
likely include both the user and the application that was running on the
server.
John
--
John DuBois spc...@armory.com. KC6QKZ/AE http://www.armory.com./~spcecdt/
Steve Fabac
John,
I have the same problem with a COBOL application on one of my client's
SCO 5.0.5 machines. Always the same user and always running the same
program. I have not been able to get the programmer to track down
any code to "ignore hang-up."
I have just started writing the following script to run from cron
to kill the orphaned processes. It's still in testing (just logging now
looking for inappropriate processes listed in killidle.log) but when I
tried uncommenting the system( "kill " $2 ) command, it killed the
specified process.
My question is why system( "kill -15 " $2 ) results in a usage message
for kill? The "kill " $2 by itself worked but may be more severe than
I want. I'd prefer to run "kill -15 " $2 followed with a sleep and then
"kill -9 " $2 to cache any process that ignores the -15 signal.
> :
> # @(#) killidle 1.1 9/12/01 smf
> # Script to test for abandoned vedco processes and to kill them
> #
> ps -ef | awk ' BEGIN {
> while ( "who" | getline ) {
> aray[ $2 ] = $1
> # print $2, $1 # uncomment for debugging
> }
> system( "sleep 6" )
> }
> $6 ~ /ttyp/ {
> if ( aray[ $6 ] > "" ) next
> if ( $8 == "login" ) next
> system( "date >> /usr/adm/killidle.log" )
> close( "date >> /usr/adm/killidle.log" )
> print $0 >> "/usr/adm/killidle.log"
> close("/usr/adm/killidle.log")
> # print $2, $6, $1 # uncomment for debugging
> # bob = system( "kill " $2 )
> } '
--
Steve Fabac
S.M. Fabac & Associates
816/765-1670
Jim Simpson
that my users are dum and do not follow your wise teachings on the correct
procedure to logoff how do I as a humble programmer kill off the process
started by these illinformed rowdy users who refuse to accept the wise
teachings of Karel
inclined to large dose of sarcasim
an yes my football time is crap but we have a good time losing
Karel Adams <k_a...@glo.be> wrote in message
news:6G6o7.5796$35.5...@iguano.antw.online.be...
Bill Vermillion
>I have just started writing the following script to run from cron
>to kill the orphaned processes. It's still in testing (just logging now
>looking for inappropriate processes listed in killidle.log) but when I
>tried uncommenting the system( "kill " $2 ) command, it killed the
>specified process.
>My question is why system( "kill -15 " $2 ) results in a usage message
>for kill? The "kill " $2 by itself worked but may be more severe than
>I want. I'd prefer to run "kill -15 " $2 followed with a sleep and then
>"kill -9 " $2 to cache any process that ignores the -15 signal.
Actually the prefered order is typically is SIGTERM - aka 15 - a
software-termination signal, then a SIGINT - aka 1 - interupt
the program - before you perform a SIGKILL - aka 9 - terminate with
extreme prejudice.
--
Bill Vermillion - bv @ wjv . com
John DuBois
>SCO 5.0.5 machines. Always the same user and always running the same
>program. I have not been able to get the programmer to track down
>any code to "ignore hang-up."
While the app is running, find its process ID and then
(as root) run crash. From within crash, do:
u #processid
Among other things, that will list the signal disposition.
If signal 1 (HUP) is listed, it is being ignored or trapped
(which means the process is free to respond however it wants,
including ignoring it). This is one of several ways in which
a process can avoid hangup termination.
>My question is why system( "kill -15 " $2 ) results in a usage message
>for kill?
kill produces a number of different usage messages.
Which particular one are you referring to?
You might want to look at ftp://ftp.armory.com./pub/admin/nidleout
Robert Carnegie
"kill" by default is "kill -15" which we all agree is preferred.
As to why an error message, evidently something is wrong when it
gets to the awk line "bob = system( "kill -15 " $2 )" but I can't
read awk. Is it possible that $2 is coming up empty sometimes?
"kill" and "kill -15" with no other parameters both get the message
"Bad argument count" on our OpenServer 5.0.6A.
You don't have a stray quote mark in the rest of the awk script?
Those have fascinating consequences. I don't think a separate
script, or function, or single-word alias for "kill -1", &c.,
is the way to go. (But feel free.)
Steve Fabac
>
> bi...@wjv.com (Bill Vermillion) wrote in message news:<GJnn8...@wjv.com>...
> > In article <3BA142F7...@att.net>, Steve Fabac <smf...@att.net> wrote:
> >
> > >I have just started writing the following script to run from cron
> > >to kill the orphaned processes. It's still in testing (just logging now
> > >looking for inappropriate processes listed in killidle.log) but when I
> > >tried uncommenting the system( "kill " $2 ) command, it killed the
> > >specified process.
> >
> > >My question is why system( "kill -15 " $2 ) results in a usage message
> > >for kill? The "kill " $2 by itself worked but may be more severe than
> > >I want. I'd prefer to run "kill -15 " $2 followed with a sleep and then
> > >"kill -9 " $2 to cache any process that ignores the -15 signal.
> >
> > Actually the prefered order is typically is SIGTERM - aka 15 - a
> > software-termination signal, then a SIGINT - aka 1 - interupt
> > the program - before you perform a SIGKILL - aka 9 - terminate with
> > extreme prejudice.
>
> "kill" by default is "kill -15" which we all agree is preferred.
> As to why an error message, evidently something is wrong when it
> gets to the awk line "bob = system( "kill -15 " $2 )" but I can't
> read awk. Is it possible that $2 is coming up empty sometimes?
This script is still running in debug mode and I am waiting for client's
system to have another episode where the script will start logging the
pid and user name to /usr/adm/killidle.log. When that happens, I will
be able to answer your questions about usage messages.
When I first started the script and the print $2, $6, $1 below was
listing the correct PID, terminal, and user name:
> print $0 >> "/usr/adm/killidle.log"
> close("/usr/adm/killidle.log")
> # print $2, $6, $1 # uncomment for debugging
> # bob = system( "kill " $2 )
When I uncommented bob = etc. above, the script killed the listed
processes. Prior to that, the script was "kill -15 " $2 and it
failed. No other changes were made except to drop the -15.
> "kill" and "kill -15" with no other parameters both get the message
> "Bad argument count" on our OpenServer 5.0.6A.
>
> You don't have a stray quote mark in the rest of the awk script?
> Those have fascinating consequences. I don't think a separate
> script, or function, or single-word alias for "kill -1", &c.,
> is the way to go. (But feel free.)
--
Steve Fabac
Thanks for the above information John. When the client's system
experiences the problem again, I will look into the user's pid with
crash as you suggested and post the results.
I have downloaded nidleout but have not read it yet. The quick look over
I gave it makes it look intimidating.
Tony Lawrence
> I have downloaded nidleout but have not read it yet. The quick look over
> I gave it makes it look intimidating.
Oh, gosh- it really isn't. If you are trying to UNDERSTAND the ksh
programming, yeah, it's quite a complex script- but USING it is a piece of
cake.
--
Tony Lawrence (to...@aplawrence.com)
SCO/Linux articles, help, book reviews, tests,
job listings and more : http://www.pcunix.com
Han van Capelle
"Jim Simpson" <j...@hcsltd.com> wrote in message
news:9nqncg$2nd$1...@uranium.btinternet.com...
problems.
When a user closes the emulator window before logging off, Bungee will keep
the session 'alive'.
Then there are 2 options :
1. The user comes back, logs on and automatically gets the session back (the
user will get back in the application at the precise point he or she left
it!)
2. The sysadmin can connect to that session and close it the way the user
should have done.
Other options of Bungee are:
- Remote control, remote user support (take over users screen and keyboard,
like Doublevision and peek)
- limiting the number of times a user is allowed to log on.
- and more....
Installation of Bungee does not affect the kernal.
Bungee comes with a Windows graphical administration program.
Han.
Spencer Clark
Han.
Sounds like something I could make use of. Any suggestions where this
package is available from, either download as a trial or to purchase ? (OH
yes if purchase I reside in the UK)
Thanks
Spencer Clark
Legal Disclaimer:
Internet communications are not secure and therefore Exact Abacus does
not accept legal responsibility for the contents of this message. Any views
or opinions presented are solely those of the author and do not necessarily
represent those of Exact Abacus unless otherwise specifically stated.
Han van Capelle
"Spencer Clark" <spe...@exact3ex.co.uk> wrote in message
news:BFEGIPMNCAKICFBAOD...@exact3ex.co.uk...
Spencer,
We develloped Bungee together with two German companies.
So, we are selling it.
I can mail Bungee over together with a 30 days eval key.
Total data is two times 800KB (a part for installation on SCO and a part for
installation on the PC).
To generate an eval key I need the EXACT output of the command uname -a on
the machine your going to install.
Besides, I have to know howmany concurrent sessions you will have.
Let me know if thats o.k.
Regards, Han.
Steve Fabac
>
> Robert Carnegie wrote:
> >
> > bi...@wjv.com (Bill Vermillion) wrote in message news:<GJnn8...@wjv.com>...
> > > In article <3BA142F7...@att.net>, Steve Fabac <smf...@att.net> wrote:
> > >
> > > >I have just started writing the following script to run from cron
> > > >to kill the orphaned processes. It's still in testing (just logging now
Snip
> > "kill" by default is "kill -15" which we all agree is preferred.
> > As to why an error message, evidently something is wrong when it
> > gets to the awk line "bob = system( "kill -15 " $2 )" but I can't
> > read awk. Is it possible that $2 is coming up empty sometimes?
>
> This script is still running in debug mode and I am waiting for client's
> system to have another episode where the script will start logging the
> pid and user name to /usr/adm/killidle.log. When that happens, I will
> be able to answer your questions about usage messages.
>
> When I first started the script and the print $2, $6, $1 below was
> listing the correct PID, terminal, and user name:
>
> > print $0 >> "/usr/adm/killidle.log"
> > close("/usr/adm/killidle.log")
> > # print $2, $6, $1 # uncomment for debugging
> > # bob = system( "kill " $2 )
>
> When I uncommented bob = etc. above, the script killed the listed
> processes. Prior to that, the script was "kill -15 " $2 and it
> failed. No other changes were made except to drop the -15.
>
> > "kill" and "kill -15" with no other parameters both get the message
> > "Bad argument count" on our OpenServer 5.0.6A.
Found the problem: system ( "kill -15" $2 ) Fails because there
is no space after -15 and before the ". Thus the argument to kill is
-15PID ( -15207 for PID = 206 ) and that "ain't a valid signal."
The correct construct is system ( "Kill -15 " $2 ) and it works.
Steve Fabac
> In article <3BA142F7...@att.net>, Steve Fabac <smf...@att.net>
wrote:
> >I have the same problem with a COBOL application on one of my client's
> >SCO 5.0.5 machines. Always the same user and always running the same
> >program. I have not been able to get the programmer to track down
> >any code to "ignore hang-up."
>
> While the app is running, find its process ID and then
> (as root) run crash. From within crash, do:
>
> u #processid
>
> Among other things, that will list the signal disposition.
> If signal 1 (HUP) is listed, it is being ignored or trapped
> (which means the process is free to respond however it wants,
> including ignoring it). This is one of several ways in which
> a process can avoid hangup termination.
John the following is the output of the crash command you recommended
above when applied to process ID 27678 first and then 27680. What do
you make of the output?
output of killidle:
Wed Oct 10 11:30:00 CDT 2001
team5 27678 1 0 14:53:18 ttyp5 00:00:00 -ksh
team5 27680 27678 80 14:53:18 ttyp5 18:05:23 runcobol85 OEEPK -k
-c/usr1/bin/configure -k
output of crash | tee /tmp/crash.log:
command execuited: u #27678 and then u #27680:
dumpfile = /dev/mem, namelist = /unix, outfile = stdout
> PER PROCESS USER AREA FOR PROCESS 92
USER ID's: uid: 212, gid: 100, real uid: 212, real gid: 100
supplementary gids: 100
PROCESS TIMES: user: 0, sys: 0, child user: 0, child sys: 1
PROCESS MISC:
command: ksh, psargs: -ksh
proc: P#92, cntrl tty: 58,5
start: Tue Oct 9 14:53:18 2001
mem: 0xd5, type: fork
proc/text lock: none
current directory: I#1816
OPEN FILES AND POFILE FLAGS:
[ 0]: F#276 r [ 1]: F#276 w [ 2]: F#276 w
[30]: F#441 c r
FILE I/O:
u_base: 0x807074e, file offset: 1024, bytes: 1024
segment: data, cmask: 0002, ulimit: 4194303
file mode(s): read
SIGNAL DISPOSITION:
sig# signal oldmask sigmask
1: 0x8051050 - 1
2: 0x8051a00 - 2
3: 0x8051a00 - 3
4: 0x8051050 - 4
5: 0x8051050 - 5
6: 0x8051050 - 6
7: 0x8051050 - 7
8: 0x8051050 - 8
10: 0x8051050 - 10
12: 0x8051050 - 12
13: 0x8051050 - 13
14: 0x8051a00 suspend 14
15: 0x8051050 - 15
16: 0x8051050 - 16
17: 0x8051050 - 17
18: default - 18
20: 0x8051a00 - 20
24: ignore - 24
26: ignore - 26
27: ignore - 27
31: 0x8051a00 - 31
> PER PROCESS USER AREA FOR PROCESS 103
USER ID's: uid: 212, gid: 100, real uid: 212, real gid: 100
supplementary gids: 100
PROCESS TIMES: user: 2246199, sys: 4253106, child user: 5, child sys: 7
PROCESS MISC:
command: runcobol85, psargs: runcobol85 OEEPK -k
-c/usr1/bin/configure
-k
proc: P#103, cntrl tty: 58,5
start: Tue Oct 9 14:53:18 2001
mem: 0x5cde8471, type: exec
proc/text lock: none
current directory: I#1816
OPEN FILES AND POFILE FLAGS:
[ 0]: F#276 r [ 1]: F#276 w [ 2]: F#276 w
FILE I/O:
u_base: 0x7ffff99f, file offset: 216406, bytes: 1
segment: data, cmask: 0002, ulimit: 4194303
file mode(s): read
SIGNAL DISPOSITION:
sig# signal oldmask sigmask
1: 0x4310 -
2: 0x4310 -
3: 0x4310 -
6: 0x4344 -
13: ignore -
14: 0x4300 suspend
15: 0x4310 -
24: ignore -
26: ignore -
27: ignore -
>
>
> John
> --
> John DuBois spc...@armory.com. KC6QKZ/AE
http://www.armory.com./~spcecdt/
>
John DuBois
>John the following is the output of the crash command you recommended
>above when applied to process ID 27678 first and then 27680. What do
>you make of the output?
This shows that the cobol program is indeed trapping hangup, meaning that it
can respond to a logout notification in any way it chooses, which in this case
is apparently to just ignore it.
John
>
>output of killidle:
>
> team5 27680 27678 80 14:53:18 ttyp5 18:05:23 runcobol85 OEEPK -k -c/usr1/bin/configure -k
>
Steve Fabac
>
> In article <3BC4BCE1...@att.net>, Steve Fabac <smf...@att.net> wrote:
> >John the following is the output of the crash command you recommended
> >above when applied to process ID 27678 first and then 27680. What do
> >you make of the output?
>
> This shows that the cobol program is indeed trapping hangup, meaning that it
> can respond to a logout notification in any way it chooses, which in this case
> is apparently to just ignore it.
>
> John
Thanks for the reply John. Will you take a moment to comment the crash
output below to mark what shows that this program is trapping hangup?
I am not a C programmer and the information presented looks cryptic.
I would like to be able to read the output and interpret it correctly.
Any guidelines you can offer will be much appreciated.
--
Roberto Zini
>
> John DuBois wrote:
> >
> > In article <3BC4BCE1...@att.net>, Steve Fabac <smf...@att.net> wrote:
> > >John the following is the output of the crash command you recommended
> > >above when applied to process ID 27678 first and then 27680. What do
> > >you make of the output?
> >
> > This shows that the cobol program is indeed trapping hangup, meaning that it
> > can respond to a logout notification in any way it chooses, which in this case
> > is apparently to just ignore it.
> >
> > John
>
> Thanks for the reply John. Will you take a moment to comment the crash
> output below to mark what shows that this program is trapping hangup?
>
> I am not a C programmer and the information presented looks cryptic.
> I would like to be able to read the output and interpret it correctly.
> Any guidelines you can offer will be much appreciated.
>
Hi !
Sorry for jumping in but I'd like to offer my 2 cents on this issue,
hoping that John won't mind (he's one of my favorite posters here, given
his knowledge and background on SCO's OS related problems).
> >
> > >
> > >output of killidle:
> > >
> > > team5 27680 27678 80 14:53:18 ttyp5 18:05:23 runcobol85 OEEPK -k -c/usr1/bin/configure -k
> > >
> > >> PER PROCESS USER AREA FOR PROCESS 103
> > >USER ID's: uid: 212, gid: 100, real uid: 212, real gid: 100
> > > supplementary gids: 100
[snip]
> > >SIGNAL DISPOSITION:
> > > sig# signal oldmask sigmask
> > > 1: 0x4310 -
> > > 2: 0x4310 -
> > > 3: 0x4310 -
> > > 6: 0x4344 -
> > > 13: ignore -
> > > 14: 0x4300 suspend
> > > 15: 0x4310 -
> > > 24: ignore -
> > > 26: ignore -
> > > 27: ignore -
I think the above is the key; as far as I can see, crash reports that
the above program is able to intercept some signals (namely, the
one reported below) and to act in a "programmed manner" when they
are received. As an example, signal #1 (SIGHUP) is being intercepted
by the routine whose "address" is 0x4310 (the signal handler); other
signals (6=IOT, 14=alarm clock) are handled by different routines
whose addresses are ox4344 and 0x4310.
The problem here is that only the developer of the application
knows what the routine is supposed to do; crash is not my cup of
tea so I don't know if it's possible to "disassemble" the code
at the above addresses and find out the logical scheme behind that
handler (not the easiest things in the world though :-) but I'm
wide open to corrections (John ?).
Just my 2 cents,
Roberto
--
---------------------------------------------------------------------
Roberto Zini email : r.z...@strhold.it
Technical Support Manager -- Strhold Evolution Division R.E. (ITALY)
---------------------------------------------------------------------
"Has anybody around here seen an aircraft carrier?"
(Pete "Maverick" Mitchell - Top Gun)