rlogin via expect mysteriously aborts when run from cron

Hello, and sorry for crossposting. I'm not sure whether this is a problem related to shell, or to expect.

I have an application which, at some point, executes a zsh script. This
script in turn calls another script written in Tcl/Expect, and that one
does an rlogin to a remote host, does some interaction, and then returns.
Note also that the login-shell on the remote host is tcsh. The operating
system on both machines is Linux.

All this works fine when called manually, but when running it from a
cron job, it mysteriously dies within the rlogin thing.

So the first thing I did was to put a "set echo" in the .cshrc on
the remote system to see at which point the application dies.

When investigating the output which was sent to me from the cron job
via email, I found that on several runs, it died on different points
while executing .cshrc (in this case, there is a *lot* to do in .cshrc,
as there are MANY other scripts sourced). Moreover, it does not die
with an error message; instead, it is that someone "just has cut the
plug" during execution. I had one case where even a command

setenv VAR something

was listed only "half" in the cron job, as

setenv VAR som

In another case, the system was able to perform the whole login
process, Expect was even able to supply the first command as part
of the interaction, but the next command, which happened to be
a cd $HOME, was only listed, but I already didn't see the shell
prompt, so the connection must have been cut after this.

There were also no other output from my script after that.

So what could be the reason for this strange behaviour? Could
there be some kind of timeout be involved, which kills the
connection? Alternatively, could it be that cron collects output
only up to a certain amount, and if the application produces
more, it is killed?

The last one would explain why sometimes the commands seem to
be "cut in the middle"; due to the complexity of the rlogin
stuff, it is well possible that on successive invocations,
always a different amount of output is produced. OTOH, the man
pages for cron don't mention such a restriction.

Any ideas on this?

Ronald

--
Ronald Fischer <ronaldf@xxxxxx>
Posted via http://www.newsoffice.de/

.

Relevant Pages

  • Re: Newbie getting desperate with for
    ... This tells the shell to run the script ... When you run a command from the shell, it first tries to directly execv ... which calls the kernel to load and execute the file. ...
    (comp.lang.python)
  • Re: shell scripting
    ... and am assuming an sh-compatible shell here.... ... command 1 options arguments ... To run the script, do: ... then you need to use the full path to execute it: ...
    (comp.unix.questions)
  • Re: shell scripting
    ... and am assuming an sh-compatible shell here.... ... command 1 options arguments ... To run the script, do: ... then you need to use the full path to execute it: ...
    (comp.unix.shell)
  • Re: [opensuse] Lazarus and free pascal need ELF
    ... In a bourne shell interpreter, which is what you are in while you are logged in and sitting at a command prompt, the syntax "dot space filename" does not execute the file, it sources the file. ... It has the effect that your current shell instance ends up directly executing the commands, which may look and smell like the normal way a script or program is executed, but it's in fact quite different. ... The simplest example of why this is "wrong" even though it seems to "work for scripts" would be to look at any typical script that has an exit command. ...
    (SuSE)
  • Re: [opensuse] Lazarus and free pascal need ELF
    ... Lazarus the following in command line.. ... In a bourne shell interpreter, which is what you are in while you are ... Sourcing a file is usually meant for a script to read in some variables ... exit command. ...
    (SuSE)