Hi,
I installed magicspam-plesk-1.0.4-4-rhel4-centos4-83.i386.rpm on my CentOS 4 server yesterday. I am running 8.3.0 RedHat el4 83080131.20 of Plesk.
The log files are being created in /var/log/magicspam/
~]# ls -la /var/log/magicspam/
total 3596
drwxr-xr-x 2 qmaild nofiles 4096 Aug 28 00:00 .
drwxr-xr-x 15 root root 4096 Aug 27 11:50 ..
-rw-r--r-- 1 qmaild nofiles 2984468 Aug 27 23:59 log.4
-rw-r--r-- 1 qmaild nofiles 672945 Aug 28 07:31 log.5
The /usr/share/magicspam/bin/magicspam-plesk-updater script is running every 6 hours as per the cron.
The problem is however in the GUI.
When I log into Plesk, Click on Modules and then on MagicSpam the 'Statistics for Today' reports:
Total number of RCPT's received 0
Number of RCPT's rejected as spam 0
Number of RCPT's exempt from spam checks 0
And the 'Statistics for the month of August' reports:
No statistics found
How do I get MagicSpam to update the statistics?
Statistics does not update
Re: Statistics does not update
Could you please confirm that you are running 32bit RHEL4? It appears that one of the statistics files is missing which is why the data is not displaying in the interface at all.
Thanks!
Thanks!
Re: Statistics does not update
Yes, this is an installation on a 32-bit system.
How do I fix the the missing file?
How do I fix the the missing file?
Re: Statistics does not update
I have tracked down the problem with the statistics not updating by doing a lot of debugging on your code.
The /var/qmail/plugins/magicspam-plesk program creates the statistics file in the /tmp directory using a /tmp/msXXXXX file name.
Later on the /var/qmail/plugins/magicspam-plesk program uses the rename() function to move the /tmp/msXXXX file to the /var/log/magicspam/.counter.dat.XX file, where XX = the 2 digit month number.
The problem occurs with the rename() function throwing an uncaught error, EXDEV (Invalid cross-device link) because, in our specific case, the /tmp and the / mount points are on 2 different file systems.
If /tmp and / were on the same file system, then the error would not occur. I suspect that this is the way that your test system is setup.
I have a /tmp directory with a tens of thousands of msXXXXX files in it, since the rename() function is failing the whole time.
There are 2 solutions to the problem as I see it:
1. Allow the client to specify the temporary directory to use in a config file. This way, you can for instance create a temporary directory for MagicSpam as say: /var/log/magicspam/tmp which will be on the same file system as /var/log/magicspam.
2. The second solution is to move away from the rename() function to a copy() and unlink() solution, which works across file systems. You may then keep the default as /tmp. The drawback of this solution is that copy()+unlink() is a lot slower than rename() and on a busy mail server the impact will definitely be noticeable.
During the debugging process I have also stumbled across another bug, although it is insignificant, it may create problems for you with support in future.
The /var/qmail/plugins/magicspam-plesk reports itself to be version: MagicSpam 1.0.4-2, but the RPM that I used to install MagicSpam was: /usr/local/src/magicspam-plesk-1.0.4-4-rhel4-centos4-83.i386.rpm
There is thus a discrepancy in the versions: 1.0.4-2 VS 1.0.4-4.
I hope you will be able to provide me with a solution.
The /var/qmail/plugins/magicspam-plesk program creates the statistics file in the /tmp directory using a /tmp/msXXXXX file name.
Later on the /var/qmail/plugins/magicspam-plesk program uses the rename() function to move the /tmp/msXXXX file to the /var/log/magicspam/.counter.dat.XX file, where XX = the 2 digit month number.
The problem occurs with the rename() function throwing an uncaught error, EXDEV (Invalid cross-device link) because, in our specific case, the /tmp and the / mount points are on 2 different file systems.
If /tmp and / were on the same file system, then the error would not occur. I suspect that this is the way that your test system is setup.
I have a /tmp directory with a tens of thousands of msXXXXX files in it, since the rename() function is failing the whole time.
There are 2 solutions to the problem as I see it:
1. Allow the client to specify the temporary directory to use in a config file. This way, you can for instance create a temporary directory for MagicSpam as say: /var/log/magicspam/tmp which will be on the same file system as /var/log/magicspam.
2. The second solution is to move away from the rename() function to a copy() and unlink() solution, which works across file systems. You may then keep the default as /tmp. The drawback of this solution is that copy()+unlink() is a lot slower than rename() and on a busy mail server the impact will definitely be noticeable.
During the debugging process I have also stumbled across another bug, although it is insignificant, it may create problems for you with support in future.
The /var/qmail/plugins/magicspam-plesk reports itself to be version: MagicSpam 1.0.4-2, but the RPM that I used to install MagicSpam was: /usr/local/src/magicspam-plesk-1.0.4-4-rhel4-centos4-83.i386.rpm
There is thus a discrepancy in the versions: 1.0.4-2 VS 1.0.4-4.
I hope you will be able to provide me with a solution.
Re: Statistics does not update
Thank you very much for your detailed tracking of the issue in question. This information has been forwarded to our development team and we will let you know as soon as we have an updated package available to resolve this. (Early estimates: next 2 days)
-- MagicSpam Support Team --
Re: Statistics does not update
We have now posted a fresh release of packages for MagicSpam (version 1.0.4-4.1) which addresses the issue you have noted, along with several other backend improvements and fixes. The new package can be found at:
http://download.magicspam.com
Please let us know if you have any other issues after upgrading to this release.
Thanks!
http://download.magicspam.com
Please let us know if you have any other issues after upgrading to this release.
Thanks!
-- MagicSpam Support Team --
Re: Statistics does not update
Thank you.
I have installed the update and it seems everything is now working.
I will continue monitoring MagicSpam and will return with new problems.
I have installed the update and it seems everything is now working.
I will continue monitoring MagicSpam and will return with new problems.
Who is online
Users browsing this forum: Google [Bot] and 31 guests