hmm, I'll take a look, it seems your computer never time syncs with our server:

http://qcn.stanford.edu/qcnalpha/result.php?resultid=293819

but still it shouldn't leave these zombie procs around, I'll have to check the cleanup on my thread. it is really just an "ntpdate" exec so shouldn't conflict with your own ntpd but something is obviously wrong.

thanks Fred (Rudy Toody) - I think as you noted my cmd line is being truncated so I will look into a fix for that. I just run ntpdate to get a "local" offset from our servers, so it isn't trying to really update your clock etc (just gives me a number offset I can report to adjust event times etc).

can you try ntpdate with all the options I use, either the one I distribute via BOINC or your "local" ntpdate, i.e.

/var/lib/boinc-client/projects/qcn.stanford.edu_qcnalpha/ntpdate_4.2.4p5_i686-pc-linux-gnu -p 8 -t 20 -u -b -q qcn-upl.stanford.edu

or

ntpdate -p 8 -t 20 -u -b -q qcn-upl.stanford.edu


because this way supposedly shouldn't conflict with current running ntpd's (the -q flag) -- it's just an informative msg that returns with a time offset between your machine & our server

so what "Rudy Toody" discovered is it seems my command line above is getting truncated which would cause a conflict so my ntpdate process dies and "zombies"

great, that means somehow my linux command-line is getting truncated as Rudy Toody thought. because the -q option shouldn't conflict with anybody's ntpd (if running) etc; I just "grep" the offset to get a better estimate of the time.

I'll try and get a new build up today or tomorrow (probably should have done before declaring qcn "non-alpha"!)

Edit: OK, it was a dumb error I had in the path name for Linux, so I made a new version and put it up. you can wait until you get a new workunit or "abort" your current one to get it. seems to sync OK on my VMWare test:

http://qcn.stanford.edu/qcnalpha/trigger.php?hostid=6108

well it seems to be doing the time sync but leaving zombies; I think it's because of the customized popen pipe stuff I'm doing which isn't cleaning up after itself nicely, so I'll try a waitpid() and see if that fixes it.

mine has been getting sync times on a few Linux PCs (but still leaving zombies behind):

5172469 qcne_sc300_sta200_015414_0 23 Apr 2009 4:21:43 UTC 23 Apr 2009 4:21:46 UTC 23 Apr 2009 4:17:23 UTC -0.000476 3.528071 0.296161 37.887708 -122.277847 0.02 2 JoyWarrior 24F8 USB 4.76 7.38 1379.66
5172318 qcne_sc300_sta200_015414_0 23 Apr 2009 4:12:23 UTC 23 Apr 2009 4:12:27 UTC 23 Apr 2009 4:02:22 UTC -0.006883 12.872495 1.516854 37.887708 -122.277847 0.02 2 JoyWarrior 24F8 USB 4.76 6.11 819.06
5172271 qcne_sc300_sta200_015414_0 23 Apr 2009 4:09:26 UTC 23 Apr 2009 4:09:30 UTC 23 Apr 2009 4:02:22 UTC -0.006883 3.594747 0.328485 37.887708 -122.277847 0.02 0 JoyWarrior 24F8 USB 4.76 3.52 642.8
5172260 qcne_sc300_sta200_015414_0 23 Apr 2009 4:08:17 UTC 23 Apr 2009 4:08:22 UTC 23 Apr 2009 4:02:22 UTC -0.006883 4.422219 0.324538 37.887708 -122.277847 0.02 0 JoyWarrior 24F8 USB 4.76 3.2 573.9

odd, I just put up a new version (4.80) in which I doubled the size of the cmd line (which should be much bigger than required), see if that works?

that's odd, I get no zombies & time sync OK with 4.80 on my Ubuntu & Debian tests (run for about an hour). I'm afraid I won't have too much time to work on Linux until I move back to Oxford in the next month; where I'll have more Linux boxes to play with. If the zombies get to be hogging up your machine you may want to suspend until I figure out what's happening (but I'm using waitpid so that should clear up any zombies, and it seems to be time syncing OK so I don't see where it would have crashed or anything).