Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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...
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
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:
Code:
$ cat /tmp/input 2> /tmp/cat.error | nc ip port 2> /tmp/nc.error
and in the other side
$ nc -l -p port 2> /tmp/nc.error | cat > /tmp/output 2> /tmp/cat.error
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.