Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
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.
First of all:
1. Yes, I have to use UUCP.
2. No, there is no way to replace it with RSYNC/SCP/etc.
3. Please don't tell me how to replace UUCP or why I should do this or why I shouldn't be using UUCP.
So here is a problem.
It looks like UUCP can't handle more than X (15?) number of concurrent connections over long (more than 10 min) period of time.
I've run lots of stress test (UUCP over SSH, plain UUCP) and it looks like I'm getting error PIPE BROKEN/ Time Out. I have 19 branches, 1 head office server, all connections are coming at the same time from the branches to the HO server. And every so often 1-2 would drop so I have to re-run uucico for that systems.
No, running 19 connections with scp doesn't fail so I'm assuming that network is fine.
I'm using Taylor's UUCP on RHEL4 with protocol "e". I'm suspecting that one of the buffers is overfilling somewhere within UUCP, but don't know how to check it/prove my theory.
Did anyone had similar problems? Is it a know issue? I've used google to research topic but can't see people mentioning this kind of problems.
All advice much appreciated. Especially how to see what's closing socket? No problems with ram (18GB, lots of free, swap not even touched!), no problems with disk speeds, no problems with CPUS.
Thanks for your answer. Yeah, I know It's not easy to find system which still uses UUCP
Well, I have solution for now - uucico tries failed systems, but it's rather dirty hack then proper resolution to the problem.
The way comms are designed there is no easy way to stagger them. Plus it's usually one-two failed connections so it's quicker just to resume them