I've noticed that the Daily statistics clear out at midnight on our server, however it continues to log emails after midnight to yesterdays graph... Then around 1AM, the daily statistics will start counting up again. I'm assuming this is just a weird time issue, but just wanted to point it out.
Running Plesk 9.2.2 on a Red Hat 64Bit Box....
Thanks again for an AMAZING product!
Logging Anomaly
Re: Logging Anomaly
We're glad to here you are enjoying our product!
As to the logging - the mechanisms for log 'rotation' are built in to the system itself as opposed to running through traditional cron systems. The 'daily' statistic counts should be based on items logged to the log.x file in /var/log/magicspam where 'x' represents the day of the week.
This calculation is done via a simple call to 'localtime' which determines the local time as known by the server itself. For the interface side, the calculation is done via a simple call to 'date' which should return the current date based on the system default timezone. In the case of our software, we rely on the server time zone as specified either via TZ, PHP configuration explicit timezone, or (dependent on security settings) the root system time zone.
This can of course lead to some discrepancies if, for example, the server time zone is set to a different time zone than that of the client side web browser. Further discrepancies are possible if the PHP timezone has been set to a different one than the system timezone. It sounds, based on what you are reporting, that there is a remote possibility of the latter being the case as we have not been able to replicate this condition in testing.
Please do let us know if there is any further information related to this for our developers to review.
Thanks!
As to the logging - the mechanisms for log 'rotation' are built in to the system itself as opposed to running through traditional cron systems. The 'daily' statistic counts should be based on items logged to the log.x file in /var/log/magicspam where 'x' represents the day of the week.
This calculation is done via a simple call to 'localtime' which determines the local time as known by the server itself. For the interface side, the calculation is done via a simple call to 'date' which should return the current date based on the system default timezone. In the case of our software, we rely on the server time zone as specified either via TZ, PHP configuration explicit timezone, or (dependent on security settings) the root system time zone.
This can of course lead to some discrepancies if, for example, the server time zone is set to a different time zone than that of the client side web browser. Further discrepancies are possible if the PHP timezone has been set to a different one than the system timezone. It sounds, based on what you are reporting, that there is a remote possibility of the latter being the case as we have not been able to replicate this condition in testing.
Please do let us know if there is any further information related to this for our developers to review.
Thanks!
-- MagicSpam Support Team --
Who is online
Users browsing this forum: No registered users and 20 guests