Cron 500 Errors

[KungFuJosh]

Hi,

I was seeing different cron related 500 errors in the browser console.

Some of the errors included:

cron.task.core.tidy_database
cron.task.core.tidy_sessions
cron.task.core.tidy_plupload

etc... depending on what page I was on.

One of those errors referred to a line of code:

Code: Select all

<img src="/cron/cron.task.core.tidy_database" width="1" height="1" alt="cron" /></div>

So I copied the /phpbb/cron/ folder to my root directory, and now all the errors stopped.

Is this a bug in the latest version of phpbb? Is something else causing this? There's no reference to any of this in my custom theme or other files. Only stock core phpbb files reference any of this on my site.

Thanks,
Josh

PS. Here's an example of an error:

error.png (4.78 KiB) Viewed 2201 times

[rxu]

What pages exactly did produce these errors? Also, you can try looking into webserver's error log for error details.

[Scanialady]

Maybe the error has the same cause as with my test update.

http://area51.phpbb.com/phpBB/viewtopic ... 16#p333116

To add

Options -MultiViews

to my .htaccess (root) solved it for me. https://stackoverflow.com/questions/254 ... n-htaccess

[EA117]

To add Options -MultiViews to my .htaccess (root) solved it for me.

Nice, I had forgotten about that one after it was resolved. If the phpBB 3.3.0 .htaccess file was used, the MultiViews statement should already be there; as was addressed in 3.3.0-RC1 time frame.

But if the phpBB 3.3.0 .htaccess wasn't used or wasn't merged, that could indeed be the cause of such an error.

Code: Select all

<img src="/cron/cron.task.core.tidy_database" width="1" height="1" alt="cron" /></div>

So I copied the /phpbb/cron/ folder to my root directory, and now all the errors stopped.

There is definitely not supposed to be a /cron folder at the root of the site. The cron URLs either get written as "cron.php?cron_type=cron.task.core.tidy_database", or as a route through app.php, written as "/cron/cron.task.core.tidy_database".

By making the /cron folder actually exist, you're now stopping the app.php redirect from happening for the "/cron/cron.task.core.tidy_database" URL. But that was not the issue, and definitely is not the solution except for suppressing the symptom.

As rxu already asked, the PHP error log may hold the key. Either it might show the error Scanialady is referencing, or it might show something more unexpected and exotic. (And hopefully a stack trace for how we reached that point.)

Note this guy actually had his host disable his cron.php file without his knowledge, so maybe also check whether your cron.php even contains valid content / has the phpBB 3.3.0 cron.php file content.

[KungFuJosh]

Thanks for the tip, adding -MultiViews to htaccess fixed it. I'm not using the 3.3 htaccess, mine has a lot of custom code and I haven't looked through the new one yet.

Anything else essential the old one is missing?

Thanks,
Josh

[EA117]

Disabling multiviews was the only .htaccess file change. Indeed it is common to just keep the .htaccess during updates, since the .htaccess file tends to not change very much or very often.

[KungFuJosh]

I've had that line in my htaccess for a while, but I'm still getting some weird cron related errors:

Code: Select all

PHP Fatal error:  Uncaught Symfony\Component\Routing\Exception\MissingMandatoryParametersException: Some mandatory parameters are missing ("cron_type") to generate a URL for route "phpbb_cron_run". in /public_html/vendor/symfony/routing/Generator/UrlGenerator.php:136

[EA117]

Code: Select all

PHP Fatal error:  Uncaught Symfony\Component\Routing\Exception\MissingMandatoryParametersException: Some mandatory parameters are missing ("cron_type") to generate a URL for route "phpbb_cron_run". in /public_html/vendor/symfony/routing/Generator/UrlGenerator.php:136

That looks like the kind of error I might expect to see if someone or something invoked the /cron/ route on my site without actually specifying any additional path indicating what type of cron needed to run. Such as the /cron/cron.task.core.tidy_database path from your earlier examples.

