As there is no video on YouTube to set the cron job and other administration setting errors in NextCloud mainly running on the CasaOS setup. Also, CasaOS is simple to use for newbies like me. It will be a great help if you can make a video specifically on that.
This has been added to BigBearCasaOS. I made a video for it:
I did not see any mention of cron in the video. Your tutorials have been great, but my CPU is pegged at 99% due to the cron container, and I’m trying to figure out how to fix that.
Can you look at the logs on the cron container?
How to install Dozzle on CasaOS using BigBearCasaOS
Wow, thanks for the speedy reply! Yes, I can see the logs under the cron container but I don’t see anything there that jumps out. However, I poked around a bit after making my post, and noticed that the CPU usage was unlimited, so I chopped that down to half a gig and re-loaded. That’s not RAM, but everything seems normal for now. But could be something that builds up over time, or kicks in after some particular cron execution. I’m familiar with cron and crontab in a Linux environment, but not sure what it’s doing here, in a container with Nextcloud. Probably just need to figure out where to go to read up on that. There is no “cron” (or much else in terms of /bins) in the container, and I thought looking at cron.php might be illuminating, but not to me.
Would it break anything if I just deleted the bigbear cron container? I keep having to restart nextcloud b/c it’s pegging my CPU at 99% routinely. I figure I can always go back and re-create it later if I want cron jobs running on the nextcloud install. I’d export the compose file but that doesn’t seem to do anything for the cron container (works fine for the actual nextcloud container). I also wouldn’t mind being surgical and actually fixing whatever is not working, but I haven’t really figured out what to look for. Thanks.
Is Nextcloud a fresh install with nothing in it, and it’s still using 100% at times on the cron container?
Yes it is a fresh install of nextcloud. As for “nothing on it,” I have installed just a handful of apps, but the CPU usage was the same before I’d installed anything. I mostly just use Nextcloud for the files app, behind a Cloudflare tunnel.
EDIT: I’m happy to provide add’l log data. These are the things I’ve tried, and obstacles to me figuring this out myself (although I suspect the problem is going to boil down to something in cron.php, which I haven’t modified).
-
“docker logs big-bear-nextcloud-cron-1” seems to just provide statements of execution, with no timestamp, plus the occasional entry of “process already running” (possibly interesting).
-
The formatting of nextcloud.log is a hot mess, at least compared to other /var/log type entries I’m used to. Might be something there, though. I grepped for cron.php and def. got some returns.
-
The “view logs” function built into the CasaOS Settings menu keeps scrolling off-screen, although it is formatted nicely. Perhaps I just need to learn how to use it?
EDIT: Pretty clearly it’s php-gone-wild (apologies for the formatting):
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
201459 www-data 20 0 172128 66824 28344 R 100.0 1.7 476:35.75 php
194842 www-data 20 0 168048 63816 28344 R 98.7 1.6 496:30.98 php
204904 www-data 20 0 174320 67956 28344 R 97.7 1.7 466:42.92 php
198167 www-data 20 0 174320 67776 28344 R 97.4 1.7 486:41.05 php
pi4# ps -elf | grep 201459
4 R www-data 201459 194068 97 80 0 - 43032 - Jul17 ? 07:56:59 php -f /var/www/html/cron.php
0 S root 363079 359393 0 80 0 - 1477 pipe_r 06:31 pts/0 00:00:00 grep 201459
pi4# ps -elf | grep 194842
4 R www-data 194842 194068 98 80 0 - 42012 - Jul17 ? 08:17:08 php -f /var/www/html/cron.php
0 S root 363170 359393 0 80 0 - 1477 pipe_r 06:32 pts/0 00:00:00 grep 194842
pi4# ps -elf | grep 204904
4 R www-data 204904 194068 97 80 0 - 43580 - Jul17 ? 07:47:32 php -f /var/www/html/cron.php
0 S root 363245 359393 0 80 0 - 1477 pipe_r 06:32 pts/0 00:00:00 grep 204904
pi4# ps -elf | grep 198167
4 R www-data 198167 194068 98 80 0 - 43580 - Jul17 ? 08:07:47 php -f /var/www/html/cron.php
0 S root 363343 359393 0 80 0 - 1477 pipe_r 06:32 pts/0 00:00:00 grep 198167
So I’m not sure what was in it, because I copied over it and blew it away, but I think there was something non-standard in cron.php that I tweaked on and then forgot about. Because I was poking around and saw a cron.php.org (which is how I typically name original files). I copied that back over to cron.php, restarted nextcloud, and it’s been running smooth for a couple of hours and only one php process spawned. I just didn’t want you to waste any more of your time. You’ve got yourself another subscriber, though. Thanks.
So it was what I thought you edited a file? Is it still running good? I was trying to reproduce it on my end and haven’t been able to.
Yup, still running smooth. I apologize for wasting your time. FWIW, I did send you a small “thank you” via Youtube.
Oh, no worries at all! You had an issue, and I was just trying to see if I could reproduce it. I’m really glad you got it up and running, and I appreciate the support!
1 Like
Welp, it happened again! AFAIK I’m now running stock cron.php. Is there a way I can grab (curl/wget is fine) the default cron.php file without doing a re-install? Thanks.
Just as another data point, I just built a new server, thinkcenter tiny M700 w. 16GB RAM and 512GB SSD, i5-something. Fresh install of debian 12 netinstall. All I did to config.php was add trusted hosts, and I for sure haven’t touched cron.php. Cron container pegged at 100% and was running hot enough that I just shut down nextcloud. The only other thing I tweaked (and this is true of both servers) is that I made /data an NFS mount. Everything seems to be working fine with it… not sure if anything about permissions on /data might drive cron nuts, but it’s the only other thing I can think of.
Another update: I went ahead and set up portainer so I could get a nice view into the big-bear-nexcloud-cron-1 logs. I just re-installed nextcloud from your repo, so everything is running cool and quiet at the moment, as expected. When load spikes, as I expect it will, I should have some real logs to look at. I’ll try to figure it out on my own, but will share what I find here, either way. Thanks.