The macosxhints Forums - Terminal: PS results different from Activity Monitor?

The macosxhints Forums (http://hintsforums.macworld.com/index.php)

- UNIX - General (http://hintsforums.macworld.com/forumdisplay.php?f=16)

- - Terminal: PS results different from Activity Monitor? (http://hintsforums.macworld.com/showthread.php?t=91484)

cwtnospam

07-04-2008 03:50 PM

Terminal: PS results different from Activity Monitor?

Right now, if I look in Activity monitor, my Finder process ID is 97, and its parent ID is 79.

If I look in the Terminal using:

ps -w -U myshortname
I see that the Finder's PID is 97. So far, so good.

Next, I use:
ps -j -p 97
and I see that PID 97 is the Finder, but it has a PPID of 73! How can that be?

baf	07-04-2008 04:59 PM

How do you check in activity monitor? OsX Version?

cwtnospam

07-04-2008 05:03 PM

Using the inspect button. I'm using 10.4.11

Edit: I'm trying to find a way of knowing (in a script) what user is the active user. The script may be running under a user that is logged in but not active.

baf	07-04-2008 05:09 PM

What does it say that the name of the parent process is?
Inspect on my Finder gives:
loginwindow(20691) and ps agrees.
10.4.11 here also .

cwtnospam

07-04-2008 05:14 PM

Yes, it does show loginwindow, but ps thinks it belongs to ApplicationServices. I'm logged in as a nonadmin, and I've got an admin user logged in in the background. It's almost as if ps is getting them confused.

cwtnospam

07-04-2008 05:23 PM

Just rebooted:
ps -w -U myshortname
shows Finder has PID of 97
ps -j -p 97
shows PPID of Finder to be 72
ps -j -p 72
shows process to be ApplicationServices and not loginwindow, which Activity Monitor does (PID: 79)

Mikey-San

07-04-2008 05:39 PM

Quote:

Originally Posted by cwtnospam (Post 480345)

Edit: I'm trying to find a way of knowing (in a script) what user is the active user. The script may be running under a user that is logged in but not active.

Why does the script need to know? Perhaps there's a better/different solution.

cwtnospam

07-04-2008 05:43 PM

It started out as an exercise for me. Somebody else said they needed it. Now I want to figure out what's wrong with ps as well as know how to tell if a script is running under a user who's in the background.

baf	07-04-2008 06:37 PM

First I believe in ps not activity monitor. Your first finding that Finder was it's own child is definitely a bug.
try this line in terminal and you will see all the relevant process at one time.
ps -awwxj|egrep -i "(Fin[d]er|loginw[i]ndow|window[s]erver|P[P]ID)"| cut -c1-21 -c60-

Second I can't find any way with ps only to see who is "active". But some combination of looking in /var/log/secure.log and then checking if the last authenticated still has a running loginwindow process should tell you who is "active"
this shows the interesting ones of the last 20 lines.
cat /var/log/secure.log|tail -20 |grep "com.apple.SecurityServer: authinternal authenticated user"
This must be done with some care as the logfiles is rotated weekly?

cwtnospam

07-04-2008 06:47 PM

I would believe ps, but I noticed in Activity Monitor that the parent process of the Finder for the active user is loginwindow and the parent process for the background user is WindowServer. This seems consistent, at least on the two users I have tried on my system.

cwtnospam

07-04-2008 06:50 PM

Quote:

cat /var/log/secure.log|tail -20 |grep "com.apple.SecurityServer: authinternal authenticated user"

I tried looking in logs, but I didn't see much that would help, and I'd have to run the script with elevated privileges, so I'd prefer to find a more secure method anyway.

cwtnospam

07-04-2008 07:05 PM

Quote:

Originally Posted by baf (Post 480366)

Same results from both users:

Code:

windowse    72     1  /System/Library/Frameworks/ApplicationServices.framework/Frameworks/CoreGraphics.framework/Resources/WindowServer -daemon

userone    79     1  /System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow console

userone    97    72  /System/Library/CoreServices/Finder.app/Contents/MacOS/Finder -psn_0_655361

usertwo    816    72  /System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow

usertwo    831    72  /System/Library/CoreServices/Finder.app/Contents/MacOS/Finder -psn_0_5505025







windowse    72     1  /System/Library/Frameworks/ApplicationServices.framework/Frameworks/CoreGraphics.framework/Resources/WindowServer -daemon

userone    79     1  /System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow console

userone    97    72  /System/Library/CoreServices/Finder.app/Contents/MacOS/Finder -psn_0_655361

usertwo    816    72  /System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow

usertwo    831    72  /System/Library/CoreServices/Finder.app/Contents/MacOS/Finder -psn_0_5505025

That's why I think ps is missing something. It seems like Activity Monitor correctly tells the difference between the two, since it correctly identifies the Finder of the active user.

baf	07-04-2008 07:22 PM

No I think activity monitor tries to be "helpful" and shows with it believes that you want to see. Yes in your case that is what you want to know but it isn't the parent you see.

One reason I say this is that act. mon. data suggests that the system could "reparent" the process after a switch and I have never heard of a UNIX that does that.

cwtnospam

07-04-2008 07:37 PM

Quote:

Originally Posted by baf (Post 480378)

No I think activity monitor tries to be "helpful" and shows with it believes that you want to see. Yes in your case that is what you want to know but it isn't the parent you see.

Do you see similar results on your system?

baf	07-04-2008 07:43 PM

Yep exactly the same (10.4.11 here too). ps is consistent whichever user I am. Activity monitor changes its data depending on who I am (hmm do I feel a smell of multiple personality disorder here? ).

baf	07-05-2008 05:45 AM

Test this script:

Code:

#!/bin/bash



{

    while read lll ; do

        if [[ $lll == *IOConsoleUsers* ]]; then

            OIFS=$IFS

            IFS="{}"

            arr=($lll)

            break;

        fi

    done

    cat >/dev/null

}< <( ioreg -w0 -Sn Root )



#check here if anything found otherwise ?



for a in ${arr[@]}; do

    if [[ $a == *kCGSSessionOnConsoleKey\"=Yes* ]]; then

        IFS=,

        arr2=($a)

        break

    fi

done



#check here if anything found otherwise ?



for a in ${arr2[@]}; do

   case $a in

       ( \"kCGSSessionUserNameKey* | \"kCGSessionLongUserNameKey* | \"kCGSSessionUserIDKey* )

       echo $a;;

   esac

done

Error handling still needed.

cwtnospam

07-05-2008 09:29 AM

That works. Thanks!

Why the loops? It seems like you should be able to use grep or awk to search the results of ioreg -w0 -Sn Root for the appropriate keys. I tried without success though, so I assume there's more going on than I'm aware of.

biovizier

07-05-2008 09:32 AM

For me, checking the owner of '/dev/console' has been fairly reliable (at least in 10.4 and 10.5) in finding the current active user (root if at the login window), eg.

Code:

stat -f "%Su" /dev/console

cwtnospam

07-05-2008 10:01 AM

Wow! That is far too easy, but then I guess when you see the answer it's always easy. ;)

baf	07-05-2008 10:39 AM

Quote:

Originally Posted by cwtnospam (Post 480455)

Why the loops? It seems like you should be able to use grep or awk to search the results of ioreg -w0 -Sn Root for the appropriate keys. I tried without success though, so I assume there's more going on than I'm aware of.

Reason: All the interesting stuff is on one line so it's hard to use awk or grep and I'm not sure if they always come in the same order.

baf	07-05-2008 10:40 AM

Quote:

Originally Posted by biovizier (Post 480456)

For me, checking the owner of '/dev/console' has been fairly reliable (at least in 10.4 and 10.5) in finding the current active user (root if at the login window), eg.

Code:

stat -f "%Su" /dev/console

That's so easy that it borders on cheating. :D

cwtnospam

07-05-2008 10:57 AM

Quote:

Originally Posted by baf (Post 480467)

Reason: All the interesting stuff is on one line so it's hard to use awk or grep and I'm not sure if they always come in the same order.

Well, this seems to work. ;)

Code:

ioreg -w0 -Sn Root | grep 'kCGSSessionOnConsoleKey"=Yes' | perl -pe 's/kCGSSessionOnConsoleKey"=Yes/\nkCGSSessionOnConsoleKey"=Yes/g' | grep 'kCGSSessionOnConsoleKey"=Yes' | perl -pe 's/kCGSessionLongUserNameKey"="/\n/g' | tail -n 1 | perl -pe 's/"/\n/g' | head -n 1

I'm sure it could be made shorter, but it'll never get as short as biovizier's solution.

baf	07-05-2008 11:06 AM

Yes but I'm always careful when data comes on a long line because sometimes order is not guaranteed. With my script order doesn't matter at all.

cwtnospam

07-05-2008 11:11 AM

Quote:

Originally Posted by baf (Post 480479)

With my script order doesn't matter at all.

Neither does mine, I think. ;) I tried to keep it all on one line and then eliminate extraneous data to pluck the user name from that line.

baf	07-05-2008 11:27 AM

Example of what I mean:
assume that sometimes kCGSessionLongUserNameKey=... comes before kCGSSessionOnConsoleKey=... your script would then fail.

I'm not saying it does but as I can only check on one machine and with it's installed os I can't be sure. Is it perhaps sorted in username order or what? I just prefer to do a real parse if possible unless I have "proof" e.g. a man page that states the order.

baf	07-05-2008 11:44 AM

And if we're talking perl then use it the whole way.

Code:

ioreg -w0 -Sn Root |perl -ne '/.*{(.*?kCGSSessionOnConsoleKey"=Yes.*?)}.*/ && $1=~/"kCGSessionLongUserNameKey"="(.*?)"/ && print $1'

This (I think) should be order safe, doesn't depend on any commands except ioreg and raw perl. It seems to be the fastest one (except bio:s ) checked with time ....

hayne

07-05-2008 11:54 AM

An alternative is to use the 'scutil' command, asking it to show the data for the key "State:/Users/ConsoleUser".

Here's a Perl script that does this (it shows the short username):

Code:

#!/usr/bin/perl



# getConsoleUsername:

# This script echos the name of the currently active user

# (this is useful when using Fast User Switching)

#

# This script also serves as an illustration of using the 'scutil' command.

# Cameron Hayne (macdev@hayne.net)  July 2008



use strict;

use warnings;



my $scutil = "/usr/sbin/scutil";

my $consoleUserKey = "State:/Users/ConsoleUser";

my $results = `echo "show $consoleUserKey" | $scutil`;

#print $results;

my ($uid) = $results =~ m/^\s*UID\s*:\s*(\d+)\s*$/m;

my ($username) = $results =~ m/^\s*Name\s*:\s*(\S+)\s*$/m;

#print "$uid\n";

print "$username\n";

cwtnospam

07-05-2008 11:56 AM

Quote:

Originally Posted by baf (Post 480482)

Example of what I mean:
assume that sometimes kCGSessionLongUserNameKey=... comes before kCGSSessionOnConsoleKey=... your script would then fail.

I see.

Quote:

Originally Posted by baf (Post 480486)

And if we're talking perl then use it the whole way.

Code:

ioreg -w0 -Sn Root |perl -ne '/.*{(.*?kCGSSessionOnConsoleKey"=Yes.*?)}.*/ && $1=~/"kCGSessionLongUserNameKey"="(.*?)"/ && print $1'

This (I think) should be order safe, doesn't depend on any commands except ioreg and raw perl. It seems to be the fastest one (except bio:s ) checked with time ....

I've got to get better with perl. I only started using it when I had a problem with sed and escaped characters like \n and \t.

hayne

07-05-2008 12:11 PM

Quote:

Originally Posted by baf (Post 480486)

It seems to be the fastest one (except bio:s ) checked with time ....

Code:

% time ioreg -w0 -Sn Root |perl -ne '/.*{(.*?kCGSSessionOnConsoleKey"=Yes.*?)}.*/ && $1=~/"kCGSessionLongUserNameKey"="(.*?)"/ && print $1'

Fred Smith

real        0m0.048s

user        0m0.013s

sys        0m0.039s



% time ./getConsoleUsername 

fred



real        0m0.021s

user        0m0.010s

sys        0m0.010s



% time stat -f "%Su" /dev/console

fred



real        0m0.004s

user        0m0.001s

sys        0m0.002s

One problem with biovizier's solution is that the permissions on /dev/console would seem to prevent a script running under some other user account from doing 'stat' on it. Hence a 'sudo' would be needed.

baf	07-05-2008 01:12 PM

Nice one hayne. Do you have any good place to read up on scutil? The man page is rather short.

And on which os doesn't stat work? On tiger it's ok for me at least.

hayne

07-05-2008 04:54 PM

Quote:

Originally Posted by baf (Post 480505)

And on which os doesn't stat work? On tiger it's ok for me at least.

I don't know that it doesn't work - I just looked at the permissions and saw that they are:
crw-------
so only the owner has read permission. And so I thought that 'stat' would fail for anyone other than owner. But I realize now that the relevant permissions are those of the enclosing folder - so all is well.

I don't have any better reference on 'scutil' - I agree that the man page is inadequate.
Best to just run it interactively and try things: especially 'list' and 'help'

baf	07-05-2008 04:56 PM

:D Ahh even you can be mistaken.;)

All times are GMT -5. The time now is 05:46 PM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.
Site design © IDG Consumer & SMB; individuals retain copyright of their postings
but consent to the possible use of their material in other areas of IDG Consumer & SMB.