The first thing that would make me want to look at is the normal web server access log, to try and correlate whether there really is someone hitting my site with a GET request for just http://mysite.com/cron/ instead of http://mysite.com/cron/cron_type, and if so, does it appear to be part of a page load (a bunch of GET requests all coming at the same time) or just someone hitting that exact path on its own for some reason.

phpBB itself isn't expecting to generate "a /cron/ URL without a specific cron type specified in the path", because a specific cron type being found as "ready to run" is why phpBB is generating the /cron/ URL at all in the first place. But it's certainly possible that some kind of mis-written .htaccess rule could be causing the redirect to strip off the remaining path, or similar.

[KungFuJosh]

But it's certainly possible that some kind of mis-written .htaccess rule could be causing the redirect to strip off the remaining path, or similar.

Either they all work or don't. Htaccess isn't going to unintentionally block only one type of cron request and let the rest work properly.

[EA117]

Either they all work or don't. Htaccess isn't going to unintentionally block only one type of cron request and let the rest work properly.

Logical, but I'm not sure completely matches the reality. A cron URL could be in the form of http://mysite.com/cron/cron_type or in the form of http://mysite.com/cron.php?cron_type=cron_type. A rule unintentionally spoiling one doesn't necessarily spoil the other. The premise also begs the question, are any of the cron URLs working properly?

If it were my own site, a good next step still seems like a review of the HTTPD log, to see if any of the GET requests do actually specify a cron URL without a cron_type specified. To "divide and conquer" whether this condition of "no cron type was specified" is happening "outside" the web server, e.g. a page rendered with a malformed URL like that, or someone/something hitting the server with that URL on their own. Versus "there are no such URL requests arriving without a cron_type specified", which would mean it's getting stripped at the .htaccess or deeper level after the request has already arrived at the server.

Perhaps also be sure to look only at more recent log entries, just as just March and later. Since back when there were conditions such as "I've copied the /phpbb/cron/ folder to the root of the phpBB site", cron URLs could have been failing for an entirely different set of reasons at that point. Oh, I guess that's something never explicitly confirmed: You confirmed adding MultiViews, but you did also remove the /cron folder created at the root of the phpBB site? Only cron.php expected to exist at the root of the site; no actual /cron folder.

[KungFuJosh]

Perhaps also be sure to look only at more recent log entries, just as just March and later. Since back when there were conditions such as "I've copied the /phpbb/cron/ folder to the root of the phpBB site", cron URLs could have been failing for an entirely different set of reasons at that point. Oh, I guess that's something never explicitly confirmed: You confirmed adding MultiViews, but you did also remove the /cron folder created at the root of the phpBB site? Only cron.php expected to exist at the root of the site; no actual /cron folder.

I did delete the folder I added, and cron was working fine. No errors on my browser console now, but before MultiViews I was getting errors on basically every page (in the browser console).

The errors I'm getting now appear to be from a url generator:

Code: Select all

Stack trace:
#0 /public_html/cache/production/url_generator.php(52): Symfony\Component\Routing\Generator\UrlGenerator->doGenerate(Array, Array, Array, Array, Array, 'phpbb_cron_run', 1, Array, Array)
#1 /public_html/phpbb/routing/router.php(168): phpbb_url_generator->generate('phpbb_cron_run', Array, 1)
#2 /public_html/phpbb/routing/helper.php(148): phpbb\routing\router->generate('phpbb_cron_run', Array, 1)
#3 /public_html/phpbb/controller/helper.php(114): phpbb\routing\helper->route('phpbb_cron_run', Array, false, false, 1)
#4 /public_html/cron.php(34): phpbb\controller\helper->route('phpbb_cron_run', Array, false)
#5 {main}

That error is repeating in my error_log file. Over and over for 8.5megs since the last time I deleted it.

Thanks,
Josh

[KungFuJosh]

