1

I have some perl script which executes some commands on remote gerrit server via SSH. It's running on a Debian lenny virtual machin. During several monthes it was executed in the following way:

./script.pl &>~/script.log &
disown

and everything was working well. However from the last friday this script and its child processes ("sh -c ssh ...." and "ssh ...") hangs at some moment exactly during remote command execution. "ps x" shows status T (sTopped) for all of them. Sending SIGCONT dosen't really helps. They recive SIGSTOP immediatelly after it.

I can't see such wired behaviour when runing this script interactivelly (now it works in screen without any problems).

I have tried to use strace to investigate what happens but I can't catch this bug since this scripts works well when started interactively. I don't know who can send SIGSTOP and I don't know which process exactly recives this signal first. Can I find out this information somehow? How can such issue be investigated?

P.S. My scope of responsibility is limited to monitor and restart (if needed) this script. I don't know which changes were made on this server or on remote gerrit server by responsible people.

1
  • 1
    You can run strace on non-interactive invocations; just run strace -f -o /tmp/script.strace ./script.pl ...
    – womble
    Aug 8, 2011 at 5:32

1 Answer 1

1

After more experiments with strace (thanks for womble's comment) I discovered that my ssh process recives SIGTTIN and this causes the problem I faced. The first link from google for the "ssh SIGTTIN" clarifies the situation: http://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch07_04.htm section "7.4.5.6. Backgrounding a remote command":

ssh provides the -n command-line option to get around this problem. It redirects standard input to come from /dev/null, which prevents ssh from blocking for input.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .