python at login on macintels
D P Schreber
listed as "(python)". These processes are not cleaned up at logout: if
I login 10 times, 10 of them are setting around. It's not a concern,
given that they're not doing anything or using any resources (other than
a process slot). I'm just curious what python is being used for at
login. For those who don't know, python is a sophisticated scripting
language, or, if you prefer, a sophisticated interpreted programming
language.
My account is configured to run only the two default Login Items,
iTunesHelper and iCalAlarmScheduler, same as on my other two Macs.
Since those Macs are PowerPC and don't have these python processes, I'm
assuming that, whatever their purpose is, it's macintel-specific, and
probably has nothing to do with any user-specific Login Items.
So what's running these python scripts at login, and to what end?
Dave Seaman
I just tried a "ps aux | grep python" on my MacBook Pro and found no
processes. Whatever it is, it's specific to your Mac.
--
Dave Seaman
U.S. Court of Appeals to review three issues
concerning case of Mumia Abu-Jamal.
<http://www.mumia2000.org/>
D P Schreber
> I just tried a "ps aux | grep python" on my MacBook Pro and found no
> processes. Whatever it is, it's specific to your Mac.
Possible but not likely. But I did get the description slightly wrong.
The _first_ time I login, I don't have any python processes. The second
time I have one, the third time I have two, etc etc. Here's a snapshot
after the third login, from "ps x -ocommand" and edited to keep the
lines from getting excessively wide. Note that there's nothing running
other than standard Apple login apps + Terminal.
/System/Library/Frameworks/ApplicationServices.framework/Frameworks/ATS.framework/Support/ATSServer
(python)
/System/Library/Frameworks/CoreServices.framework/Frameworks/Metadata.framework/Versions/A/Support/mdimportserver
(python)
/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow
/System/Library/PrivateFrameworks/DedicatedNetworkBuilds.framework/Resources/sctwistd
/System/Library/CoreServices/pbs
/System/Library/CoreServices/Dock.app/Contents/MacOS/Dock -psn_0_393217
/System/Library/CoreServices/SystemUIServer.app/Contents/MacOS/SystemUIServer
/System/Library/CoreServices/Finder.app/Contents/MacOS/Finder
/Applications/iCal.app/Contents/Resources/iCalAlarmScheduler.app/Contents/MacOS/iCalAlarmScheduler
/Applications/iTunes.app/Contents/Resources/iTunesHelper.app/Contents/MacOS/iTunesHelper
/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal
-tcsh
Tom Stiller
D P Schreber <schre...@rayban.net> wrote:
> On 2006-05-31, Dave Seaman <dse...@no.such.host> wrote:
> > I just tried a "ps aux | grep python" on my MacBook Pro and found no
> > processes. Whatever it is, it's specific to your Mac.
>
> Possible but not likely. But I did get the description slightly wrong.
> The _first_ time I login, I don't have any python processes. The second
> time I have one, the third time I have two, etc etc. Here's a snapshot
> after the third login, from "ps x -ocommand" and edited to keep the
> lines from getting excessively wide. Note that there's nothing running
> other than standard Apple login apps + Terminal.
>
> /System/Library/Frameworks/ApplicationServices.framework/Frameworks/ATS.framew
> ork/Support/ATSServer
> (python)
[snip]
I have them too. They are "zombies", processes that have completed but
whose status has not been retrieved by the task that spawned them. My
guess is that the task was spawned as part of login, but I'll have to
explore further.
In any event, the zombies cause no harm other than occupying a few slots
in the process table.
--
Tom Stiller
PGP fingerprint = 5108 DDB2 9761 EDE5 E7E3
7BDA 71ED 6496 99C0 C7CF
D P Schreber
> In any event, the zombies cause no harm other than occupying a few slots
> in the process table.
Right, as I said in my initial post. I was just wondering where they
came from, which is to say, which Apple process is leaving these things
around. If you can figure it out, please post.
Barry Margolin
D P Schreber <schre...@rayban.net> wrote:
Do you use JunkMatcher? It's written in Python.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
D P Schreber
>> Right, as I said in my initial post. I was just wondering where they
>> came from, which is to say, which Apple process is leaving these things
>> around. If you can figure it out, please post.
>
> Do you use JunkMatcher? It's written in Python.
Nope, never even heard of it. I did a test case in which I was running
_nothing_ other than (a) the standard osx processes that always run at
login, (b) the two default Login Items, and (c) Terminal, which I used
only to run ps. I still get one python zombie per login.
Bob Harris
D P Schreber <schre...@rayban.net> wrote:
Run this script in an Applications -> Utilities -> Terminal session
#!/bin/sh
while true
do
if ps -axlww|grep -v "axlww|grep" | grep python; then
ps -axlww|grep -v "axlww|grep" | grep python
date
fi
sleep 60
done
*******
chmod +x name_of_file_you_put_script_into
./name_of_file_you_put_script_into
What this script will do is look for any process that has the word
python in the command line, and display the process followed by
the date.
It will check every minute.
This will help isolate when the process first appears, just in
case it is part of something that runs while you are logged in.
Bob Harris
David Empson
> On 2006-05-31, Dave Seaman <dse...@no.such.host> wrote:
> > I just tried a "ps aux | grep python" on my MacBook Pro and found no
> > processes. Whatever it is, it's specific to your Mac.
>
> Possible but not likely. But I did get the description slightly wrong.
> The _first_ time I login, I don't have any python processes. The second
> time I have one, the third time I have two, etc etc.
A point worth considering: if you have (n-1) of these processes, where n
is the number of times you have logged in, perhaps they are being
created on logout rather than login.
--
David Empson
dem...@actrix.gen.nz
D P Schreber
>> The _first_ time I login, I don't have any python processes. The second
>> time I have one, the third time I have two, etc etc.
>
> A point worth considering: if you have (n-1) of these processes, where n
> is the number of times you have logged in, perhaps they are being
> created on logout rather than login.
Seems very plausible that some part of the cleanup that happens at
logout is leaving these around. I don't know the detailed sequence of
events that occur during logout (from the Aqua console).
Tom Stiller
dem...@actrix.gen.nz (David Empson) wrote:
As nearly as I can determine, the zombie is a result of the execution of
the python process "sctwistd" located in directory
"/System/Library/PrivateFrameworks/DedicatedNetworkBuilds.framework/Versi
ons/A/Resources".
On my machine (OS X 10.4.6), this process runs early in the login
sequence and is active for the entire login sequence. I don't know what
process initiates "sctwistd", but apparently, it doesn't check on its
termination before terminating itself.
Alan Baker
Tom Stiller <tomst...@comcast.net> wrote:
<URL:http://developer.apple.com/releasenotes/DeveloperTools/Xcode/Xcode.h
tml>
"Dedicated Network Builds
€ Features
€ Dedicated Network Builds is a new feature in Xcode 2.3 targeted at
developers of large projects with dedicated build farms for compilation.
The existing distributed builds mechanism (distcc) does not scale past 6
to 12 builders, depending on network speed and host architecture.
Dedicated Network Builds is designed to scale well beyond a dozen
builders and has been tested with up to 32 builders. Dedicated Network
Builds uses an advanced caching mechanism such that bandwidth between
the build client (recruiter) and builders (volunteers) is minimized.
€ Dedicated Network Builds is not a replacement for distcc builds,
which is best used for small- to mid- size projects, and ad-hoc,
auto-discovered builders. Volunteer machines participating as Dedicated
Network Build builders are not auto-discovered. Instead, each machine
must be added to the preferences pane in Xcode. This workflow will be
improved in a future release.
€ Processes on the builder are run chrooted to a mount point whose
underlying filesystem mirrors the filesystem on the build recruiter (the
machine running the Xcode build). As such, whatever version of the
compiler and headers installed on the build recruiter will always be
used for the compilation process on the volunteers. As a result of this,
the compiler and system version number in the preferences pane will be
shown as the same for all volunteers.
€ Dedicated Network Builds also uses more volunteer machine
resources, so dual-use build volunteers/developer workstations are not
recommended."
So it looks like this is a part of Xcode...
Tom Stiller
Alan Baker <alang...@telus.net> wrote:
And the process is started by the LaunchDaemon "com.apple.dnbvolunteer".
John C. Randolph
Are you using Xcode, and have you volunteered your machine for network builds?
That's the one thing I know of that Apple's using the Twisted libraries for.
-jcr
Tom Stiller
I do use XCode and I didn't volunteer the machine for network builds.
I was going to disable "dnbvolunteer", but it already is disabled.
Either the disable flag doesn't work or there's another place where
"sctwistd" gets activated.
D P Schreber
>> network builds? That's the one thing I know of that Apple's using
>> the Twisted libraries for.
>
> I do use XCode and I didn't volunteer the machine for network builds.
OP here. I don't use Xcode per se -- I've never launched it on my MBP
-- but I do have it installed and I routinely use the bsd and java
command-line build tools (gcc, javac, ant, make, etc). I never
intentionally configured the machine to accept network build requests.
Fwiw the MBP has XCode 2.3 installed, the update that came out just a
couple of weeks ago. My G5 desktop also has this installed and it does
_not_ generate a python zombie per login. On the G5, where I'm running
now, the dnbobserver daemon is enabled and the dnbvolunteer is disabled.
The sctwistd is running and was started as part of my current login.
I'll try disabling the observer and see if that stops sctwistd from
starting on my next login.
D P Schreber
> On the G5, where I'm running now, the dnbobserver daemon is enabled
> and the dnbvolunteer is disabled. The sctwistd is running and was
> started as part of my current login. I'll try disabling the observer
> and see if that stops sctwistd from starting on my next login.
That seems to have done it on the G5, after a reboot: disabling both the
observer and the volunteer prevents the sctwistd from starting at login.
I'll try the same procedure later today on the MBP and verify that the
python zombies no longer appear.
Thanks for everyone's excellent detective work.
Tom Harrington
Wait, what did you actually _do_ here? I get the same python processes,
but I don't think I understand how you made them go away.
--
Tom "Tom" Harrington
Macaroni, Automated System Maintenance for Mac OS X.
Version 2.0: Delocalize, Repair Permissions, lots more.
See http://www.atomicbird.com/
Tom Stiller
Tom Harrington <t...@pcisys.no.spam.dammit.net> wrote:
> In article <MKadnXevANC...@comcast.com>,
> D P Schreber <schre...@rayban.net> wrote:
>
> > On 2006-06-03, D P Schreber <schre...@rayban.net> wrote:
> > > On the G5, where I'm running now, the dnbobserver daemon is enabled
> > > and the dnbvolunteer is disabled. The sctwistd is running and was
> > > started as part of my current login. I'll try disabling the observer
> > > and see if that stops sctwistd from starting on my next login.
> >
> > That seems to have done it on the G5, after a reboot: disabling both the
> > observer and the volunteer prevents the sctwistd from starting at login.
> > I'll try the same procedure later today on the MBP and verify that the
> > python zombies no longer appear.
> >
> > Thanks for everyone's excellent detective work.
>
> Wait, what did you actually _do_ here? I get the same python processes,
> but I don't think I understand how you made them go away.
You have to disable both dnbobserverd and dnbvolunteer and restart. The
zombies result when the task that spawns the python process terminates
without reaping it's dead children.
D P Schreber
>> but I don't think I understand how you made them go away.
>
> You have to disable both dnbobserverd and dnbvolunteer and restart.
More specifically:
cd /System/Library/LaunchDaemons
sudo launchctl unload -w com.apple.dnbobserver.plist
You don't have to do anything about dnbvolunteer, since it's disabled by
default.
You don't necessarily have to restart but it can't hurt...
Bob Harris
<tomstiller-CE1CB...@comcast.dca.giganews.com>,
Tom Stiller <tomst...@comcast.net> wrote:
Zombies: Your answer is close, but off by just a tiny bit.
A Zombie is a process that has terminated and is waiting for its
_STILL_ _ALIVE_ parent to reap the completion status.
If the parent process goes away and abandons the child before or
after the child process terminates the child process is inherited
by the 'init' process (process PID 1), and the 'init' process will
reap the status of the zombie process.
So this means that the parent process actually still exists, or it
would not be a zombie.
You can find the parent process using the ps command
ps -o ppid,command -p [pid-of-the-zombie-process]
Then repeat using the PPID
ps -o command -p [PPID-from-previous-ps]
Bob Harris
Tom Stiller
Bob Harris <nospam....@remove.Smith-Harris.us> wrote:
> Zombies: Your answer is close, but off by just a tiny bit.
>
> A Zombie is a process that has terminated and is waiting for its
> _STILL_ _ALIVE_ parent to reap the completion status.
>
> If the parent process goes away and abandons the child before or
> after the child process terminates the child process is inherited
> by the 'init' process (process PID 1), and the 'init' process will
> reap the status of the zombie process.
So the zombie hangs around until shutdown.
>
> So this means that the parent process actually still exists, or it
> would not be a zombie.
>
> You can find the parent process using the ps command
>
> ps -o ppid,command -p [pid-of-the-zombie-process]
>
> Then repeat using the PPID
>
> ps -o command -p [PPID-from-previous-ps]
Interesting, but I'm not sure the explanation fits the case here.
Before logout there was a process, sctwistd, running with, say, pid 123.
After logout and re-login pid 123 is a python zombie.
Bob Harris
<tomstiller-A1413...@comcast.dca.giganews.com>,
Tom Stiller <tomst...@comcast.net> wrote:
> In article <nospam.News.Bob-E7...@news.verizon.net>,
> Bob Harris <nospam....@remove.Smith-Harris.us> wrote:
>
> > Zombies: Your answer is close, but off by just a tiny bit.
> >
> > A Zombie is a process that has terminated and is waiting for its
> > _STILL_ _ALIVE_ parent to reap the completion status.
> >
> > If the parent process goes away and abandons the child before or
> > after the child process terminates the child process is inherited
> > by the 'init' process (process PID 1), and the 'init' process will
> > reap the status of the zombie process.
>
> So the zombie hangs around until shutdown.
Zombie hang around until its parent process either issues a system
call from the wait() family, or the parent process terminates
which allows the zombie to be inherited by 'init', and init will
issue a wait to collect the completion status.
If the parent does not issue the wait, and the parent runs until
shutdown, then yes, the zombie will stay around until shutdown.
It still goes away the same way. During shutdown the parent will
be killed, the zombie is inherited by 'init', and its completion
status reaped.
> >
> > So this means that the parent process actually still exists, or it
> > would not be a zombie.
> >
> > You can find the parent process using the ps command
> >
> > ps -o ppid,command -p [pid-of-the-zombie-process]
> >
> > Then repeat using the PPID
> >
> > ps -o command -p [PPID-from-previous-ps]
>
> Interesting, but I'm not sure the explanation fits the case here.
> Before logout there was a process, sctwistd, running with, say, pid 123.
> After logout and re-login pid 123 is a python zombie.
Based on what you say, then sctwistd was killed as part of logout,
but its parent process was not, and the parent process did not
issue a wait to reap the completion status.
ps -o ppid,command -p 123
PPID COMMAND
nnnn (python)
ps -p [nnnn]
What is this parent process? That is the offender.
This is how zombies have worked since I first started using UNIX
back in 1985. This is how zombies worked when I was a Digital
Tru64 UNIX kernel developer. And as far as I know, this is how
zombies work on MacOSX and Linux. The zombie waits for its
parent, and if it parent dies, it is automatically adapted by
'init' which gives it the needed care and attention.
Bob Harris
Tom Stiller
Bob Harris <nospam....@remove.Smith-Harris.us> wrote:
You are correct, but then, you knew that ;-) Here's what happens:
tms@imac% ps ax | grep sctwistd
4857 ?? Ss 0:04.29
/System/Library/PrivateFrameworks/DedicatedNetworkBuilds.framework/
Resources/sctwistd
Logout/Login
tms@imac% ps ax | grep python
4857 ?? Z 0:00.00 (python)
5061 p1 R+ 0:00.00 grep python
tms@imac% ps -o ppid,command -p 4857
PPID COMMAND
4833 (python)
tms@imac% ps -o ppid,command -p 4833
PPID COMMAND
1
/System/Library/PrivateFrameworks/DedicatedNetworkBuilds.framework/Resour
ces/bfobserver
Unloading bfobserver cleans up all the mess.
Thanks for explaining the mechanism.