Anybody? No ideas?

[EA117]

The errors I'm getting now appear to be from a url generator:

Code: Select all

Stack trace:
#0 /public_html/cache/production/url_generator.php(52): Symfony\Component\Routing\Generator\UrlGenerator->doGenerate(Array, Array, Array, Array, Array, 'phpbb_cron_run', 1, Array, Array)
#1 /public_html/phpbb/routing/router.php(168): phpbb_url_generator->generate('phpbb_cron_run', Array, 1)
#2 /public_html/phpbb/routing/helper.php(148): phpbb\routing\router->generate('phpbb_cron_run', Array, 1)
#3 /public_html/phpbb/controller/helper.php(114): phpbb\routing\helper->route('phpbb_cron_run', Array, false, false, 1)
#4 /public_html/cron.php(34): phpbb\controller\helper->route('phpbb_cron_run', Array, false)
#5 {main}

Can you look at that again and post what the actual error is in those cases? The above text shows the stack trace for when an error occurred, but omits what the actual error was (which gets reported right before the stack trace). e.g. "Invalid array index", "call to undefined function", "syntax error", etc. Just capture the entire log entry, everything from the time stamp of when it occurred through to the end of the stack trace.

I think I stopped replying because I was short on time, and didn't want to repeat for a third time "check the HTTPD access logs" to correlate whether someone is actually making a cron request without a cron type specified, versus whether all requests have a cron type specified when they arrive at the server (and the cron type is somehow subsequently being lost).

But looking at at least the stack trace of the error you're continuing to see, a warning or error stopping the execution right at that point actually might be consistent with phpBB generating a cron URL for a page which didn't have a cron type specified. Meaning if phpBB is hitting some PHP execution issue when trying to generate the cron URL as suggested by this stack trace, maybe the cron URL being generated for a page ends up without its cron type specified.

So I would say perhaps both items could be important clues: What is the actual error text that proceeded this stack trace. And does the HTTPD access log confirm that when this issue occurs, the cron URL GET request seen by the server didn't have any cron type parameter associated with it.


e.g. The difference between seeing inbound GET requests logged that look like:

Code: Select all

[23/Nov/2019:14:44:41 -0600] "GET /phpbb/cron.php?cron_type=cron.task.core.tidy_sessions&sid=a094d06af2cb7a23a648ffec7608d911 HTTP/1.1" 200 43 "http://127.0.0.1/phpbb/index.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"
[28/Mar/2020:10:20:13 -0500] "GET /phpbb/cron/cron.task.core.tidy_sessions?sid=a372bedc66c902402bf9a29df83e33cd HTTP/1.1" 200 43 "http://localhost/phpbb/mcp.php?i=main&mode=front&sid=a372bedc66c902402bf9a29df83e33cd" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36"

...in which a cron type was specified (cron.task.core.tidy_sessions in those cases). Versus whether the HTTPD access log shows that when the issue was reported, the actual inbound GET request did not have a cron type specified, maybe similar to:

Code: Select all

[23/Nov/2019:14:44:41 -0600] "GET /phpbb/cron.php?cron_type=&sid=a094d06af2cb7a23a648ffec7608d911 HTTP/1.1" 200 43 "http://127.0.0.1/phpbb/index.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"
[28/Mar/2020:10:20:13 -0500] "GET /phpbb/cron?sid=a372bedc66c902402bf9a29df83e33cd HTTP/1.1" 200 43 "http://localhost/phpbb/mcp.php?i=main&mode=front&sid=a372bedc66c902402bf9a29df83e33cd" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36"

As described in the earlier posts, if you're not seeing cron GET requests arriving with the cron type parameter already missing, then the implication is that the cron type parameter is being lost or dropped somehow after the request already arrived. e.g. An .htaccess rewrite which isn't expecting to maintain parameters.

[KungFuJosh]

Here's the errors with the traces:

Code: Select all

