-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, Apr 07, 2007 at 02:03:10PM -0400, William L. Maltby wrote:
> > 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.
oh, we can just create a nice little GPLed C application, generic enough
to suit most cases.
> > > 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.
Actually, I'm assuming low precision too. I just got facinated by
this issue.
> 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" :-)
LOL.
> Needless to say, I garnered much more revenue when fixing up their
> "inverse KISS" implementations.
Tell me about it. I have spent a lot of time lately migrating SERVERS
built with Kurumim (ick!) to CentOS.
> > 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.
Oh, I did a lot of shell coding too. Even tho I have to confess I
usually cheat with a lot of sed and awk :)
> > > 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.
Your solution would have a precision of 5 to 10 seconds, I estimate.
If that is good enough, it is a simple way to do it. That should give
higher than 95% precision, usually higher than 98%. Not bad for a
small script.
> > > 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.
It IS overkill :) I'm just considering a generic implementation, not
the need of OP. Actually, I'm considering creating a small GPLed
program to do this, so I have to cover as many situations as possible.
I think you misunderstood me, when you say the target has to have this
facility. I was talking about a callibration child, not the exec() one.
> > 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.
I know. The only (somewhat) reliable way to do this is to trap
the ELF loader, not the target program itself. And that would be
nasty to do.
I was even considering using some kind of LD_PRELOAD trick for this.
Now, THAT would be overkill :)
> > 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.
I second that. Since I started my own company, the business side of
it is taking so much time I'm getting really rusty on shell/C skills.
> > > > 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.
Well, it IS possible to run the target a few times, and gather the
information either using times(2) (in C) or time(1) (in a shell).
That would give us the values we need. It would be kind of precise,
too, since we could look past all those I/O and scheduller issues.
Which might be exactly what the OP needs.
I imagine a callibration loop, where we would run the program a few
times, with different (...)& alarms and maybe a few "ulimit -t" passes,
gathering time(1) values.
Then, with that data in hand, we could save that value inside a
cache/db for further uses. From that point on, the script would only
need to check that database for the appropriate value when executing
a given program.
- --
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)
iD8DBQFGF+TypdyWzQ5b5ckRAi4MAJ9XyEwWfs7XYpAg+//uqzYolktdCwCghCZy
oqoAsqdVFBgzGonjEkED+Qk=
=HIxH
-----END PGP SIGNATURE-----