Thanks for your additional hints! Maybe I should have pointed out more clearly that we are talking about a Virtual Private Server (VPS) using Virtuozzo. My own container (Virtual Server) is running Ubuntu 8.04 LTS (64-Bit) and Plesk: 9.5.3. Due to the virtualisation I don't see the underlying host filesystem, but I guess it's probably ext3. All I can see is the "vzfs" filesystem provided by Virtuozzo. My VPS gets 50GB of a RAID10-Array, but I don't know about the physical implementation (local SAS, external SAN, etc.).
Concerning the suspicion on the time stamp of the files, I saw that there was no abnormal behaviour (even if the files were actually stored on a remote system) and I could see reasonable time stamps. When I first discovered the problem the corresponding info file was dated Octobar 25th: -rw------- 1 qmaild nofiles 0 Oct 25 10:14 info. Problem persisted when I moved the file and a new file was touched by the system: -rw------- 1 qmaild nofiles 0 Dec 14 18:01 info. Since we exceeded a multiple of graylist-min-secs I'd say timesync should not have been the cause, but again, I'm not the master of the underlying host os (it's hosteurope and they mainly seem to do a good job). As far as I know the host system itself is syncing the hardware clock that my VPS gets the time from (there also were some recent reboots of the container as well before I recognized the issue). Concerning the filesystem check, I'll try to involve the provider in order to check integrity, since I'm not sure if running a filesystem check on a virtual filesystem would identify any physical disk errors. On the other hand, the RAID10-Array has the capability to identify and overcome any errors immediately. In case I may see the issue again, I'll try to do further diagnostics according to the things you mentioned. For the moment I'll enforcedly settle for not having an explanation on what had happened. Roland -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von Sam Clippinger Gesendet: Donnerstag, 16. Dezember 2010 05:03 An: spamdyke users Betreff: Re: [spamdyke-users] Greylisting entries won't update Sorry for the acronyms: QMT is QmailToaster -- a precompiled Linux distribution that includes a working qmail installation. LwQ is Life With Qmail -- a popular guide for compiling qmail from source and configuring it to work correctly. Both of these methods include a command that limits the amount of RAM qmail can use (and thus also limits spamdyke); when that limit is set too low, strange errors occur (not the "out of memory" errors you might expect). Since you're using Plesk, that consideration doesn't apply. SELinux is Security Enhanced Linux -- a loadable module that adds a ton of security-related "features" to the Linux kernel but usually only causes problems. SELinux is one of the first things most sysadmins disable or uninstall when they build a new server. I'm glad it started working, though it would have been nice to find a rational explanation. A couple more ideas occur to me. Is your graylist folder stored on a local filesystem or is it mounted from another server (e.g. NFS, AFS, CODA)? If it is stored remotely, is it possible there the qmail server's and the file server's clocks are out of sync? After all, everything about spamdyke's graylist-min-secs option relies on reading the timestamp on the file -- if that fails for some reason or returns a date within graylist-min-secs, incoming messages could remain graylisted forever. Is it possible your server's time was adjusted/updated recently (around the time you witnessed it suddenly working)? For that matter, what OS and version are you running? What filesystem type (e.g. ext3, reiserfs, XFS) are you using for the graylist folder? Have you run a filesystem check to make sure there are no disk errors lurking? -- Sam Clippinger On 12/15/10 4:11 PM, Roland Moelle wrote: > Sam, > > Concerning your questions: Yes, the messages are beeing greylisted > forever (for this address only). The log file contains "DENIED_GRAYLISTED from: > [email protected]". The EXISTING info file in > /var/qmail/spamdyke/greylist/moelle.biz/roland.moelle/redcoon.de was > not touched repeatedly at all. It was created at first attempt when it > was not existing with a size of zero and then it wasn't touched > anymore during the following attempts. The file for > [email protected] in the same directory was updated as desired. > > The available disk space is used for less than 3%, RAM for 10% and the > CPU-load is constantly below 3%, so I'd say the machine gets rather > bored than stressed. > I don't even have the foggiest notion of "QMT or LwQ" and also > "SELinux", so I can't comment these issues. > > I also don't know how the /var/qmail/spamdyke/conf.s entry came to my > spamdyke.conf file (I guess uninteded duplication of a line using vi - > shame on me), but I corrected this entry in a first step (change #1), > but did not reinitialize qmail or spamdyke at that point. > > - Then I renamed the existing info-file (as I already did yesterday, > too) (change #2) and > - I triggered a new message to make sure the problem persists: > The message was rejected twice with "DENIED_GRAYLISTED" but the > minimum time for greylisting was not past yet, so I had to wait for the third attempt. > - Meanwhile I prepared the new spamdyke.conf containing > "full-log-dir", but did not save it, yet. > > And guess what happened: The third attempt suddenly was accepted > (ALLOWED), the info file was updated. > Don't know wheater to cry or laugh right now. > > So I discarded the "full-log-dir" option. > Since change #2 didn't show any effect yesterday, I reversed the > remaining change #1 to see if this was the key ... and of course it was not. > > So I moved the renamed info file back in place, deleted the contents > an gave it a try ... and of course it worked fine now and the message > was accepted in third attempt. > In the end I checked my log files to see if it was really permanently > rejected with "DENIED_GRAYLISTED" yesterday and it was. > > I don't know what was happening and I'm not able to reproduce the > problem anymore. Magic! > I'm sorry for your inconvenience and I would like to say thanks to you > and Eric for your assistance! > > Roland > > > > -----Ursprüngliche Nachricht----- > Von: [email protected] > [mailto:[email protected]] Im Auftrag von Sam > Clippinger > Gesendet: Dienstag, 14. Dezember 2010 22:07 > An: spamdyke users > Betreff: Re: [spamdyke-users] Greylisting entries won't update > > You're seeing the error about /var/qmail/spamdyke/conf.s because there > is a line in your configuration file giving that folder as a value for > "config-dir". But that's not what's causing the problem. > > What messages are you seeing in your log file for these rejected > connections? Are they being graylisted forever or rejected for some > other reason? Also, can you enable full logging (with "full-log-dir") > and trigger one of these messages, then post (or privately email) the > log file from that connection? > > Offhand, this looks like something else is going on here -- in a QMT > or LwQ setup I would suggest increasing qmail's memory limit. Have > you checked your filesystem to make sure it's not out of disk space > and/or inodes? Is SELinux enabled? > > -- Sam Clippinger > > On 12/14/10 2:12 PM, Roland Moelle wrote: > _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
