one log for each module
There are some way to have a log for each module? If there aren't, it should be a a great functionality for maintaining the server. Thanks for the help and continue with this great application !
Re: one log for each module
Well, Ivan, it's not in the code, at least, not yet. How about this for a simple solution. use syslog. Choose an unused facility. make the destination a program. Perl is probably the best tool for this. filehandle named for module called. they can be generated on the fly. the process id is used to direct the wrote somany bytes lines to the right file. You could do it with a growing array of filehandles, or simply opening and closing the filehandles in append mode, as needed. I prefer the second one, as it makes it possible to manage the logs without restarting. Of course, you'll have one log program running continuously, with a line feeder called by syslog. Actually, it would probably be easier to just make the syslog destination a fifo, and read that from the perl script. I've had bad luck with fifos, but maybe perl does a better job handling them than the shell scripts i was using. Good luck. Tim Conway [EMAIL PROTECTED] 303.682.4917 Philips Semiconductor - Longmont TC 1880 Industrial Circle, Suite D Longmont, CO 80501 Available via SameTime Connect within Philips, n9hmg on AIM perl -e 'print pack(, 19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970), .\n ' There are some who call me Tim? Ivan Renedo [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/26/2001 10:08 AM Please respond to ivan To:[EMAIL PROTECTED] cc:(bcc: Tim Conway/LMT/SC/PHILIPS) Subject:one log for each module Classification: There are some way to have a log for each module? If there aren't, it should be a a great functionality for maintaining the server. Thanks for the help and continue with this great application !
Re: one log for each module
On Fri, Oct 26, 2001 at 06:08:55PM +0200, Ivan Renedo wrote: There are some way to have a log for each module? If there aren't, it should be a a great functionality for maintaining the server. Thanks for the help and continue with this great application ! Currently the log file option is a global but I don't see why it can't be made into a local. Do you want to work up a patch? At one point the log file was opened early and never closed reopened on a long-running rsync --daemon, but I changed that a while ago to re-open the log file on every new connection, and that may have taken away the reason for making it a global. - Dave Dykstra
2.4.7p1 protocol differences?
Hi all, rsync-2.4.6 has been running for quite a while with no problems, until about a week ago when for some reason it blocked on the same host ever time. I use it to backup about thirty hosts to my backup server, but for some reason it's illiciting that blocking bug that some people experience with 2.4.6. So, I upgraded the client side with 2.4.7, but it complained of protocol differences. I certainly can't upgrade all 30 hosts to 2.4.7p1, especially when it's not production-ready yet. The host that it's blocking on isn't even transferring all that much data. Maybe fourty or so meg per day. What could be happening? Thanks, Dave
avoid different versions
Is their a way or a quick bash script anyone has that would first take down the files, but after would look through the list downloaded and any duplicate file with some version, the highest version would be taken and the lower versions deleted? -- Jason G Helfman Network Administrator BizRate.com 310.754.1264 desk 310.466.2319 cell Fingerprint: DA13 C109 072B CC12 B568 8D84 E9A2 6A7D C479 BCFB GnuPG http://www.gnupg.org Get Private! 1024D/D75E0A36
