Configuration file imports don't see INSTANCE_HOME when running zope as a windows service

[Michael Dunstan]

Extensions to zope.conf installed in INSTANCE_HOME of the form::

  %import Products.MyProduct
  <myproduct>
     ...
  </myproduct>

are not available when running Zope as a windows service. (They are available when running from runzope.bat or other platforms.) From memory the service silently dies when it gets to the import directive.

My hack was to set up a PYTHONPATH to include INSTANCE_HOME before starting PythonService.exe. See patch for details.

[ChrisW (chris-simplistix)]

Status: Pending => Resolved

It's more insidious than that, having just run into this with MailingLogger 2.0.0

Although we now have the shiny new ZConfig zope.conf file, the old environemnt variables will still have an effect.

See findhomes.py in your Zope source tree.

What I experienced was that MailingLogger worked fine on Windows, but not on Linux. The difference I found was that in my linux runzope script, I hadn't exported INTSANCE_HOME, whereas in Windows batch files, you don't get a a lot of choice, the equivalent of a shell script EXPORT happens anyway, whether you want it or not.

Now, it's the presence of the environment variable that makes findhomes.py correctly set up the Products pseudo-module when ZConfig imports Zope's schema.xml. Once that's set up:

%import Products.SomeProduct

...will work, but not before.

Now, the options are:

1. Include the instances's Products path on the PythonPath. NB: This breaks if your Product does:

from Products.MyProduct import x

2. require the INSTANCE_HOME environment variable to still be set when this circumstance arises. This is what I've advised in the MailingLogger documentation.

3. Extend ZConfig to allow %imports to work with things that aren't just on the python path in some way.

Option 1 and 2 work now, and option 3 is a change to ZConfig, which isn't appropriate to discuss in this collector. I'll send a mail to <email address hidden> to kick off the discussion.

As for your specific problem, I'd recommend wrapping zopeservice.py in a batch script or twiddling with the service settings such that INSTANCE_HOME is set before zopeservice.py starts.

I DON'T think zopeservice.py should be changed in the way you suggest.So I'll mark this bug as resolved, and hopefully ZConfic will grow something to support this.

[Tim Peters (tim-one)]

FYI, Zope's Z4I product had a similar problem when running as a Windows service. Z4I needs to use a different Interface package than the base Zope's, but when running as a service the instance's lib/python (containing the Interface Z4I needs) got stuck on sys.path too late: the base Zope's Interface had already been loaded by then.

The variant of zopeservice.py Z4I uses worms around this by doing

os.environ["INSTANCE_HOME"] = INSTANCE_HOME

That's something like the patch here, but better in two respects: (1) modifying os.environ is "the correct" way to set envars in Python (it calls putenv() under the covers, BTW); and, (2) setting PYTHONPATH directly overwrites whatever (if any) PYTHONPATH the user set.

[Tim Peters (tim-one)]

Status: Resolved => Pending

I'm resubmitting this. I don't believe either of the suggested workarounds make sense: (a) you can't run a .bat script as a Windows service, and even if you could the Zope distribution would have to change anyway (to do that instead of running zopeservice.py directly); (b) there is no option to set environment variables specific to a service.

[Tim Peters (tim-one)]

This thread from March has a lot of clues:

http://mail.zope.org/pipermail/zope-dev/2004-March/021979.html

[Tres Seaver (tseaver)]

We can't go further without input / interest from Windows-service-running users here.

[Colin Watson (cjwatson)]

The zope2 project on Launchpad has been archived at the request of the Zope developers (see https://answers.launchpad.net/launchpad/+question/683589 and https://answers.launchpad.net/launchpad/+question/685285). If this bug is still relevant, please refile it at https://github.com/zopefoundation/zope2.