Crontab issues with DD and NC
 

I have been using the DD and NC command to clone disk drives with a good amount of Success. Example command. Master Node dd if=/dev/hda | nc IP 9000. Slave command nc -l -p 9000 | dd of=/dev/hdb. I am trying to get it to run on Cron. The slave node starts out waiting on port 9000 and the two commands can be seen with a ps -ef. But when the master node runs it comes back unsuccesfully with the output 1+0 records in
0+0 records out. I don't think it's firewall issues. Any help would be much appreciated. This is on Redhat Ent 3 btw. Thanks

The first thing to suspect when something works from the command line but not from cron is ... ENVIRONMENT. Is the PATH set appropriately (i.e., can it find the commands being called?) Is a different shell being invoked (ksh vs. bash perhaps?) Any other environmental variables you might be depending on?

I have no idea if this relates to your problem or not. It's just a general cron debugging tip I thought I'd throw out there...

And when starting the server by hand, I mean, without cron, did it work ?

Ok thanks for the advice. Today I tested the way I thought it was failing, used cron on the master and ran the command normal on the slave and it worked fine. So I thought maybe I made a mistake when running the cron and tried again but it did not work same as before. So I am in the process of testing it the other way, cron on slave manually run the command on the master. I had been told the environment was different but thought it was maybe a path problem. Now that you point out the different shells I am going to research it a bit, run this test and post my results in about an hour. Thanks!

So I am back, and still stuck. The problem is I cannot seem to troubleshoot the problem. I try to redirect standard error and the only output I ever get is

1+0 records in
0+0 records out

It works very well from command line, but from cron it fails for some reason. But not complete failure the actual handshake is made or some sort of error would be reported and besides I have seen it in Tcpdump. I outputted tcpdump to a file from the failure and from a succesful version and have tried to debug it. You can see the handshake being made, its what immediately terminates the command.....

How do I debug this problem?

I have tried full paths to the commands and that does not seem to change anything. I am looking for ideas, thanks for your help

Everlast

A good start point is replace the dd command with something more friendly, like cat and redirect the standard error to specific files. Something like that:
Inspecting the 4 errors files should give you some hint what is happening.

Would be nice after you manage to put this thing working, to post your findings back here.

good luck

I have been playing with this some and have had some odd results. The cat stuff had the same reaction since the problem involves the tcp handshake in one capacity or another. Anyway I started playing with the error redirect with the DD and was getting at least some information. I noticed in the one error file this, 9000 (?) open. That question mark made me wonder. I tried the same thing with the -u switch and it worked, go figure. So the question arises as to whether or not UDP is reliable enough. I am told from a friend that this app solves the problem and is much faster than tcp. http://udpcast.linux.lu/source.html. Anyway I don't have time to figure out why the tcp packets did not work as long as this solution works like it seems too. I will post in a few days about how easy the udpcast is to use. If anyone can solve the tcp packet problem over cron with netcat I would love to hear it.

Everlast