Actually I've seen the error about not having access to Z2.pid occur for reasons other than file permissions per se. It appears that the PCGI daemon still has the code in him that detects whether the zserver process is running and if not, he starts one. Nowadays zserver is started via ./start or /etc/rc.local but if it should fail for some other reason, or if the PCGI control file (Zope.cgi) is not correct, the PCGI daemon will spawn zserver, but with the -wrong- ownership/permissions. I tried to disable that part of PCGI when I built the RPMs but could not find an (easy) way. I figure it won't matter soon when FastCGI is released and we move away from PCGI. I swear though, that the Z2.pic problem is the -most- commonly reported failure w/Zope that I in my email box, and made worse that often it is a red herring. The other one I see, for the same reasons is: ImportError: (<class exceptions.IOError at 80a3008>, "[Errno 13] Permission denied: '/var/zope/var/Data.fs.lock'") To demonstrate the problem, run Zope in PCGI+ZServer mode, start up Zope and show that it works fine. Now, kill -9 both the zdaemon and zserver processes, and tell your browser to display a Zope page. Wait 15-60 seconds, while PCGI starts a new zserver process, and whamo, one of the above error messages will appear in your browser window, with a traceback in the HTML source as usual. I didn't *touch* the file/dir permission settings between the successful and unsuccessful test. Very misleading... -Jeff Rush On Sun, 24 Oct 1999 12:37:47 -0400, Michel Pelletier wrote:

...

-----Original Message----- From: VanL [mailto:vel2@email.byu.edu] Sent: Friday, October 22, 1999 6:22 PM To: zope@zope.org Subject: Re: [Zope] Could someone translate the debugging information?

Hmm.. I tried what you said, and got the following output:

IOError: [Errno 13] Permission denied: '/usr/local/share/zope/var/Z2.pid'

You do not hve permission to write the .pid file. Check your file permissions. This is completely unrelated to your original error.