Thanks for your answer. I understand the problem - there is at the moment no better solution as using syslogd...
the good thing on using syslog is: You can use syslog-ng to filter the SYSLOG by application, facility etc... One other nice ability of syslog-ng is also that a simple custom script can handle the syslog-entries - and syslog-ng takes care that nothing will be lost... conclusion: i write my own statistics script using syslog-ng :-) Otto -- www.bergerdata.de Sam Clippinger schrieb: > With a solution like that, the concurrency problems would quickly render > the data worthless. As you mentioned, each instance of spamdyke would > have to read the statistics file, increment the counters and rewrite the > file. > > However, imagine if two instances of spamdyke tried to do this > simultaneously. If they both read the file at the same time, they would > both load the same numbers into memory. They would both increment one > of the counters and try to rewrite the file. It would be a classic > "race condition", where the last process to write the file would produce > the numbers that were saved. The other process' numbers would be lost. > On a busy server, you would lose so much data that the file would be > meaningless. > > Incidentally, this is exactly why the syslogd daemon exists. If every > daemon on the server tried to write its own entries to the system logs, > many entries would be lost. The syslogd daemon accepts the log messages > through a system call (not subject to this type of race condition) and > writes the file itself. > > Once spamdyke runs as a daemon, these concerns will disappear. spamdyke > could write to a statistics file periodically, log to a database > periodically or whatever. I'll put this suggestion on my TODO list. > > -- Sam Clippinger > > Otto Berger wrote: >> Hi Sam, >> >> first of all i would like to thank you for providing this great software >> - it saved on our spam-gateway much cpu-time regarding spamassassin... >> >> I have one request regarding spamdyke statistics: >> >> I'd dont like very much that log-file-scanning method (run by 5 minutes) >> to get statistical data. >> >> What about the idea that spamdyke writes a small statistics file with >> simple counters (32bit-overflow?) for example. >> >> Then it should be very easy an performance-friendly to generate >> rrdtool-related graphs (MRTG, cacti). >> >> Example: >> >> DENIED_RBL_MATCH 985485 >> DENIED_RHSBL_MATCH 56 >> DENIED_SENDER_NO_MX 856 >> >> >> i know - spamdyke isnt a deamon, so on every run the stats-file must be >> parsed and updated - but i think its a more clean solution as scanning >> big logfiles... >> >> what do you think about it? >> >> many regards, >> >> Otto >> >> -- >> www.bergerdata.de >> >> >> >> night duke schrieb: >>> It's possible to make stats of spam with maillog. >>> It's easy to do with mrtg? >>> >>> Thanks >>> >>> Nightduke >>> >>> >>> >>> >>> ______________________________________________ >>> ¿Chef por primera vez? >>> Sé un mejor Cocinillas. >>> http://es.answers.yahoo.com/info/welcome >>> _______________________________________________ >>> spamdyke-users mailing list >>> [email protected] >>> http://www.spamdyke.org/mailman/listinfo/spamdyke-users >> _______________________________________________ >> spamdyke-users mailing list >> [email protected] >> http://www.spamdyke.org/mailman/listinfo/spamdyke-users > _______________________________________________ > spamdyke-users mailing list > [email protected] > http://www.spamdyke.org/mailman/listinfo/spamdyke-users _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
