Howdi. I just checked in how I finally got Zope 2.7.x to run as a service on Windows again. Setting the PYTHONPATH environment actually even makes more sense here as the CreateProcess API call won't take the sys.path into the new python, but the environment variables. This now also plays with the import of sitecustomize.py correctly. I still wonder why this seems to behave differently in 2.7 as in 2.8. The 2.8 currently works as a service out of the box. I don't see the actual difference. Anybody tell me. I'm scared. Also: I'd like to know if this solution for 2.7 is acceptible or not. It works for me but I'm everything but a windows guru. Cheers, Christian PS: See http://cvs.zope.org/Zope/skel/bin/Attic/zopeservice.py.in.diff?r1=1.1.2.8&r2... for the change. -- gocept gmbh & co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - ct@gocept.com - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development
[Christian Theune]
I just checked in how I finally got Zope 2.7.x to run as a service on Windows again. Setting the PYTHONPATH environment actually even makes more sense here as the CreateProcess API call won't take the sys.path into the new python, but the environment variables.
It doesn't sound like a good solution. PYTHONPATH is Python's envar, not Zope's, and a user can legitimately set PYTHONPATH to whatever they like (for example, to get other extensions they've installed found by whichever Python is running). Then their stuff won't work if we clobber their PYTHONPATH.
This now also plays with the import of sitecustomize.py correctly.
I still wonder why this seems to behave differently in 2.7 as in 2.8. The 2.8 currently works as a service out of the box. I don't see the actual difference. Anybody tell me. I'm scared.
I don't know -- I've lost track of how Zope 2 gets built on Windows. All along on Windows, Products/WinBuilders/etc/ has tried to install its own sitecustomize.py on Windows, to force the software home into sys.path whenever Zope's Python is used. I don't have any idea how that plays with "the other" sitecustomize.py newly added to Zope 2 proper. Best guess is that they conflict horribly <wink>, but that nobody has noticed that yet.
Also: I'd like to know if this solution for 2.7 is acceptible or not. It works for me but I'm everything but a windows guru.
As above, I doubt it's the right solution. But if nobody on Windows complains, maybe you're stuck with it. It would be good to know if you're aware of WinBuilders and Zope fighting over sitecustomize.py now. Who wins? If Zope's sitecustomize.py is overwriting the sitecustomize.py WinBuilders tries to install, that would explain why Windows services stopped working.
I just checked in how I finally got Zope 2.7.x to run as a service on Windows again.
See also http://collector.zope.org/Zope/1533 - this has a number of changes to make services much more reliable on Windows. My patch includes your change, but along the lines of Tim's objection, mine compromises with: +os.environ["PYTHONPATH"] = os.environ.get("PYTHONPATH", "") + ";" + SOFTWARE_HOME My patches also have the killer feature of writing any Zope stdout to the Windows event log in the case of error - critical if you hope to see what the underlying error was. The patch also allows for Zope to be terminated gracefully (rather than unconditionally terminating it as now), re-instates support for Windows NT, and allows for a complete, functioning pywin32 build to be used (including win32com etc). Just-by-way-of-reminder ly, Mark
Mark Hammond wrote:
I just checked in how I finally got Zope 2.7.x to run as a service on Windows again.
See also http://collector.zope.org/Zope/1533 - this has a number of changes to make services much more reliable on Windows. My patch includes your change, but along the lines of Tim's objection, mine compromises with:
+os.environ["PYTHONPATH"] = os.environ.get("PYTHONPATH", "") + ";" + SOFTWARE_HOME
My patches also have the killer feature of writing any Zope stdout to the Windows event log in the case of error - critical if you hope to see what the underlying error was. The patch also allows for Zope to be terminated gracefully (rather than unconditionally terminating it as now), re-instates support for Windows NT, and allows for a complete, functioning pywin32 build to be used (including win32com etc).
Just-by-way-of-reminder ly,
+1 for landing Mark's patch as a prerequisite to fixing *any* Windows-service related bug in the future. Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
[Mark Hammond]
See also http://collector.zope.org/Zope/1533 - this has a number of changes to make services much more reliable on Windows. My patch includes your change, but along the lines of Tim's objection, mine compromises with:
+os.environ["PYTHONPATH"] = os.environ.get("PYTHONPATH", "") + ";" + SOFTWARE_HOME
My patches also have the killer feature of writing any Zope stdout to the Windows event log in the case of error - critical if you hope to see what the underlying error was. The patch also allows for Zope to be terminated gracefully (rather than unconditionally terminating it as now), re-instates support for Windows NT, and allows for a complete, functioning pywin32 build to be used (including win32com etc).
Just-by-way-of-reminder ly,
[Tres Seaver]
+1 for landing Mark's patch as a prerequisite to fixing *any* Windows-service related bug in the future.
I think we should call now "the future". Windows services were broken completely by the sitecustomize.py fiddling, and remain in a hackish state. Christian, Mark wrote the book (literally) on managing Windows services from Python, and wrote all the win32all support code Zope has relied on forever to get Windows services working at all. If it's at all possible to apply his patches, please do so -- they address several long-standing problems Zope suffers on Windows, and nobody on Earth is better qualified to fix them than Mark.
Hi all, Am Freitag, den 17.12.2004, 15:17 -0500 schrieb Tim Peters:
[Tres Seaver]
+1 for landing Mark's patch as a prerequisite to fixing *any* Windows-service related bug in the future.
I think we should call now "the future". Windows services were broken completely by the sitecustomize.py fiddling, and remain in a hackish state.
Yupp.
Christian, Mark wrote the book (literally) on managing Windows services from Python, and wrote all the win32all support code Zope has relied on forever to get Windows services working at all. If it's at all possible to apply his patches, please do so -- they address several long-standing problems Zope suffers on Windows, and nobody on Earth is better qualified to fix them than Mark.
Ok, I'll do that. I have accepted a couple of reports to windows specific problems. I think I'm the complete opposite of Marks windows abilities, but as I'm maintaining the Windows releases, I'm caring for that. Hope to get all the windows stuff cleaned up until after xmas. Cheers, Christian -- gocept gmbh & co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - ct@gocept.com - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development
--On Freitag, 17. Dezember 2004 10:35 Uhr -0500 Tres Seaver <tseaver@zope.com> wrote:
Mark Hammond wrote:
I just checked in how I finally got Zope 2.7.x to run as a service on Windows again.
See also http://collector.zope.org/Zope/1533 - this has a number of changes to make services much more reliable on Windows. My patch includes your change, but along the lines of Tim's objection, mine compromises with:
+os.environ["PYTHONPATH"] = os.environ.get("PYTHONPATH", "") + ";" + SOFTWARE_HOME
My patches also have the killer feature of writing any Zope stdout to the Windows event log in the case of error - critical if you hope to see what the underlying error was. The patch also allows for Zope to be terminated gracefully (rather than unconditionally terminating it as now), re-instates support for Windows NT, and allows for a complete, functioning pywin32 build to be used (including win32com etc).
Just-by-way-of-reminder ly,
+1 for landing Mark's patch as a prerequisite to fixing *any* Windows-service related bug in the future.
I suggest we schedule that for 2.7.5. As I understood Christian, the service machinery is now working again (for 2.7.4). So we could add these enhancements to 2.7.5. Andreas
Howdi, Am Samstag, den 18.12.2004, 09:09 +0100 schrieb Andreas Jung:
I suggest we schedule that for 2.7.5. As I understood Christian, the service machinery is now working again (for 2.7.4). So we could add these enhancements to 2.7.5.
I'd be fine with that. Additionally, I need to review what the difference between 2.7 and 2.8 is, as 2.8 wasn't broken at all. Cheers, Theuni -- gocept gmbh & co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - ct@gocept.com - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development
participants (5)
-
Andreas Jung -
Christian Theune -
Mark Hammond -
Tim Peters -
Tres Seaver