topic Re: at command in Operating System - HP-UX

at command

Leslie Chaim — Wed, 02 May 2001 16:38:26 GMT

Re: at command

Leslie Chaim — Wed, 02 May 2001 16:58:34 GMT

Sorry I hit the enter key too soon:)

Well, I was able to 'solve' my problem but I still have some questions I would like to clear.

First let me outline what the script does:
It starts on machine A collects some data
then 'remsh' to machine B and collects some more data then it 'remsh' to machine C
followed by some other chores on machine A.

When I run the job without the 'at' command it runs fine. However if I start it with the at command it does not work if I start it as follows:

at now < driver.sh

The above fails after completing on machine B the job just stops. However if I start the job as follows:

at now
driver.sh
Ctrl D

This works fine. A small wrapper does the job as well.

Why does the 'driver.sh' stop after completing it's work on Machine B when using input redirection to the 'at' command.

I checked the spooler by doing at -d jobid, and after removing all of the environment stuff , a ?diff? to the original is successful.

Just looking for an explanation!

Thanks,

Leslie

Re: at command

John Bolene — Thu, 03 May 2001 12:34:11 GMT

Things that work for us are:
cat script|at now
at now -f script

In the case of
at now< script
It would appear that the pipe gets broken.

Re: at command

Pedro Sousa — Thu, 03 May 2001 12:43:04 GMT

Leslie, normally you need to specify the file with '-f' flag. If you specify '<' maybe it doesn't read it's contents.
When I run something with the at, I do it as follows: at -f -t

Re: at command

Leslie Chaim — Thu, 03 May 2001 12:53:08 GMT

I guess the -f option may be more elegent, nevertheless, reading from stdin should be no problem.

if 'cat job | at now' works why sould it differ from 'at now < job'? Also, what do yo0u mean by a broken pipe?

Re: at command

John Bolene — Thu, 03 May 2001 13:03:28 GMT

Since you submit the job to be partially run on another machine, the at command may not have read all the file to be submitted.

When it comes time to read more, the job has already been sent to the other machine with remsh.

Re: at command

Pedro Sousa — Thu, 03 May 2001 13:12:05 GMT

Sorry. You're completely right. it works fine for me...
so, it's very strange. Maybe it has to do with the shell? Just a thought

Re: at command

James R. Ferguson — Thu, 03 May 2001 13:16:07 GMT

Leslie:

I think the "anomoies" have to do with when stdin is closed and with . From the man pages for 'remsh':

/begin_quote/

By default, remsh reads its standard input and sends it to the remote command because remsh has no way to determine whether the remote
command requires input. The -n option redirects standard input to remsh from /dev/null. This is useful when running a shell script containing a remsh command, since otherwise remsh may use input not intended for it. The -n option is also useful when running remsh in the background from a job control shell, /usr/bin/csh or /usr/bin/ksh. Otherwise, remsh stops and waits for input from the terminal keyboard for the remote command. /usr/bin/sh automatically redirects its input from /dev/null when jobs are run in the background.

/end_quote/

...and from 'man at':

/begin_quote/

You can enter commands into a job...From the keyboard on separate lines immediately after the at or batch command line, followed by the currently defined eof (end-of-file) character to end the input.

/end_quote/

Does this help?

...JRF...

Re: at command

Vincenzo Restuccia — Thu, 03 May 2001 13:41:56 GMT

echo "sh $HOME/jobs/weekly-run" | at 1900 thursday next week

Re: at command

Ravi_8 — Fri, 04 May 2001 09:20:57 GMT

at now < script
'at' command taking i/p from script.
"at now script" should work

Re: at command

Wieslaw Krajewski — Fri, 04 May 2001 18:09:02 GMT

Hi,

This is pretty interesting problem.
I've made some experiments, that I'd like to summarize:

0. First of all to adopt some assumptions.
In the file driver.sh there are a few remsh commands, as for example:

remsh hostA cmd ...
remsh hostB cmd ...
remsh hostC cmd ...

1. James seems to be very close to the right explanation.
Being executed the first command wait for sth from STDIN.

2. If we try to run directly (without file driver.sh)

at now
remsh hostA cmd ...
remsh hostB cmd ...
remsh hostC cmd ..
^d

we observe the same behaviour as when running
at now < driver.sh

only first command is executed. I assumed that this is related to executing these commands in background.

3. So I prepared a script with these commands in it, and when this script is run in the foreground everything is OK, whereas running this script in background (script.sh &)
it resulted as in running via at command. Only first command was executed. Furthermore I noticed running jobs commans, the result was as below.

[1] + Stopped (SIGTTIN)

man 5 signal

SIGTTIN means Background process attempting read.

4. At the next step I added to my script

trap '' 27

as the first line. Then this script when run in background was running correctly, i.e. all remsh commands have been executed.

Unfortunately adding trap command as the first command in the at command does not help.
So this can be further investigated.

Hope this help a little in explanation.

Rgds.