[Tickets #12906] Re: Horde doesn't work on NFS

[n***@bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/12906
------------------------------------------------------------------------------
Ticket | 12906
Updated By | ***@fsn.hu <***@fsn.hu>
Summary | Horde doesn't work on NFS
Queue | Horde Base
Version | 5.1.5
Type | Bug
State | Unconfirmed
Priority | 2. Medium
Milestone |
Patch |
Owners |
------------------------------------------------------------------------------


***@fsn.hu (2014-01-08 09:02) wrote:

I've a recently upgraded Horde from FreeBSD packages. The server runs
from a read only NFS server, so every directory and file are on NFS
and are read only.
When I log into Horde, I get the following error:
[08-Jan-2014 09:46:44 Europe/Budapest] PHP Fatal error: Call to
undefined method PEAR_Error::getName() in
/usr/local/share/pear/Horde/Core/Db/Migration.php on line 93

Placing two debug log statements around that line:
-----------------------------------8<-----------------------------------
foreach (glob($pear->get('data_dir') . '/*/migration') as $dir) {
Horde::log("XXX ".$dir, Horde_Log::ERR);
Horde::log("XXX
".$registry->getPackage(basename(dirname($dir)),
'pear.horde.org'), Horde_Log::ERR);
$app = $registry->getPackage(
-----------------------------------8<-----------------------------------
revealed the following:
Jan 8 09:46:44 [imp] XXX
/usr/local/share/pear/data/Horde_ActiveSync/migration [pid 2333 on
line 90 of "/usr/local/share/pear/Horde/Core/Db/Migration.php"]
Jan 8 09:46:44 [imp] XXX could not acquire shared lock
(/usr/local/share/pear/.lock) [pid 2333 on line 91 of
"/usr/local/share/pear/Horde/Core/Db/Migration.php"]

Doing a ktrace on the php process gives:
2333 php-fpm CALL open(0x810f64348,0<O_RDONLY>,<unused>0)
2333 php-fpm NAMI "/usr/local/share/pear/.lock"
2333 php-fpm RET open 16/0x10
2333 php-fpm CALL fstat(0x10,0x8112bc540)
2333 php-fpm STRU struct stat {dev=973143809, ino=3195588,
mode=-rw-r--r-- , nlink=1, uid=0, gid=0, rdev=42672,
atime=1389170490.846139742, stime=1389170490.846139742,
ctime=1389170490.846139742, birthtime=-1, size=0, blksize=4096,
blocks=1, flags=0x0 }
2333 php-fpm RET fstat 0
2333 php-fpm CALL lseek(0x10,0,SEEK_CUR)
2333 php-fpm RET lseek 0
2333 php-fpm CALL flock(0x10,0x1<LOCK_SH>)
2333 php-fpm RET flock -1 errno 45 Operation not supported

which makes sense, flock over NFS doesn't work. Last year this setup
worked. What has changed since then?
Could you please correct, or work around this to make Horde runnable
over NFS again?

[n***@bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/12906
------------------------------------------------------------------------------
Ticket | 12906
Updated By | Michael Rubinsky <***@horde.org>
Summary | Horde doesn't work on NFS
Queue | Horde Base
Version | 5.1.5
Type | Bug
-State | Unconfirmed
+State | Not A Bug
-Priority | 2. Medium
+Priority | 1. Low
Milestone |
Patch |
Owners |
------------------------------------------------------------------------------


Michael Rubinsky <***@horde.org> (2014-01-08 15:57) wrote:

This is a limitation of PEAR, it requires that the process owner be
able to create a lock file in the pear directory. You can talk to the
folks at PEAR to see if it's possible to work around this on a
read-only NFS share. It might even be possible to manually set the
directory to create the lock...

[n***@bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/12906
------------------------------------------------------------------------------
Ticket | 12906
Updated By | ***@fsn.hu
Summary | Horde doesn't work on NFS
Queue | Horde Base
Version | 5.1.5
Type | Bug
State | Not A Bug
Priority | 1. Low
Milestone |
Patch |
Owners |
------------------------------------------------------------------------------


***@fsn.hu (2014-01-09 06:28) wrote:

I guess doing mandatory locking in getPackage may not be needed, so
this could be made optional, if it fails, just do the thing without
the lock.
I've already opened a bug there, I hope they will take care of it.

Thanks.