Hello,
since upgrade from NC 25.0.3 to newest 25.0.4 yesterday I am getting Error messages via mail from cron.php
Config file has leading content, please remove everything before "<?php" in config.php
Fatal error: Uncaught Error: Call to a member function getLogger() on null in /is/htdocs/wp13723049_KAO38NZZ6O/www/Cloud/cron.php:190
Stack trace: #0 {main}
thrown in /is/htdocs/wp13723049_KAO38NZZ6O/www/Cloud/cron.php on line 190
I tripple checked my config.php and there is nothing before the mentioned <php
Then I created a new config.php by writing the first line via hands and copying the rest from the old file.
Same error.
I have the same issue running 25.0.5. This was a new install of 25.0.4 (from Softaculous through CPanel on a Linux host) but quickly upgraded, so I cannot verify whether it was happening for me on 25.0.4 or earlier versions. From viewing in vi, there are NO leading characters in $WEBROOT/config/config.php.
I am running PHP 7.4.33.
Running the cron.php script manually from a terminal from the NextCloud directory with:
php -d memory_limit=512M ./cron.php
WORKS and gives no errors. However, running through cron (with an absolute instead of relative path) results in an emailed error every time:
Config file has leading content, please remove everything before "<?php" in config.php
After running manually, the GUI reports that background jobs are being run. After letting it run through cron, in addition to the error report, the GUI complains that background tasks are NOT being run. At the moment, this site is just being used for testing, but I am hoping to take it live within the week…
Hmm… experimentally, I used the PHP Selector to change the domain to php v.8.1.16.
cron.php still runs correctly from the command line and still fails from within cron. I added a cron job of “php -v” and it still reports v.7.4.33. So cron is still using the system native php no matter what the selector says (which makes some sense). This means it may be ignoring other settings.
I am thinking that the difference in behavior between the command line and cron pretty much guarantees that the error is a php environment issue— something present in my command line run but not picked up by cron’s environment. So far, I cannot see what this is; perhaps the behavior difference might give the OP an idea.
The cron environment seems to be calling /usr/bin/php. They are precisely the same php version, but there are significant differences between the resulting php environments when I dump them to a file, enough so that pinning it down to just one setting would be very difficult. I think this proves, however, that the apparently spurious error can be caused by the calling php environment.
