-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, Apr 07, 2007 at 12:43:52PM -0400, William L. Maltby wrote: > > > > 2) You are forgeting to take starting up time in consideration > > > > > > > > Say a problem will take 2 seconds to start up, due to > > > > any reason (disk I/O, memory, swap etc). If you specify 4 seconds > > > > as the limit, the problem will actually run for only 2 seconds. > > > > > > > > I have no idea how to solve this second issue. > > > > > > > > > > Run the pre-defined script with a nice command (maybe -20, etc.), start > > > the process in background (with a somewhat smaller nice?), capture it's > > > start time and the current time (both in seconds since epoch), take > > > difference between them and subtract that from desired run duration, > > > round to seconds/minutes, ..., use that value. > > > > Hummm, I still don't see how that can work. > > > > my_prio=getpriority(PRIO_PROCESS,0); > > > > if (!(cpid=fork())) { > > setpriority(PRIO_PROCESS,0,-20); > > execvp(...); > > } > > > > some_magic(); > > setpriority(PRIO_PROCESS,cpid,my_prio); > > alarm(limit_time); > > > > > > So here I have the cpid, which is the PID of the process. How can I know > > when the startup is finished ? What is this some_magic() function you are > > proposing ? > > No. I envision the controlling shell started at some hard-coded "nice" > value and the other process is kicked of with nice at a "lower" hard- > coded priority. Shell returns the PID of children - it is captured. So we can have something like: setpriority(PRIO_PROCESS,0,my_prio-10) that should have about the same effect. > Capture the target process PID from the shell commands (no 'C' > envisioned here - otherwise I'd solve it all with sigaction calls - > "sleep" and/or "trap" in BASH) sigaction is fine by me. I proposed it earlier. I still don't think you can do anything even moderately reliable (in this particular case) using shell only. If I've got your meaning write, you are proposing something like: ( sleep $TIMER; kill -WHATEVER $PID )& Which is pretty interesting way to do it, which I haven't though about until now. I never tried (...)&, and after you said this, I decided to see if it worked. And it did. It is a pretty neat way to create alarms inside a shell script. > and the target process can be assumed to start up reasonable quickly > (we *do* "nice" it) Well, maybe at runlevel 1. Otherwise, we really can't make that assumption. Process scheduling is pretty weird these days (not to mention delays due to I/O). > or it may have desirable attributes, like leaving a PID file in /var, ... You mean like using libfam/gamin to monitor that file ? It _could_ work, but we have no way to garantee that will be always the case. > Also, we could do a small loop looking for CPU time used vi "ps" (if > significant enough load is imposed by the target) or such "rabbit > tracks" as PID files or whatever. If you want to go as farther as that, we can always ptrace the child. But I'm not willing to do something as weird like that. > If they are not available, well a SWAG > (Scientific Wild Ass Guess) may suffice (OP didn't sound like precision > was an issue at all) for OP's needs. I know. We can always run a calibration cicle beforehand. We can even dlopen all the libraries the problem will need (you can get then either by decoding the ELF header, or even by popen()ing ldd against it, and reading the results). Actually, we could even start a child specific for dlopening the libs (this way we don't affect the calling process), and wait for it to signal back. This child, of course, won't _exit, but enter an idle loop, maybe using a select() where we can communicate with it (and so tell it when to finish). If you add times(2) to the mix, you can get a somewhat precise callibration (baring sudden usage spikes). And yes, I think you are right about the OPs doesn't needing that much precision. But this is a question that has occured to me from time to time in the past years, and I never got to discussing it with anyone. > > One last quiestion: how off-topic are we ? :) ehehehe > > :-) Based on past list postings for *many* other threads? Not at all! > ;-> Well, this one is at least interesting ;-) - -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFGF9LxpdyWzQ5b5ckRAhTNAJsFbxbc9VI4etvMRIfZoUt23PQGswCfdDSO S/9ENP/nXX5gUhAP4QZ0aUw= =TvMP -----END PGP SIGNATURE----- _______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos