Xref: utzoo comp.unix.wizards:23993 comp.unix.programmer:1005 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!world!bzs From: bzs@world.std.com (Barry Shein) Newsgroups: comp.unix.wizards,comp.unix.programmer Subject: Re: deamon help Message-ID: Date: 7 Feb 91 03:17:12 GMT References: <594@edpmgt.UUCP> <2304@inews.intel.com> <19032@rpp386.cactus.org> Sender: bzs@world.std.com (Barry Shein) Organization: The World Lines: 30 In-Reply-To: jfh@rpp386.cactus.org's message of 6 Feb 91 13:29:16 GMT From: jfh@rpp386.cactus.org (John F Haugh II) >Hmmm. I'm half tempted to take that bet. One problem I envision with >the PS approach is that the CPU resolution is to the full second, and >there are many processes which lurk about in the background and don't >use much more than a second in a days time. That's a good point (see, you can tell the "wizards", they're the ones willing to admit they may be wrong...:-) Looks like we need another option to ps...to increase clock res. Seriously, grokking around in the kernel proc structures tends to be fraught with peril unless you're really pre-disposed to that sort of thing. The next best suggestion would be to try to find a reliable program distributed with source to just modify for this task. "Top" comes to mind, modifying top to do this, or even just rip out the full-screenness (there's a flag for this, -b) and modify the print-out to include more precision and then revert to the script idea. Whatever, at that point the rest of the code is probably pretty simple, just sleep, sweep an array, and kill if desired (how easy this is depends on how top is structured internally.) -- -Barry Shein Software Tool & Die | bzs@world.std.com | uunet!world!bzs Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD