The queue.php file is technically not a cache file, even though it resides (presumably for permissions reasons) in the cache directory.If the concern is that an admin might unknowingly purge queue.php in a "normal" purge, the reverse is also true, where purging the cache in an attempt to solve a serious problem leaves the admin unknowingly with the problem still in the cache.
Maybe the configuration of the server is such that timeout errors aren't written to the error log. Testing with a script that deliberately times out may answer this questionIf the board hit maximum_execution_time, why no logged error?
So that queue lock file was supposed to stop the e-mail notificatons from going out when there is a problem? If I am not mistaken on my site there was a queue lock file generated and the notifications kept going out until Ruler deleted the lock file and renamed the queue file.T0ny wrote:
However, you are entirely correct that phpbb should inform the admin when something goes wrong with the queue system rather than press on regardless sending the same email over and over. As an example, when the script detects that a queue lock file already exists it should notify the admin(s) and then exit without sending any emails. This would give an admin the option of deleting the lock file and allowing email delivery to continue or delete the queue and lock files to avoid multiple emails being sent.
Then perhaps a queue folder with its own "panic purge" is worth considering as a minimally invasive revision suitable for a 3.0.x release...T0ny wrote:The queue.php file is technically not a cache file, even though it resides (presumably for permissions reasons) in the cache directory.
What it's supposed to do can only be answered by the dev team T0ny is suggesting a more appropriate behaviour than what it seems to be exhibiting now.Captain Don wrote:So that queue lock file was supposed to stop the e-mail notificatons from going out when there is a problem?
Code: Select all
<Files *> Order Allow,Deny Deny from All </Files>
IIRC, the cron.php has nothing to do with the cron process on a Unix system, it is the maximum execution time for a PHP script you have to worry about. The only way in which a PHP web application can start processing something is when a client makes a request, AFAIK that's also how the "cron" system in phpBB works; it's simply triggered when someone requests a page.Ruler2112 wrote:I was not aware that there was a maximum execution time defined for cron to run.
I had to do it, didn't I? I couldn't just leave well enough alone! The very day after bragging about how my daemon has never had a problem, I get to work and the lady in charge of e-mail marketing tells me that the e-mails didn't go out. I checked and the daemon wasn't running. In my own defense, the logs clearly indicate that it ran into a bug in the Slackware kernel - not a bug of mine! 'Write daemon watchdog' was added to my whiteboard today.Ruler2112 wrote:the daemon has yet to go down once in 7 months of use.
Never mind. Thanks for the amusing anecdote.Ruler2112 wrote:Not that this has anything even remotely to do with the main topic of this thread
I've read this and other topics on this problem start to finish, and can perhaps provide some clarity for users who are experiencing this problem.
In my case (PHPBB3.0.2 running on a Win Server 2003 box), it was my mis-configuration of the permissions that was to blame.
At first glance, everything seemed right - the "Internet Guest Account" user had "Read & Execute", "List folder contents", "read" and "write" permissions ticked, yet I was still getting the problem of duplicate emails sent to users periodically.
After reading this and other forums, I've realised the vital missing link is the "modify" permission - I hadn't ticked that.
Since doing so, all is well.
It's worth noting I have RDP access (ie, I can Remote Desktop into the server) and thus I am talking about the actual Windows permissions module. I have no idea about Plesk or any of the other server management tools mentioned.