Re: Re: command to ensure other command does last longer than5 seconds

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



-----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

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux