Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
ps vs who
- Thread starter qlark
- Start date
unclebrian
Vendor
I found that sometimes information gets stuck in the /etc/utmp file when a user logs out. 'who' references this file and can give this apparent discrepancy.
Try clearing the /etc/utmp file when you get a quiet moment with no-one on the system
Try clearing the /etc/utmp file when you get a quiet moment with no-one on the system
RodKnowlton
MIS
- Apr 26, 2000
- 1,005
- 0
- 0
It's also possible that the user exec'd something that changed uid, perhaps with sudo or the setuid bit set. This would (correctly) wait to add a logout record to utmp until after the exec'd process ended.
You can use ps with the -t option to find out what's running on the second connection, if anything. The -t argument will be the second field of the who output for the connection, like:
ps -tpts/25
or
ps -ttty5
(for a tty, you can also use just the number)
ps -t5
If there are any processes attached to the connection (other than getty on a tty) and there are no duplicate entries for the tty/pts in the "who" output, then the utmp report is valid and you might want to contact the user to find out what they're doing, to confirm.
Rod Knowlton
IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+
You can use ps with the -t option to find out what's running on the second connection, if anything. The -t argument will be the second field of the who output for the connection, like:
ps -tpts/25
or
ps -ttty5
(for a tty, you can also use just the number)
ps -t5
If there are any processes attached to the connection (other than getty on a tty) and there are no duplicate entries for the tty/pts in the "who" output, then the utmp report is valid and you might want to contact the user to find out what they're doing, to confirm.
Rod Knowlton
IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+
- Thread starter
- #4
Thanx Rod,
I did a ps -tpts/123 on a connection of mine that is over 20 hours old and it came back with nothing ... I typically have 4 sessions connected at any one time so I wrote a script to close all my sessions. Is it possible that the kill -9 -1 could be causing this ... when I run this script all my sessions are just sitting at a unix prompt so a ps -ef | grep username just returns that they are all runnung ksh (not including the ps -ef and grep username).
if [ $CurrentUser = $UserName ]
then
read rusure?'Are you sure you want to exit all? (y/n)'
if [ "$rusure" = "Y" ] || [ "$rusure" = "y" ]
then
echo Exit in progress from $CurrentUser
sleep 1
nohup kill -9 -1 > /dev/null
fi
else
echo - You cannot exit the system from $CurrentUser - fi
I did a ps -tpts/123 on a connection of mine that is over 20 hours old and it came back with nothing ... I typically have 4 sessions connected at any one time so I wrote a script to close all my sessions. Is it possible that the kill -9 -1 could be causing this ... when I run this script all my sessions are just sitting at a unix prompt so a ps -ef | grep username just returns that they are all runnung ksh (not including the ps -ef and grep username).
if [ $CurrentUser = $UserName ]
then
read rusure?'Are you sure you want to exit all? (y/n)'
if [ "$rusure" = "Y" ] || [ "$rusure" = "y" ]
then
echo Exit in progress from $CurrentUser
sleep 1
nohup kill -9 -1 > /dev/null
fi
else
echo - You cannot exit the system from $CurrentUser - fi
RodKnowlton
MIS
- Apr 26, 2000
- 1,005
- 0
- 0
...looking at man page for kill........
Wow! I'm a little suprised they used "kill -9 -1" as an example. SIGKILL (-9) is a very rude way to end a program and might be the cause of your stray entries.
If the sessions are all sitting at the ksh prompt, you could define TMOUT in your environment file so that they'll automatically log out after TMOUT seconds of inactivity (actually, after TMOUT seconds you'll get a message that 60 more seconds of inactivity will terminate the shell, so you have a grace period).
Otherwise, just live with the invalid entries, or clear utmp as suggested, or just type "exit" four times each day.
Better yet, install screen and have sessions you can hot-key between in a single window, and that you can detach from and leave running, only to reattach from a new login later.
We run jobs that can't handle a network interruption of their stdout inside screen sessions, which just interpret a network interruption as a "detach" command. The jobs never know anything happened, because the "terminal" they're run from is virtual and exists only in the machine's memory.
I always use it when connecting remotely via dial-up or VPN. It's a bandwidth and nerves saver.
I like screen a lot (like it wasn't obvious), as does everybody I've ever talked to that used it.
It's free, mature, and included in the AIX Toolbox for Linux Applications.
Rod Knowlton
IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+
Wow! I'm a little suprised they used "kill -9 -1" as an example. SIGKILL (-9) is a very rude way to end a program and might be the cause of your stray entries.
If the sessions are all sitting at the ksh prompt, you could define TMOUT in your environment file so that they'll automatically log out after TMOUT seconds of inactivity (actually, after TMOUT seconds you'll get a message that 60 more seconds of inactivity will terminate the shell, so you have a grace period).
Otherwise, just live with the invalid entries, or clear utmp as suggested, or just type "exit" four times each day.
Better yet, install screen and have sessions you can hot-key between in a single window, and that you can detach from and leave running, only to reattach from a new login later.
We run jobs that can't handle a network interruption of their stdout inside screen sessions, which just interpret a network interruption as a "detach" command. The jobs never know anything happened, because the "terminal" they're run from is virtual and exists only in the machine's memory.
I always use it when connecting remotely via dial-up or VPN. It's a bandwidth and nerves saver.
I like screen a lot (like it wasn't obvious), as does everybody I've ever talked to that used it.
It's free, mature, and included in the AIX Toolbox for Linux Applications.
Rod Knowlton
IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+
- Thread starter
- #6
The kill command has some history in that I am connected via a VPN which drops at random and I was having to do this manually way too often to recoop my work and shutdown anything running ... this script has been working unchanged without any issues for several years until the client recently moved AIX from an RS6000 to an AS400 (I believe IBM has them running a virtual RS6000 under the AS400 OS)
Sorry but I HATE timeouts ... murphy is always there watching and will get you doesn't matter what you set the timeout to.
I guess I have become lazy in my old age ... prior to using the kill -9 -1 I would have to capture the PPID's of all my processes then manually issue a kill -9 ppid.
I also have a wide screen laptop so I can see all my sessions at the same time ... far more productive IMHO when developing (sort of like having a GUI IDE) ... Screen kind of defeats the purpose by having 3 sessions hidden ... my terminal software can do this as well but as stated I like the ability of having all 4 sessions visible. All activity that I run on this machine is independant of anyone else so it wouldn't really matter if the processes are killed.
Question; are you implying that you can reconnect to a Screen Session should you loose your VPN connection or is it just that the OS won't terminate the processes running in this virtual screen? (Much like a nohup where the process runs to completion) If one can reconnect to a virtual screen I think that I would recommend its usage for critical updates like schema changes and or releases.
I can certainly reserve my kll script to recover VPN crashes and go back to using "exit" on the 4 sessions to see if this makes the Lost session issue go away.
Sorry but I HATE timeouts ... murphy is always there watching and will get you doesn't matter what you set the timeout to.
I guess I have become lazy in my old age ... prior to using the kill -9 -1 I would have to capture the PPID's of all my processes then manually issue a kill -9 ppid.
I also have a wide screen laptop so I can see all my sessions at the same time ... far more productive IMHO when developing (sort of like having a GUI IDE) ... Screen kind of defeats the purpose by having 3 sessions hidden ... my terminal software can do this as well but as stated I like the ability of having all 4 sessions visible. All activity that I run on this machine is independant of anyone else so it wouldn't really matter if the processes are killed.
Question; are you implying that you can reconnect to a Screen Session should you loose your VPN connection or is it just that the OS won't terminate the processes running in this virtual screen? (Much like a nohup where the process runs to completion) If one can reconnect to a virtual screen I think that I would recommend its usage for critical updates like schema changes and or releases.
I can certainly reserve my kll script to recover VPN crashes and go back to using "exit" on the 4 sessions to see if this makes the Lost session issue go away.
RodKnowlton
MIS
- Apr 26, 2000
- 1,005
- 0
- 0
That's exactly what I'm saying.
You can also run more than one instance of screen.
I'd suggest with your VPN situation that you run a separate screen instance for each window. You can name them at instantiation (ie mysession1, mysession2...) and then use the the session names to reattach to them after a VPN drop. Check out this from the man page:
Code:
`-d -R'
Reattach a session and if necessary detach or even create
it first.This means you can create four aliases, one for each of your sessions, that essentially mean "I want session x. I don't care if my VPN has dropped, or I left them running in the office, or even if it doesn't exist. Just work it out and give me it to work in.".
Give it a spin, it don't cost nothin'.
BTW, it's been my experience that once you've used a widescreen, there's no going back. On the rare occasions when I pick up one of our Thinkpad T23s (1024x768) instead of my Powerbook 17" (1680x1050), it feels like a kid's computer. Everything on the screen is so big, and the keys are so small. And I've only had the PB since the first week in December.
Rod Knowlton
IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+
- Thread starter
- #8
RodKnowlton
MIS
- Apr 26, 2000
- 1,005
- 0
- 0
In a nutshell, screen creates virtual terminals, within which programs can be run and behave as if they are attached to a physical terminal.
screen is also a program for monitoring these virtual terminals, viewing their output on a physical terminal, and watching the physical terminal for commands to intercept.
When you launch screen, you're launching the viewing program. Depending on command line options, it can either (re)attach to existing virtual terminals, or launch a copy of itself as a daemon and then request and attach to new virtual terminals from the daemon copy.
It is this "viewing program" type of screen instance that you are interacting with over your VPN session.
When a "viewing program" instance of screen ends, whether by the internal detach command (^A-d by default), or by dying because the telnet session it was using for output went south when the VPN dropped, the virtual terminals being managed by a "daemon" instance couldn't care less. As far as they are concerned, nothing happened.
The big payoff for this is that you can start a new "viewing program" instance and tell it to reconnect to the session (one "daemon" process's virtual terminals) you were working with.
This is probably as clear as mud now, but you can look at the actual manual at the screen homepage for (much) more information. I don't recall if there's a direct link to the manual, but both PostScript and info versions can be generated from the source.
- Rod
IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+
Wish you could view posts with a fixed font? Got Firefox & Greasemonkey? Give yourself the option.
screen is also a program for monitoring these virtual terminals, viewing their output on a physical terminal, and watching the physical terminal for commands to intercept.
When you launch screen, you're launching the viewing program. Depending on command line options, it can either (re)attach to existing virtual terminals, or launch a copy of itself as a daemon and then request and attach to new virtual terminals from the daemon copy.
It is this "viewing program" type of screen instance that you are interacting with over your VPN session.
When a "viewing program" instance of screen ends, whether by the internal detach command (^A-d by default), or by dying because the telnet session it was using for output went south when the VPN dropped, the virtual terminals being managed by a "daemon" instance couldn't care less. As far as they are concerned, nothing happened.
The big payoff for this is that you can start a new "viewing program" instance and tell it to reconnect to the session (one "daemon" process's virtual terminals) you were working with.
This is probably as clear as mud now, but you can look at the actual manual at the screen homepage for (much) more information. I don't recall if there's a direct link to the manual, but both PostScript and info versions can be generated from the source.
- Rod
IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+
Wish you could view posts with a fixed font? Got Firefox & Greasemonkey? Give yourself the option.
- Thread starter
- #11
Update; on original issue of who not matching ps
After several days of using exit instead of kill -9 -1
there is no difference in that there are still connections showing under "who" when there are no processes under "ps" for that user ... I am thinking IBM may have some minor issues with their RS6000 emulation under AS400 as this was not an issue when running on a real RS6000
Still haven't tried screen yet ... I downloaded it and provided it to the Administrator but understand he has been busy with higher priorities and hasn't had a chance to compile/install it.
After several days of using exit instead of kill -9 -1
there is no difference in that there are still connections showing under "who" when there are no processes under "ps" for that user ... I am thinking IBM may have some minor issues with their RS6000 emulation under AS400 as this was not an issue when running on a real RS6000
Still haven't tried screen yet
... I downloaded it and provided it to the Administrator but understand he has been busy with higher priorities and hasn't had a chance to compile/install it.- Status
