Failed to steal lock for file xxxx.cache from PID

Next topic

Author	Message
Monica Giambitto	Wednesday 08 June 2011 7:00:45 am Hello everybody. I had this problem just a few days ago. The problem arose after deleting physically some cache file. Ez couldn't find it anymore and for some reason the check done by processCache() method and subsequent code wasn't enough to handle this (I'm no ez publish or metaprogramming guru). I solved this issue by simply duplicating a cache file created in the meantime for the same node and renaming it to the file ez was searching for and everything went fine. Something I didn't manage to understand was why the PID ($oldpid) was empty. I don't know if this can be of any help to the core developers but while I was digging for this error, I stumbled upon the method flock() called by the _exclusiveLock() method from eZFSFileHandler. Since, again, I'm no guru, I went to the php manual to understand what flock() was used for and I found this comment where the first line says (for those lazy enough that don't want to go reading it there) "1) flock() is not safe if multiple php sessions are simultaneously locking." Hope can help somebody.
Carlos Revillo	Wednesday 08 June 2011 9:43:34 am hi Monica. Are you usign a multiple server installation? regarding to the first part of your question, it's strange... i would expect that if the file is removed, accidentally or not, ez publish should try to generate it again if needed... so, maybe can be also a permission problem?
Monica Giambitto	Wednesday 15 June 2011 7:25:37 am Hi Carlos, I don't think the installation is on multiple server. My solution didn't work for long, since when the cache was cleaned again, the problem came back. I think it was a corrupted mutex file (after digging for a loooong time), that had its xxx_meta companion no more, so ez couldn't access the meta information (such as pid and so on). After deleting the lonely mutex file everything went back to normal.

Author

Message

Wednesday 08 June 2011 7:00:45 am

Hello everybody. I had this problem just a few days ago.

The problem arose after deleting physically some cache file. Ez couldn't find it anymore and for some reason the check done by processCache() method and subsequent code wasn't enough to handle this (I'm no ez publish or metaprogramming guru).

I solved this issue by simply duplicating a cache file created in the meantime for the same node and renaming it to the file ez was searching for and everything went fine.

Something I didn't manage to understand was why the PID ($oldpid) was empty.

I don't know if this can be of any help to the core developers but while I was digging for this error, I stumbled upon the method flock() called by the _exclusiveLock() method from eZFSFileHandler. Since, again, I'm no guru, I went to the php manual to understand what flock() was used for and I found this comment where the first line says (for those lazy enough that don't want to go reading it there) "1) flock() is not safe if multiple php sessions are simultaneously locking."

Hope can help somebody.

Carlos Revillo

Wednesday 08 June 2011 9:43:34 am

hi Monica.

Are you usign a multiple server installation?

regarding to the first part of your question, it's strange... i would expect that if the file is removed, accidentally or not, ez publish should try to generate it again if needed... so, maybe can be also a permission problem?

Monica Giambitto

Wednesday 15 June 2011 7:25:37 am

Hi Carlos,

I don't think the installation is on multiple server. My solution didn't work for long, since when the cache was cleaned again, the problem came back.

I think it was a corrupted mutex file (after digging for a loooong time), that had its xxx_meta companion no more, so ez couldn't access the meta information (such as pid and so on). After deleting the lonely mutex file everything went back to normal.