Cron does not terminate and need a lot of ram

I don’t know what you mean by normal.
I have installed another php 7.0 because of a relatively old application. With the path information I want to prevent that nextcloud is running with it.

i just followed the instructions, there are also 5 minutes

Yes. But if you use cron every 5 minutes it does not work because it runs multiple because of the long time of execution.

But perhaps it is a problem with your old operation system. With Ubuntu 20.04 LTS or Debian Buster 10 you get a newer php-version than php 7.0 . Which operation system is installed?

php 7.0 and Ubuntu:
This is Ubuntu 16.04 LTS and very old.

php 7.0 and Debian:
This is Debian Stretch and also a little bit old.

Both systems are supported but perhaps not a good solution for nextcloud.
You must use for running nextcloud a php-version from another source than the normal distribution.
uses php 7.2

Perhaps you can dist-upgrade to Ubuntu 20.04 LTS

In your database you have a table oc_jobs or jobs. This is a list of all jobs executed during a cronjob. There is even a column with execution duration.

With this list you can perhaps crosscheck with the apps installed if everything is working as supposed. From you apps, there is stuff like imageconverter which could create a lot of load on the system.

That is great, and how long took the run?
The 5 minute cycle was changed recently, before it was about 15 minutes. Drawback of longer cycles are that notification mails will be sent with a larger delay. Normally the cronjob creates a lockfile, so there shouldn’t be any overlap (the new process makes sure the old one finished).
if everything takes long, you might take a look into your database caching settings.

If you have redis, I’d use it as file-locking cache as well that takes away load from the normal database.

1 Like

since I have installed php 7.4, should this not be a problem for the time I think?

this execution duration is given in seconds? then it would be 86 seconds in total

so according to the github page of the imageconverter this is only done by hand

we have some iphone users, so I installed this.

I have now done it 3 times by hand and it takes maximum 2 minutes.

thanks for the tip with the redis filelock, have it set up now

since the changeover the cronjob also takes less than one minute

Which task is taking most of the time?

With the reduction, did the memory consumption decrease as well?

i can’t say yet, because the cron seems to hang only 2 times a day

1 Like

then it’s just a matter of time. Don’t forget to dump the jobs-table so you can track this issue. I’m not sure about the logs (perhaps needs to increase log level), perhaps there it’s mentioned which job is started, so in case of a crash you just need to check which one was started last.

These are the 3 biggest jobs, then come 10 or so with an execution time of 1

OCA\Activity\BackgroundJob\ExpireActivities 	16
OCA\Files_Versions\BackgroundJob\ExpireVersions 	15
OCA\Files\BackgroundJob\ScanFiles 	15

so I can just empty the oc_jobs?

I am having this exact problem, I have ensured the php config has been done correctly. This has only started after I have moved to nextcloud 19, could this be an issue with php7.4 ?

Nextcloud version: 19.0.0
Operating system and version: 20.04 LTS
Apache or nginx version: nginx/1.18.0 (fpm-fcgi)
Database: mysql 10.1.44
PHP version: 7.4.8

No just backup the table after each run to see how long it took. Don’t empty the table, it’s needed.

1 Like

so i couldn’t see any difference except for the new timestamps, i started an excerpt here.

The problem is that the cron gets stuck at night and I would rather sleep than wait for the cron :confused:

but it always seems to get stuck at the same time; once at 23:30 and at 5:30(CEST)

but I have to agree @Chris_Aldred , I’ve only had this problem since Nextcloud 19
Whereby only on the Ubuntu system, I manage another one on Debian and there it does not occur, the configuration is almost identical

You can run a cron afterwards to query the values from the database. Also the logs might give hints :wink:

I am not sure if all the jobs do something at each run. Like this, I’d think that these are some daily routines, not sure like for the trashbin and stuff like that. But I don’t know enough to tell you which has changed for NC 19. Perhaps change the run time a bit, perhaps on your ubuntu system it collides with a different cronjob.

Ok I have now set up the whole system on a brand new Debian server and migrated the data. But I still have the problem somehow.
I really don’t know what it is

I runinng into issues with cron too and having a hard time to figure it out.
I added my comment to another thread and thought linking would be helpful

I am really struggling, so I link this thread here too.

Same problem here. :sweat: cron.php takes up to 90% of 4GB RAM und 30% of CPU for aprox. 30 secs.

Following tflidd’s advice:

select * from oc_jobs ORDER BY execution_duration DeSC;
| id   | class                                                           | argument                                                                 | last_run   | last_checked | reserved_at | execution_duration |
|   24 | OCA\UpdateNotification\Notification\BackgroundJob               | null                                                                     | 1617940802 |   1618023302 |           0 |                 27 |
|    1 | OCA\NextcloudAnnouncements\Cron\Crawler                         | null                                                                     | 1618001701 |   1618023302 |           0 |                  1 |
|   44 | OCA\Passwords\Cron\CheckPasswordsJob                            | null                                                                     | 1617940829 |   1618023302 |           0 |                  1 |
|   48 | OCA\Passwords\Cron\BackupJob                                    | null                                                                     | 1617940830 |   1618023302 |           0 |                  1 |
|   68 | OCA\Deck\Cron\ScheduledNotifications                            | null                                                                     | 1618023302 |   1618023302 |           0 |                  0 |
|   30 | OCA\Talk\BackgroundJob\ExpireSignalingMessage                   | null                                                                     | 1618023002 |   1618023302 |           0 |                  0 |
|   31 | OCA\Talk\BackgroundJob\RemoveEmptyRooms                         | null                                                                     | 1618023002 |   1618023302 |           0 |                  0 |

Except for OCA\UpdateNotification\Notification\BackgroundJob everything fine.

sudo -u www-data php /var/www/vhosts/XXX/public/occ background:queue:status -vvv:
takes long, then “Getötet” - probably “Killed” in English :slight_smile:

Same happens with:
sudo -u www-data php /var/www/vhosts/XXX/public/occ background:queue:status -vvv

Amy ideas? Thanks so much indeed.

Hm… Sounds like [NC 21] OCC Update error: allowed memory size exhausted · Issue #25742 · nextcloud/server · GitHub

1 Like

szaimen, you were right! Following this advice, by adding:

'debug' => 'false', // note: string not bool
'loglevel' => 2,

to config/config.php solved the problem.