Skip to main content

Plone 4, ZEO and supervisor

This post belongs also to the "lessons learned" category.

With Plone 3, ZEO and supervisor combination you've probably configured your supervisor to start plone instances by running $BUILDOUT/parts/client1/bin/runzope.

Problem is that with Plone 4 your $BUILDOUT/parts/client folder doesn't contain anything else than etc folder. You know starting instances by targeting supervisor to use $BUILDOUT/bin/client1 fg doesn't work like you'd expect (supervisor would control the client1 script - not the actual plone process).

My colleague Jussi Talaskivi figured that using 'console' argument instead of 'fg' for bin/client1 script should do the trick. With 'console' argument stopping, starting and restarting Plone 4 instances with supervisor works like a charm.

Below is full example of working supervisor configuration.

[buildout]

parts = supervisor

[supervisor]
recipe = collective.recipe.supervisor
port = 8200
user = xxxx
password = xxxx
programs =
    10 zeo       /buildout/xxx/parts/zeoserver/bin/runzeo  true zope
    20 instance1 /buildout/xxx/bin/instance1 [console]     true zope
    20 instance2 /buildout/xxx/bin/instance2 [console]     true zope

Comments

  1. The "bin/instance console" argument has been available for years and works just as well in Plone 3.

    I'd also run zeo with "bin/zeo fg" instead which also works with supervisord.

    ReplyDelete
  2. Yeah, starting instances with console argument isn't a new thing. Still several forum discussions and blog posts about Plone and supervisor mention that supervisor should launch plone instances using $BUILDOUT/parts/client/bin/runzope so that supervisor would actually control the process.

    As this is not possible with Plone 4 I tried to search alternative way. After wasting few hours by googling and asking this from #plone irc channel I was still without solution (except starting instances with fg argument which isn't the correct way as far as I know). Hopefully this post can help others looking for the same information.

    About zeo.. I thought that same limitations affects to zeo too, but I guess I was wrong. I just tested and can confirm that controlling zeo with fg argument works fine with supervisor.

    ReplyDelete
  3. I'm running plone 4 instance w/o ZEO setup. And 'fg' as well as 'console' commands work well with supervisor only to start instance and to get it's status.

    But anyway supervisor is still controlling only script process, not instance process itself, that's why I can't make supervisor stop my plone 4 instance. Any suggestions?

    ReplyDelete
  4. After more experiments with 'console' command I realized that it really works. Disregard my previous comment. Thank you for sharing this information, it was really helpful!

    ReplyDelete
  5. Yes, of course we know that the "console" argument has always been around, but this is still exactly what I needed to know. Thanks Jussi and Jukka.

    ReplyDelete

Post a Comment

Popular posts from this blog

Speed comparsions between Plone and Wordpress

Jon Stahl wrote recently a blogpost about Plone being three times faster than Dropal, Joomla and Wordpress . We had a small discussion about this in my workplace and as my colleague pointed out this wasn't a really that comprehensive test that you could state Plone being 3 times faster than it's competitors. This seemed a bit unfair test considering how fast this has been spread in tweet/blogosphere, so I decided to repeat the test with a bit more critical viewpoint. What's wrong in the original test? No one would consider opinion poll with 10 answers nowhere near trustworthy - it's all the same with requests. I didn't want to put up all the cms so I just set up second best (Wordpress 2.9.1) and compared that to my Plone development site (4.0a3). As a comparsion I did the first test with same ab command Jon used and my iMac gave following results: Wordpress: 7.13 requests / second Plone: 17.10 requests / second So far we have clear winner and Jons data hol

Problems with Plone version pinning

Since we splitted our one huge Plone site to several smaller ones we've been looking for the correct procedure to keep things running smoothly and to make updates as painless as possible. So far we haven't found the right way and every update has had some problems. Some of the problems are related to the fact that we have about 24 sites to maintain and adding a new content type to all of them means lots of work. Below are all the steps needed for update (and solutions we've founded so far). 1. Add your new product to buildout.cfg eggs and zcml list. Do this 24 times and you'll find yourself thinking there has to be better way. Luckily there is; you can extend your buildout.cfg with some general config file (eg. deployement.cfg). Most tutorials describe a way where you have those two files living side by side in filesystem and you run buildout with -c deployement.cfg option, but this doesn't remove the actual problem. We have our deployement.cfg living in diffe

Usability and Plone

I've seen in here and there someone mentioning that usability of Plone is very good. Lot's of people - me included - like the fact that in Plone you don't have separate content management interface compared to some of Plones rivals. That counts for something when we're talking about good usability. Still that is only one quite small part of the whole picture. So what else is there? What do people like in Plone and where are the rough edges for end users? If general consensus is that Plone does have good usability, where is the actual proof of that? On plone.org I found one page in developer documentation mentioning following:  "Plone differentiates itself on usability. The intuitiveness of the user interface is what attracts people to Plone the most." I interpret this sentence meaning about the "one view for all" approach. What bugs me in this is that this whole sentence about good usability is about how the UI works compared to Plones competi