lockfile blocking other projects on one server

[Daniel Widerin]

if you have multiple installations of S&D (for example in multiple projects on the same server) you get problems with the generated lockfile-name, because it's always '/tmp/collective.dancing.browser.utils.tick_and_dispatch'.

Example:
user1 is running your Z1 with S&D.
user2 which is running Z2 with S&D.

user1 is sending a newsletter, @@dancing.utils is running and blocking other instances to start over again which is correct. but it also blocks user2 from sending even a newsletter subscription confirmation mail

By default /tmp/collective.dancing.browser.utils.tick_and_dispatch is created with 0644 permission, which raises IOErrors in other projects which run their zopes with different users:

Traceback (innermost last):
  Module ZPublisher.Publish, line 127, in publish
  Module ZPublisher.mapply, line 77, in mapply
  Module ZPublisher.Publish, line 47, in call_object
  Module collective.dancing.browser.utils, line 37, in tick_and_dispatch
  Module zc.lockfile, line 73, in __init__
IOError: [Errno 13] Permission denied: '/tmp/collective.dancing.browser.utils.tick_and_dispatch'

When changing permission to 0664 and put all users into this assigned group it should work (untested) but user1's S&D is still blocking user2's newsletter beeing sent.

So the only really good solution would be including the current project path into lockfile-name.

[Daniel Widerin (saily)]

Possible ways to solve this (feedback welcome):
 * include current zope user in lockfilename
 * include current path in lockfilename
 * include current mailserver in lockfilename (maybe you don't want to stress your mailserver with multiple projects sending the their newsletters the same time)
 * include a optional request parameter which you append in your clockserver-configuration to modify your lockfile dynamically.

[Maurits van Rees (maurits-vanrees)]

Perhaps store the lockfile in the client home. Use:

os.environ.get('CLIENT_HOME')

In my case that gives '/Users/mauritsvanrees/buildout/singing-dancing-dev/var/instance'
I'm not sure if we mind that this means that two zeo clients could start sending out a newsletter at the same time, as they will have two separate lock files.

Including the current zope user (e.g. with os.getuid(), which in my case returns 501) in the lock file name sounds fine too. It does not solve the case of one zope user running multiple buildouts that use S&D, but that seems okay to me, though it may need a mention in some documentation, even if only in the HISTORY.txt

Current path might be tricky. At least os.getcwd() returns different directories, depending on where you are when you start the instance. And in a cron job, e.g. to restart the instance at reboot time, the current working directory is probably the root of the file system.

[Daniel Widerin (saily)]

We have the same problem with collective.singing.message.lock which is also placed in /tmp directory and blocking other S&D installations in other projects on the same server.

@maurits: i tried the os.environment.get('CLIENT_HOME') but it seems to be different when running the tests...

[Maurits van Rees (maurits-vanrees)]

Strange, with "os.environment.get('CLIENT_HOME')" I always get <buildout directory>/var/instance
It's the same whether I do 'bin/instance fg' or 'bin/instance test -s collective.dancing' in collective.dancing/trunk-buildout or 'bin/instance fg' or 'bin/test' in collective.dancing/trunk

At least, this is when putting that "os.environment.get('CLIENT_HOME')" line near the top of collective/dancing/browser/utils.py

[Harald Friessnegger (frisi)]

i'd go for the last propsed option "include a optional request parameter which you append in your clockserver-configuration to modify your lockfile dynamically."

its relatively easy to implement and works on all OS. in addition developers and admins can configure whether two instances with different newsletters use the same lockfile (might be useful if they use the same smtp-server) or not.