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