Secure Shell
Couldn't wait for ssh process: No child processes Mar 03 2010 06:28PM
Dave Jones (davejones70 gmail com) (1 replies)
Re: Couldn't wait for ssh process: No child processes Mar 05 2010 05:58AM
Derek Martin (code pizzashack org)
On Wed, Mar 03, 2010 at 12:28:18PM -0600, Dave Jones wrote:
> I am using swatch to monitor the vsftpd log and the secure log for FTP
> and SFTP inbound transfers then trigger a script to send the file
> outbound. When I use the sftp command to send a file outbound, I am
> getting "Couldn't wait for ssh process: No child processes" with a
> return code of 255. Here's the strange thing:

RC 255 == RC -1, which I believe very often means that a child program
could not be fork()'d or exec()'d. My first guess -- and it's just a
guess -- is that your script does not specify the path to your sftp
binary, and it's not in the $PATH that swatch passes to its children.
Adding the second shell script may somehow reinstate the $PATH that
contains the path to the binary. To be honest, based on what you
described, this scenario seems a little bit unlikely; but I can't
think of one that's more likely. That this succeeds when piped
through tee (though, *what* is piped through tee?), seems like a very
odd wild card. I might be inclined to think that this had something
to do with stdin/stdout being or not being a tty, but it looks to me
like it should not be a tty in all 3 cases... Hard to say for sure
though. Depends on what swatch does, and on what the scripts do.

> swatch -> script2.sh -> sftp command -> fails with RC 255
> swatch -> script1.sh -> script2.sh -> sftp command -> successful with RC 0
> swatch -> script2.sh -> sftp command piped through tee -> successful with RC 255

This little diagram tells us surprisingly little of importance. We
don't positively know:

- what the value of $PATH is at any given point
- what script2.sh looks like, and most importantly how it's invoked
- what script1.sh looks like, and most importantly how it's invoked
- whether or not stdin/stdout is a TTY at any given point
- where (i.e. what program) the error message you quoted came from
- what platform(s) this is (though it looks like the server is cygwin)
- etc.

If your shell is bash, then how it is invoked by the shell script
actually could matter quite a lot. If script2.sh is invoked as:

#!/bin/sh

but script1.sh is invoked as:

#!/bin/bash

...then this might actually lend support to my theory above. In such a
case, the script invoked as /bin/bash could possibly source the .rc
files (i.e. of the user as which the script was invoked, which could change
the environment of its children quite drastically (for example, if
$BASH_ENV is set in the environment -- unlikely but possible).

And of course, if either of these scripts sets any environment
variables or otherwise manipulates the environment the script runs in,
all bets are off.

Another possibility is that the arguments are not quoted properly as
passed from swatch to your script, *AND* they're not quoted properly
in script1.sh, and the two wrongs in this case actually do make a
right; e.g. swatch passes the args all as one string, and the
intermediate script expands the string without quoting such that each
token is passed as a distinct argument, which by chance is actually
what was intended in the first place, so it works "by accident"
essentially.

From the log of the failed transfer:

> debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 1.3 seconds
> debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
> debug1: Exit status 0
> Couldn't wait for ssh process: No child processes^M
> + RC=255

This seems to suggest that whatever ssh command was run by swatch
actually succeeded (debug1: Exit status 0), but just didn't do what
you expected it to. It could be caused by a problem with command-line
quoting either in your script itself, or in how swatch calls it; and
somehow interposing the extra script fixes it. Or, it could be that
the error is not related to SSH at all. Or, all that could be
complete hogwash.

From your "successful" log:

> debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 1.3 seconds
> debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
> debug1: Exit status 0
> Couldn't wait for ssh process: No child processes^M
> + RC=0

Note that the same error message appears. Either this output was from
a session that was not really successful, or maybe the error message
is irrelevant to the problem? Without doing a side-by-side comparison
of the two logs, it looks to me like the only significant difference
was the RC itself. That suggests to me that the problem is not with
the SSH session, but with some other command that's in the script, or
with the way swatch is invoking the child. Or, maybe it's a cygwin
sshd bug... But, unless one of my guesses was right, I don't think
there's enough information here to figure out what the problem is. In
particular, were I to spend more time on this problem, I'd want to
know what platform(s) this is running on, and see the actual scripts
involved.

Hope that helps...

--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFLkJ1ydjdlQoHP510RAm/OAKCw96BoL9OpaZpqpPhY1pCXgPf7cACdG7MK
ATst8LTQIw7b6QxTLkyynuI=
=doqY
-----END PGP SIGNATURE-----

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus