SO7, NFS-mounted
Hans Werner Strube
"Workstation Installation" could be performed on this server and the
program be used correctly.
But on other machines which mount the central SO7 directory by NFS
(under the same name as on the server itself), any call to soffice
hangs.
truss shows that the hanging occurs after opening program/types.rdb :
resolvepath("/dpi/soffice/7/program/libstore.so.3.1.0", "/dpi/soffice/7/program/libstore.so.3.1.0", 1023) = 40
1458: memcntl(0xFDBD0000, 6880, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
1458: close(9) = 0
1458: munmap(0xFE270000, 8192) = 0
1458: open("/dpi/soffice/7/program/types.rdb", O_RDONLY) = 9
1458: fcntl(9, F_SHARE, 0xFFBEF200) (sleeping...)
1458: signotifywait() (sleeping...)
1458: lwp_cond_wait(0xFF365550, 0xFF365560, 0xFF35EDB8) (sleeping...)
1458: door_return(0x00000000, 0, 0x00000000, 0) (sleeping...)
1458: signotifywait() = 20
1458: lwp_sigredirect(0, SIGWINCH, 0x00000000) = 0
1458: signotifywait() = 20
1458: lwp_sigredirect(0, SIGWINCH, 0x00000000) = 0
1458: fcntl(9, F_SHARE, 0xFFBEF200) (sleeping...)
1458: signotifywait() (sleeping...)
1458: lwp_cond_wait(0xFF365550, 0xFF365560, 0xFF35EDB8) (sleeping...)
1458: door_return(0x00000000, 0, 0x00000000, 0) (sleeping...)
1458: signotifywait() = 20
1458: lwp_sigredirect(0, SIGWINCH, 0x00000000) = 0
1458: signotifywait() = 20
1458: lwp_sigredirect(0, SIGWINCH, 0x00000000) = 0
1458: fcntl(9, F_SHARE, 0xFFBEF200) (sleeping...)
1458: signotifywait() (sleeping...)
1458: lwp_cond_wait(0xFF365550, 0xFF365560, 0xFF35EDB8) (sleeping...)
1458: door_return(0x00000000, 0, 0x00000000, 0) (sleeping...)
--
Hans Werner Strube str...@physik3.gwdg.XPAM.de (remove .XPAM)
Drittes Physikalisches Institut, Univ. Goettingen
Buergerstr. 42-44, 37073 Goettingen, Germany
Hans Werner Strube
> SO7 has just been installed on a server with setup -net, and a user's
> "Workstation Installation" could be performed on this server and the
> program be used correctly.
> But on other machines which mount the central SO7 directory by NFS
> (under the same name as on the server itself), any call to soffice
> hangs.
> truss shows that the hanging occurs after opening program/types.rdb :
> 1458: open("/dpi/soffice/7/program/types.rdb", O_RDONLY) = 9
> 1458: fcntl(9, F_SHARE, 0xFFBEF200) (sleeping...)
The reason is clearly the fcntl(, F_SHARE, ). If I preload an interposer
making F_SHARE and F_UNSHARE no-ops, it works. Thus this seems to be a NFS
bug. The server is running Solaris 7 with not the newest patch level, but
one of the clients tested runs Solaris 8 (2002) and still fails.
Is the server or the client liable for the bug? Which patches are
relevant here (Solaris 7 and 8)?
[Yes, I know SO7 officially requires Solaris 8, but it works reliably
under Solaris 7 on the server itself.]
But for what reason is a read-only file on the server reserved by F_SHARE
at all? Isn't this a bug?
Hans Werner Strube
> Hans Werner Strube <str...@physik3.gwdg.xpam.de> wrote:
>> SO7 has just been installed on a server with setup -net, and a user's
>> "Workstation Installation" could be performed on this server and the
>> program be used correctly.
>> But on other machines which mount the central SO7 directory by NFS
>> (under the same name as on the server itself), any call to soffice
>> hangs.
>> truss shows that the hanging occurs after opening program/types.rdb :
> ...
>> 1458: open("/dpi/soffice/7/program/types.rdb", O_RDONLY) = 9
>> 1458: fcntl(9, F_SHARE, 0xFFBEF200) (sleeping...)
>
> The reason is clearly the fcntl(, F_SHARE, ). If I preload an interposer
> making F_SHARE and F_UNSHARE no-ops, it works. Thus this seems to be a NFS
> bug. The server is running Solaris 7 with not the newest patch level, but
> one of the clients tested runs Solaris 8 (2002) and still fails.
> Is the server or the client liable for the bug? Which patches are
> relevant here (Solaris 7 and 8)?
Now I use a Solaris 8 machine as server and everything works. Thus the
reason was the OS or patch level.