[17-Mar-2020 19:21:53 America/New_York] PHP Fatal error:  Uncaught Symfony\Component\Routing\Exception\MissingMandatoryParametersException: Some mandatory parameters are missing ("cron_type") to generate a URL for route "phpbb_cron_run". in /public_html/vendor/symfony/routing/Generator/UrlGenerator.php:136
Stack trace:
#0 /public_html/cache/production/url_generator.php(52): Symfony\Component\Routing\Generator\UrlGenerator->doGenerate(Array, Array, Array, Array, Array, 'phpbb_cron_run', 1, Array, Array)
#1 /public_html/phpbb/routing/router.php(168): phpbb_url_generator->generate('phpbb_cron_run', Array, 1)
#2 /public_html/phpbb/routing/helper.php(148): phpbb\routing\router->generate('phpbb_cron_run', Array, 1)
#3 /public_html/phpbb/controller/helper.php(114): phpbb\routing\helper->route('phpbb_cron_run', Array, false, false, 1)
#4 /public_html/cron.php(34): phpbb\controller\helper->route('phpbb_cron_run', Array, false)
#5 {main}
  thrown in /public_html/vendor/symfony/routing/Generator/UrlGenerator.php on line 136
[17-Mar-2020 19:21:53 America/New_York] PHP Fatal error:  Uncaught Symfony\Component\Routing\Exception\MissingMandatoryParametersException: Some mandatory parameters are missing ("cron_type") to generate a URL for route "phpbb_cron_run". in /public_html/vendor/symfony/routing/Generator/UrlGenerator.php:136
Stack trace:
#0 /public_html/cache/production/url_generator.php(52): Symfony\Component\Routing\Generator\UrlGenerator->doGenerate(Array, Array, Array, Array, Array, 'phpbb_cron_run', 1, Array, Array)
#1 /public_html/phpbb/routing/router.php(168): phpbb_url_generator->generate('phpbb_cron_run', Array, 1)
#2 /public_html/phpbb/routing/helper.php(148): phpbb\routing\router->generate('phpbb_cron_run', Array, 1)
#3 /public_html/phpbb/controller/helper.php(114): phpbb\routing\helper->route('phpbb_cron_run', Array, false, false, 1)
#4 /public_html/cron.php(34): phpbb\controller\helper->route('phpbb_cron_run', Array, false)
#5 {main}
  thrown in /public_html/vendor/symfony/routing/Generator/UrlGenerator.php on line 136

Thanks,
Josh

[EA117]

Here's the errors with the traces:

Thanks. So that's still the same error cited earlier (without a stack trace), and now you have the complete stack trace for how PHP execution reached that that error.

This stack trace is reporting an issue occurring on "an inbound cron GET request." i.e. a rendered phpBB page which included a URL for cron.php?cron_type=xxxx or /cron/xxxx, and this is the GET request initiated by that URL. So this error & call stack are really "the symptom", and are occurring "because" the inbound cron request did not include a cron type.

What we still don't know is "whether" the cron type was actually missing on the inbound GET request received over HTTP, versus whether the cron type parameter or portion of the URL was stripped off the request after the web server received it. So it still seems like we're at the same point of needing to look at the HTTPD access log, to correlate and analyze the inbound cron GET request that was being received by the web server at the time these errors are logged.

Because either you're going to see that the HTTPD access log shows a fully-formed cron request (either cron.php?cron_type=xxxx or /cron/xxxx like in the examples shown earlier), which would mean that even though the URL contained a cron type parameter, it was stripped off by .htaccess or something else after the GET request was received. Or you're going to see that the HTTPD access log shows the cron type parameter was already missing on the GET request, which would mean either something went wrong when phpBB was generating the cron URL, or means that someone is making these type-less queries to your web server for some other reason.

What the next investigation step is depends on which of those conditions you find to be true when analyzing the current HTTPD access log entries that occurred around the time of each error.