Cron always has output

I have been using cron on a hosted server (adding the link to cron.php in the webmanager of the hosting account as a cron job).
The server is setup to send an email of the cron job has an error (essentially any output).

Expected behaviour

I’m expecting the cron job to not have any output when there is no error.

Actual behaviour

The cron job always throws out a “Please use ./occ system:cron”

ownCloud version: 10.4.1.3

Since the message about using ./occ does not seem to constitute an error, can this be removed from the cron.php?

If you still want to run cron.php, you should try to switch from Cron to Webcron in Settings->general, assumig you hoster supports it.

1 Like

Thanks. I think what I’m using is Webcron, set to execute ./cron.php every 30 minutes. But the line “echo ‘Please use ./occ system:cron’ . PHP_EOL;” seems to be coded there to run every time, triggering an output and an alert email…
From the code and the documentation I find it hard to figure out what cron.php actually does, so I’m wondering if I can just remove that line…?

For Webcron, you have to make a http(s)-request with the fully qualified URL of cron.php, not just execute ./cron.php. None of my instances produces output by cron.

1 Like

See the Release Notes:

Instead of executing cron.php (e.g., /usr/bin/php -f /path/to/your/owncloud/cron.php ), cron should use occ system:cron (e.g., sudo -u www-data php occ system:cron ).

This is why the message appears: you are using the wrong syntax. Fix your cron call and the message will disappear.

1 Like

Thanks. Unfortunately I am on a shared server, so can’t modify the cron files directly (or do sudo I would think…). I can only point the cron to a specific file to execute.

Maybe my only solution then would be to write a script that does a wget to the webcron URL and have that one executed by cron…?

Just an update, this works. Almost…
Except I now get an email every 15 minutes “Cron job output: []”.
I guess I might be able to fix that somehow in the shell script, but I could also just send the output to dev/null instead, because I’m not expecting any meaningful feedback from that anyway.
Thanks for the help.

Yes, redirecting to /dev/null helps on that.

1 Like

Actually wget -q did the trick. Thanks.

2 Likes