Something happened on the fist attempt to post this, so sorry or the duplicate entry.
Before setting up my Docker based NextCloud server I am trying to gain some more understanding about background jobs in NextCloud, their role and and proper configuration. From what I have read the background jobs are an important component to running a NextCloud instance efficiently and the preferred method for for executing them is using Cron. I also found this nice blog on various ways to set up cron jobs. I really hope someone can help me answer some of the (quite possibly noob-) questions below so that I can better understand this topic.
From what I’ve gathered all the background jobs are defined in cron.php. Does this file contain a set of “default” tasks that should be run regardless of the NextCloud instance setup? If so, what sort of task are they.
The NC docs, mentions that some tasks should be run at different times. I might be missing something here, but if running the cron.php file with cron will not all the tasks in the script be executed at the same time?
Using Docker it seems the preferred way to running Cron is in an additional container. I do not fully understand the separation or interaction between the main NC container and the NC cron container. Is the cron container where I would define the scheduled cron job which would trigger the cron.php script located in the main NC container? Why does this container have to be built from and NC image if it only running crontab?
The suggested docker-compose file for the NC cron container contains this configuration, entrypoint: /cron.sh. I’m not sure what this line actually do. Will it execute a cron.sh file on container startup? Where is this file and what does it do?
How do I find out when I need to- and how to- extend cron.php with additional task? Are there code snippets documented somewhere to extend to the bacground jobs scrip for certain NC addons etc?
Thanks for the input @wwe. The docker-compose you provided seems to be similar to the example found under the official repo. Creating this container is no issue, however, it is no use to me if I do not understand how the cron jobs work in NC and how to use/add/modify them. Hence my questions which I hope someone can elaborate on.
Still not sure why the Cron container needs to be a secondary NextCloud container though. As I understand it from what has been described the container only needs access to the same directory as as the main NextCloud container as well as being able execute a crontab. A job that could be done by any basic Linux container.
Regarding the directories; I have planed to mount additional volumes for data, config, your theme and custom apps. Something like this:
The cron container needs access to exactly same resources the app container has: files, database and config. as files within Nextclodu are not only the objects in the file system but they belong together with other metadata regarding this object in the DB - e.g. file versions, trashbin, sharing links etc. in other words it must be like a shadow of the original…
I’m sorry I really don’t get your problem - the other container doesn’t cost you anything, no more storage no more resources (compared to another container which costs additional storage).
Ah, so that means the Cron container is not only a “trigger” it is actually executing the background tasks within that container. This has not been clear to me.
Oh, I’m sure it doesn’t, that is not my concern. I am just trying to learn and increase my understanding of what is going on in the whole NextCloud / Docker setup and which container is doing what and the how the interaction between them is working. Sorry for not being clear.
Why would it cost additional storage if you expose the same mountpoints to that container as the main NextCloud container is using? (again, this is just for my understanding).
the mountpoints cost you only as many storage as they contain data, this is exactly the same if you share with one or multiple containers… different containers cost you additional storage… in other words running 10 containers from one image cost you 1ximage size (plus runtime data like logs/temp etc). running 2 containers from 2 images costs you the sum of two image sizes.
I am very much in a similar situation, making my first steps with Docker. Only difference: I had already set up the Nextcloud container and now try to add cron (cf this post). Carefully reading the conversation above (thank you @norsemangrey and @wwe), I am still not clear on some aspects.
I understand that the Cron container should have exactly the same resources as the app container. But then:
What is the benefit of running it in a separate container; why not run cron in the ‘main’ (App) container?
I suppose in your case the db.env contains the details of the db container (host, user, pw). But if Cron really needs access to the NC database, why does the Cron container in the example compose.yml only have the volume nextcloud:/var/www/html, and not the volume db:/var/lib/mysql (as specified for the Db container) or the (env) details necessary to access the database server?
Your setup @wwe has both the ‘parent’ directory /var/www/html and the 3 child directories as volumes. So I suppose that works. However, for my App container I didn’t define the parent directory, only the child directory. My Nextcloud instance works fine (can stop/restart without problem). Therefore:
Might the cron container also need access to other files & folders under / var/www/html, besides data, config and custom_apps? And if so, why?
Specifically: given that cron.sh loads www-data's cron tab, which in turn initiates cron.php every 5 minutes; shouldn’t www-data's cron tab be persistent to allow apps to add other/new cron jobs? (From your set-up and the example compose.yml this seems not to be the case, but I find it a bit surprising.)
Can I make do without creating a volume for the parent directory?
How does Docker’s mounting process work in my situation, where I don’t have a volume specified for the parent folder? Am I correct to assume that first the volumes are mounted in the virtual file system, and that any gaps that exist vis-à-vis the image (missing folders/files) are filled by creating them in the virtual file system, using the image as source?
I made several attempts but it didn’t seem to work. Many thanks to anyone & everyone helping us in our attempt at better understanding what is going on exactly under the hood
the philosophy of the docker is each container does exactly one thing.
the cron container does not access database files stored on the disk - it rather connects to the DB server through the network (exactly the same way application does)
if your don’t define persistent files changes happen within container instance (review difference to the image) -this can result in different files within specific container instance (e.g. you install new application which only exist within app container, but not within cron) I don’t expect issues, give it a try. otherwise it makes no difference from the admin point of view if you persist the folder and share them…
only in case you manipulate the crontab, otherwise I expect it to be managed by the maintainers of the image. yes you can persist a single file as well
How might it connect to the db server? In the example file it doesn’t have the same information as the application; the example file doesn’t give the db container credentials to access the db.
I gave it a try and cron doesn’t seem to work - at least I still have the warning in the Nextcloud admin panel.
This also worries me:
$ ls /var/www/html
config custom_apps data
That folder in the App container has many more folders and files. Despite the NC image being loaded, why do I here only have my mounted volumes?
$ systemctl status cron
sh: 6: systemctl: not found
$ crontab -e
sh: 7: crontab: not found
$ service crond status
crond: unrecognized service
$ grep "cron.php" /var/log/cron
grep: /var/log/cron: No such file or directory
None of methods I could find on the internet to check whether cron is active actually worked in the cron container (probably because the image is stripped down quite a bit).
If you didn’t provide DB autoconfiguration variables, most likely you performed the DB config manually and need to share the config.php file between the app and cron container (you need to share it in any case)
The mechanics of the docker cron I described earlier:
@norsemangrey I actually managed to get it set up, wasn’t too complicated after all.
While I had volumes for /var/www/html/config, /var/www/html/custom_apps and /var/www/html/data, the parent folder was missing. Kind folks over at GitHub said that I should add that folder as a volume, and share it with the app container.
Apparently there’s some other files (and/or the whole NC installation - didn’t really understand that) which are used by the cron container. As I hadn’t added the parent folder as volume for some reason the parent folder was empty (which I still don’t quite understand - I would expect it to be ‘filled’ from image when launching the container). Because the parent folder is empty, cron couldn’t run, basically.
After adding the parent folder /var/www/html both to the app and the cron container it worked. This is my cron container as in docker-compose.yml: