Alan McKay wrote, On 08/27/14 09:56:
I'm writing some scripts to clone over the network, and since I have
mostly boxes that do not have the -N option on nc, this is proving to
be an issue.
I have a bunch of dump files - one for each filesystem - that were
created from a live system. When I want to send them back over the
network to another system, it seems that the sender never really sees
the end of the file.
One the sender I do
nc <DEST IP> <DEST PORT> < dump.file
On the receiver I do simply
nc -l <DEST PORT> | restore -rf -
That send/receive pair will just hang there forever. But if I add the
-N option to the sender, it works as expected.
However I've also implemented some rudimentary handshaking - when the
recipient is done with the file I do :
echo "OK" | nc <SENDER IP> <DEST PORT>
Note no -N option - and it works great. The other end is just doing
"nc -l <DEST PORT>"
hmmm ... that's not what happens between my 5.5 systems. Neither end
will shutdown when the -N option is omitted (receiver or transmitter).
I wonder why your connection shuts down here without -N?
The difference seems to be the pipe.
So I'm thinking maybe introduce a superfluous dd on the original
sender, perhaps :
dd if=dump.file | nc <DEST IP> <DEST PORT>
But I try that and get the same results - they will just stay in that
state forever.
Any ideas on how to solve this problem?
I think the best solution is using the nc(1) -w timeout, which you
seemed to have discovered. I've seen the "timeout solution" recommended
in the past for this exact situation. I'm not sure there is another way
to shutdown the connection without the -N option.
