On 06Apr2010 14:49, sunhux G <sunhux@xxxxxxxxx> wrote:
| Thanks very much, Mr Simpson.
|
|
| Have a few clarifications :
|
| A)
| Can I use a sub-second as the intervals, say, eg, run for 0.2 sec &
| pause for 0.1 sec so that any slowed response will not be noticeable
| to users, eg, in the case of a web server.
| stutter 0.2 0.1 busy-command...
| (sorry can't test out 'sleep sub-second' currently as I don't have
On RedHat and other systems using GNU sleep, yes.
I suggest you test this by hand at a shell prompt when you have the
opportunity:
sleep 0.5
If that sleeps for half a second (as opposed to, say, no time at all)
then you're probably ok.
| Can the stutter script be used on a currently running pid, ie
| stutter 2 1 pid_of_a_running_process
Not as written. It would be pretty easy to change it though.
| C)
| Which Shell copes the best?
| Suppose a script or app is started from Bash, but I used root, switch
| to say a Bourne shell ("sh") & run the stutter script, would this enable
| the process to cope better?
I don't know. You could try using a Korn shell (ksh) to run the script
if you encounter difficulties. My recollection was that the difficulties
took for form of job control messages from the shell you were using.
| D)
| Would it cope better if the line below is replaced as follows, ie replace
| while kill -STOP "$cmdpid" 2>/dev/null
| with
| while trap "sigstop received, pausing" $SIGSTOP; kill -STOP "$cmdpid"
| 2>/dev/null
1: You want "STOP", not "$SIGSTOP"
2: I'm pretty sure you can't catch SIGSTOP, and thus you can't "trap"
"STOP".
3: Why would this be better? It's harder to read if nothing else.
Or were you hoping to avoid the job control weirdness?
4: I'm pretty sure the trapping wouldn't work anyway - only the subprocess
(busy-command) is receiving the SIGSTOP; since the stutter script is not
receiving the signal, it can't trap it.
So in general ,no.
Just test out stutter:
stutter 1 1 sleep 10
and see how it behaves for you. It _may_ be ok.
Also, I'm inclined to think that if it were modified to signal another
processes' pid the job control issue might go away since the STOPped
process isn't part of the jobs being controlled by your shell.
Of course, it may just move it to someone else's shell...
Cheers,
--
Cameron Simpson <cs@xxxxxxxxxx> DoD#743
http://www.cskk.ezoshosting.com/cs/
I'm Bubba of Borg. Y'all fixin' to be assimilated.
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
