Cron job vs. zope clock

Plone Support
1

I want to setup a cronjob (or other method) to make a daily call to poke collective.contentrules.comingsoon content rule. This will then be used by a content rule I have to send notifications if certain events happened.

It appears there are (at least) two ways to accomplish this.


and
https://developer.plone.org/develop/plone/misc/asyncronoustasks.html

Looking at Zope clock server mentioned in the two articles, is this better or just different than cronjob? Can I accomplish the same with either?

Note: I have a crontab setup that should do the job:

0 10 * * * /usr/bin/curl http://admin:PWD@lwhsboosters.org/@@comingsoon-notify

2

the main difference is pretty clear if you read the documentation:

  • a crontab job has to use a Zope user
  • a Zope clock server can user a Plone user

we use the clock server in 2 sites to run tasks every hour: in one (the Olympics site) we use it to read a YouTube feed a replicate the content; in the other (a magazine) we use it for 3 different tasks like updating economic data and importing content.

in the past we were using a separate instance; we moved to reuse our current instances to save memory with some speed costs, as some of this tasks take way too long to finish (we probably need to refactor them).

obviously you can achieve more flexibility on when to run the tasks with crontab, but I still prefer the clock server.

3

We use collective.cron. even nicer with its async support.

4

We usually run

bin/instance run somescript.py

within a production ZEO setup using cron rather than calling a browser view through cron.

-aj

5 Likes
5

i recently documented the setup with cronjobs for https://github.com/collective/collective.contentrules.mustread:

* * * wget --quiet -O- --user=admin --password=admin --auth-no-challenge http://127.0.0.1:8080/Plone/@@send-read-reminders > /dev/null

as hector pointed out you need to define this user in the root acl_users file, not plone

you could also work around the need to authenticate at all by using a shared secret similar to https://pypi.python.org/pypi/munin.zope/2.1

6

to me this felt like the cleanest setup too (no need to add additional users with limited privieleges, or store manager credentials in config files)

collective.pwexpiry uses this approach too for the notify_and_expire script (collective.pwexpiry/collective/pwexpiry/scripts at master · collective/collective.pwexpiry · GitHub)
however i could not come up with a clean solution to configure the correct path to the script via buildout and z3c.recipe.usercrontab automatically:

when updating to a new egg release, the path to the script changes
how do you handle this?

don't you miss the request in such script setups? or is context.REQUEST as good as self.request in views called by curl/wget

7

We've used the zope clock in the past but I like this approach.

8

Hi, short Question:
Should be the instance down or can the instance running, if the cron call "bin/instance src/namespace.mypackage/namespace/mypackage/bin/script.py" ?

9

You need to run Plone in a ZEO setup for running a script through Cron without service interruption. Otherwise the ZODB is locked by the normal instance process.

10

Ok, my ZeoSetup client1, client2, client3. The client3 is only for the Cronjobs and not available for my Loadbalancer in front. Should i start the client3 normally with all other clients or should only the CronJob start/stop the client3 ? I'm a little confused.

11

There are two ways you can interact with your Zope instance: via HTTP automization or directly interacting with the Zope objects and infrastructure.

With HTTP automization, your script emulates a browser (and the human interacting with the browser). For this to work, your Zope process must be "running" (i.e. it must be started).

If your script interacts directly with Zope, it is not emulating a browser but accesses directly with either the Zope objects or its functions. There is no need that Zope is running -- the important active instance is your script (and maybe the ZEO or other database servers).

If you use bin/client<x> run ..., your script is able to interact directly with Zope; thus, no need to use bin/client<x> start before you start your script.

1 Like
12

I have usually one spare ZEO client for such cases - either for debugging or for running such jobs outside the loadbalancer scope. I should be possible to "run" a script if a ZEO client that is already running but I would not recommend it. It is in general a good recommendation have a spare ZEO client with debugging settings enabled by default for debugging...it's handy and does not require any further resources.

-aj

2 Likes