way to queue up multiple requests to run a program

[Steve Post]

I'm looking for a way to have a program queue up requests to a 3rd party script.

There's this unidata program that runs a 3rd party application via shell script. If I run it slowly it works great. But if anyone runs it close to the same time, it drops into an infinite loop (that I have to fix by hand).

I know there's got to be a way to queue the requests I'm just blanking here. I CAN describe it at least.

runprog.sh
sh badprogram.sh &
sh badprogram.sh &

If I run "runprog.sh", I'm sending 2 jobs to the badprogram.sh. I'll get an infinite loop because badprogram.sh will not queue up the requests.

If this was an RS6000 running AIX, I would make "badprogram.sh" the backend of a printer. Then the computer would queue the request like a printer. The computer would not know or care that "badprogram.sh" is NOT a printer.

Any ideas?

[Steve Steel]

Hi


Use at and put the users in at.allow

See man at

at, batch - execute batched commands immediately or at a later time



Steve Steel

[Steve Post]

That won't work will it?
Let's go through the scenario....
5 users want to run badprogram.sh.
I spawn off 5 at jobs for now+1 minute.

If I have 5 at jobs to run at 8:43AM, will it run it 1 then 2 then 3 then 4, and then 5?
or run it 1&2&3&4&5 at the same time?

[Ian Dennison_1 · Accepted solution]

to schedule them sequentially,...

job1;job1;job1

Or put them in a wrapper script,.
#!/usr/bin/sh

for i in bob jane dick
do
job1 $i
done

Then 'at -now' command to the script file.

Share and Enjoy! Ian

[Steve Steel]

Hi

See what you mean . They would run at same time for different users.



Thus using to test

while UNIX95= ps -e -o args|grep -i badprogram.sh|grep -v grep
do
sleep 10
echo 1
done
sh badprogram.sh &


This will only launch badprogram when none is running

Something like that.

Or the printer idea should work.

Make a printer on a non standard device in sam
and replace thescript with your script and then
calling printer badprogram

lp -dbadprogram will run it


Steve Steel

[Leif Halvarsson_2]

Hi,
An unususl idea.
Perhaps it could pe possible to use the printer scheduler for this. Create a printer interface script which run the "badprogram.sh" and set up a printer queue with this interface script (output to /dev/null). Whith this metod you also can use the standard lp commands to monitor and administrate the jobs.

[Stanimir]

Hi!
I'm thinking about organization like:

runprog.sh:

$PAR=badprogram.sh
ps -ef | grep $PAR | sort > /tmp/testfile
test -s /tmp/testfile
if [ $? = "0" ]
then
echo "An example of $PAR have already
running. Please try again later" > ./logfile
exit
fi
...
< main part of runprog.sh >
...


And then you can re-run every 10-15 min
runprog.sh.
Something close to this. As option you can also use "sleep" to delay execution of
badprogram.sh, when your test find another
example running.
Regards.

[Stanimir]

And also I suppose the brilliant solution
for this case is creating a client-server
example,using sockets. In this case the
server can forks 5-6 independant childs to
work like your "badprogram.sh" without
any interference between them.
Regards,Stan

[Steve Post]

ok ok. WOW! That didn't take long did it?
You folks broke my writer's block for sure.

1. I can try a wrapper program.
2. I can try the at command.
3. I can try my print queue idea (that's what I did in AIX unix too). Good to see it's possible in HPUX.

When I did it on AIX, it was to run a robot that spits out pills (instead of paper).

Thanks. Points are coming.

Steve

[Steve Post]

The wrapper script won't work.
I have NO control over the users running the program. So I can't build a batch job for them by hand.

The "at job" almost works. It schedules the jobs at 1 second intervals.

So if 2 users run the program at the same nanosecond, it will put them one second apart. It is very possible badprogram.sh will not be done in one second. That's what my tests show at least. So I would use some type of lock file it will probably handle it correctly.
ie: if [ -f badprog.lock ] ; then
batch badprod.sh # again
else
touch badprog.lock
./badprogrun.sh
rm badprog.lock
fi
OR like what JS wrote.

The client-server thing might work. But I'm not going to do it. I don't know how. Besides you should always try to keep things simple (aka maintainable).

The printer backend idea looks real good. But I'm biased. It's what I did before.

Thanks again.
steve

[Steve Post]

fyi: The printer idea worked great.

I moved /usr/3rdparty/badprog.exe to badprod.exe.real

I made a new badprog.exe file.
I made an interface file for the "printer".


lpshut && lpadmin -pbadprog_ptr -v/dev/null -i/tmp/badprog.interface && lpsched

The interface file....
#!/bin/ksh
# file /tmp/badprog.interface
job=$1
user=$2
title=$3
copy=$4
options=$5
shift; shift; shift; shift; shift
files="$*"
runcommand=`cat $files`

sleep 10
date >> /tmp/steve.log
echo " /usr/3rdparty/badprog.real $runcommand" \ >> /tmp/steve.log
/usr/3rdparty/badprog.real $runcommand
exit 0
###########eof##########
This gets copied to /etc/lp/interface/badprod_ptr.


#!/bin/ksh
#file /usr/3rdparty/badprog.exe
# this is the fake version of badprod.exe
# this runs the print command.
# the real version of badprog.exe is run by
# the interface file for printer badprod_ptr.
host=$1
infile=$2
outfile=$3
echo "$host $infile $outfile" | lp -dbadprog_ptr
###########eof##########
That's it. Of course this printer should only be used the way it is SUPPOSED to be used. It would be called only from another program. The user NEVER would use the printer directly.