On Sat, 2007-04-07 at 14:20 -0300, Rodrigo Barbosa wrote:
> -----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.
Yes. My goal though is to use shell scripts because I assume no "C"
expertise from most admins and users, although it is certain many of
them have some based on my experience.
>
> > 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.
Without more info from the OP, you are right about "reliable". Since he
specified no precision needs, we are free to assume high precision is
need, as you seem to, or low precision is needed, as I do.
My background leads me to presume the latter in cases of insufficient
information for the task. It allows me to use the KISS principal more
frequently. He-he! That remeinds me of the "inverse KISS" principal
(which I *think* I coined - a large number of my former clients used to
"Keep It STUPID, Simpleton" :-)
Needless to say, I garnered much more revenue when fixing up their
"inverse KISS" implementations.
>
> 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.
Yep. My first *IX experience was in the original shell in PWB V6/7 and
subsequents. Later I also taught myself some C and such. I guess that's
why I'm ambivalent about "bash". What used to be a nice compact "shell"
is now a *relative* hog. I think I like "ash" for that reason.
>
> > 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).
As I say above, we can assume a lot since insufficient needs
specification was provided. I still stick with low precision until told
otherwise.
>
> > 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.
Ummm... I would use the plain old "test" command or bash's "if [ -f ..."
stuff. In a small loop with something like "sleep 1". Of course, the
bash "-s" or a read of a few bytes from the known file followed by a
test using -N might do the job. Again, in an appropriate loop. It all is
dependent on knowing what the target process is going to do and what
leeway we have, such as erasing/removing some file beforehand. If we can
do that, I'm sure some "while... sleep ..; if [ -{s|N}} <file> ] ;
then ..." construct would do admirably.
>
> > 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).
That requires that we can require the target to have this facility. All
above are valid strategies but, at the risk of seeming rude, seem a
little overkill for the task originally presented to us.
>
> If you add times(2) to the mix, you can get a somewhat precise
> callibration (baring sudden usage spikes).
As you already know, as soon as we rely on that, there will be a
"spike". Something about a joker named Murphy predicting this.
>
> 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.
I enjoy this sort of stuff. Don't get to do it often enough. And in the
last upmteen years, haven't kept my shell/C skills up-to-snuff.
Essentially retired from the race after enough decades of it.
>
> > > 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 ;-)
Yep. BTW ...
If we knew how much of a cpu hog the app was, we could "ulimit -t" the
target and forget all this other stuff.
> <snip sig stuff>
--
Bill