|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|
Re: IPC::Open3 problem...
|
On Wed, 26 Jun 2002, Kyle R . Burton wrote:
> I'm using IPC::Open3 to exec ssh from a server process. I have a method
> that starts an ssh 'worker' command on a remote host. The method runs
> the worker, sends it a simple message to get back a response that
> indicates that the worker started. The server then goes on to interact with
> the workers.
If you are using openssh perhaps try -n to prevent ssh from forking into
background and detaching from terminal (on remote side)..
>
> This works fine when the server starts up. The server monitors the workers,
> and if one gets disconnected, or terminates, it uses the same function it
> used a start-up time to restart the worker. The problem is that when the
> server tries to send the initial status request, by writing to the input
> handle returned by the open3, it gets a SIGPIPE. The status message never
> reaches the worker, so it never sends back it's ack - and the server thinks
> the worker was stillborn so it kills it.
This sounds like writing to a closed fd. Because child close it or its
dead. Did you get a pid back?
>
> This feature is also supposed to be for adding in new workers at run-time,
> which also encounters a SIGPIPE.
>
> It happens both when starting new workers at run-time, as well as when
> trying to restart a worker that started successfuly when the server
> originaly started.
>
> I've checked on the remote box and the worker process does restart. What
> I can't figure out is why this works at start-up time, but doesn't work
> to restart a worker once the server has been up and running.
>
hmmm ... maybe ssh isn't working after startup beacuse you've logged out,
and server once had a tty, but now does not, and ssh is behaving
differently. I would add a few line to you program to fork, close input,
and detach from is tty and see if behavior is differnet.
>
>
> Has anyone come across anything similar before?
>
not really. I've done this sort of thing, but not exacty. My final
solution didn't keep persisent "workers" spawned by ssh. I can't recall
whether I used bi-driectional pipes or not with ssh. I think I relied
alot on error codes for feedback. I would have workers started and
reaped by a server that was always running on and took commands from a
FIFO instead. I used ssh only to write to that FIFO and queue requests.
BTW, I make sure if you "workers" will get reaped by ssh. Otherwise you
could end up with lots of dead workers.
I assume you are being careful with buffering ect ... it doesn't sound
like a buffering problem, becuase I would expect a deadlock not a SIGPIPE.
> > Thanks,
> Kyle
>
Hope this helps..
>
>
> --
>
> ------------------------------------------------------------------------------
> Wisdom and Compassion are inseparable.
> -- Christmas Humphreys
> mortis@voicenet.com http://www.voicenet.com/~mortis
> ------------------------------------------------------------------------------
> **Majordomo list services provided by PANIX <URL:http://www.panix.com>**
> **To Unsubscribe, send "unsubscribe phl" to majordomo@lists.pm.org**
>
--
Phone: 856-482-9695
Email: ghamlin@typhoon.lightning.net
quote of moment from: http://www.detonate.net/matrixse/
Neo: Do you always look it heavily encrypted?
Cypher:Oh thats not encyption ... It's a new perl script I'm working on ...
**Majordomo list services provided by PANIX <URL:http://www.panix.com>**
**To Unsubscribe, send "unsubscribe phl" to majordomo@lists.pm.org**
|
|