Verify that cron is working

[Teekin]

I see a few posts about cron not working. It’s typical, because cron very often doesn’t work.

This is why I’d like to confirm that it’s working. I have no reason to suspect that it doesn’t work, except because cron very often doesn’t work.

When the /var/www/nextcloud/cron.php file is run, I don’t see any kind of message in any log indicating success. I don’t know what it does internally or how to confirm that it is indeed doing what it’s supposed to be doing. Does the cron.php script leave any kind of evidence that would indicate success?

[rakekniven]

cron is well documented and it is working. See

https://docs.nextcloud.com/server/stable/admin_manual/configuration_server/background_jobs_configuration.html?highlight=cron#cron

See that you have to specify the user to call php cron.

[Teekin]

Perhaps I’m not being clear.

I used that documentation, and I’ve specified the relevant user to indeed call PHP (with a full path, in fact) to the cron script. My problem is not that cron doesn’t work.

I need to verify that it works. My question is: How do I know whether the script is being successfully run or not?

[rakekniven]

Do not know about any result value. See

nextcloud/server/blob/master/cron.php

If don’t get any answer here I would recommend to contact devs on IRC.

[yourcloudasia]

Log in to the web interface as admin and go to:

Settings > Administration/Basic settings > Background jobs?

[MichaIng]

Yeah the cron on OS-side should work very reliable. Never found a reason to doubt that. The web UI admin panel as stated shows a warning if cron didn’t run for more than 30 minutes. To see actual background tasks log, you can set log level to debug (0).

EDIT: And of course you can check the syslog on the server (when using systemd: journalctl) to check the particular cron executions of the webserver user. By default it does not show failures, but one can increase verbosity e.g. via /etc/default/cron, depending on OS.

[Teekin]

@MichaIng

Yeah the cron on OS-side should work very reliable. Never found a reason to doubt that.

If I could only teach my children one thing about Unix from my 20+ years of experience, it would be to never trust cron to do anything right without verifying the expected results.

@MichaIng

The web UI admin panel as stated shows a warning if cron didn’t run for more than 30 minutes.

And that was, in fact, exactly what I needed. According to that, it’s running fine. Thanks a bunch!

[MichaIng]

@Teekin

If I could only teach my children one thing about Unix from my 20+ years of experience, it would be to never trust cron to do anything right without verifying the expected results.

The question is if the issue is with cron or due to insufficient knowledge about how cron works . Of course one needs to take care the way cron executes the scripts within /etc/cron.*/ via run-parts. E.g. files need to be executable and file names must not have endings like .sh. And e.g. on Debian by default failures are not reported to syslog (respectively journald) which can be changed via environment file (e.g. /etc/default/cron). As long as one is aware of this, and of course the service is enabled, cron should do it’s job.

Aside that, when implementing any job or service or whatever that should run non-interactively, one should ALWAYS do a test run to verify the result is as expected, regardless if in case of error the issue is with hardware, software or in front of the machine .

[Teekin]

@MichaIng

The question is if the issue is with cron or due to insufficient knowledge about how cron works .

No, it is not, and has nothing to do with my question. I know how cron works.

@MichaIng

Of course one needs to take care the way cron executes the scripts within /etc/cron.*/ via run-parts . E.g. files need to be executable and file names must not have endings like .sh . And e.g. on Debian by default failures are not reported to syslog (respectively journald) which can be changed via environment file (e.g. /etc/default/cron). As long as one is aware of this, and of course the service is enabled, cron should do it’s job.

Those are a few drops of an ocean of things that can break cron. Only watching out for those things is not even close to being enough to be able to rely on cron. Cron is fantastically and notoriously quick to fail.

@MichaIng

Aside that, when implementing any job or service or whatever that should run non-interactively, one should ALWAYS do a test run to verify the result is as expected, regardless if in case of error the issue is with hardware, software or in front of the machine .

Exactly. That’s why I asked.

Thanks again for your solution.

[MichaIng]

Sorry if it sounded rude, it wasn’t meant to. I ran into several issues as well when using cron, but to make the point clear it was always an issue with how I used it. So the cron system itself was always working 100% reliable as it is meant to. I can only say that for Debian derivatives and their particular implementation but since cron is the most widely used automation system (even more than systemd timers for now I believe) I doubt that doubts about cron itself are helpful or the right direction in that other users should be pointed to. Nothing else is used thus proven reliable that much on that many different Linux derivatives.

If you faced issues I believe they are related to usage and scripts or the underlying OS setup (init system, service states etc). Nextcloud docs give clear steps about how to implement their cron job via crontab and if something fails it is most likely an issue with the Nextcloud instance (database, access etc) and/or PHP but not cron itself. It was in fact like this during my long Nextcloud experience and all user reports about failing cron I remember.

But enough about this now, I think my point is clear and I’m happy to helped verifying working Nextcloud background jobs .