Summary for Fileserver process for ILINK 3.4 M062 on Solaris 10: nfsserv
Thank you all for responses. We still have multiple processes for
nfsserv -alone 7777 but some users here have the same. So far FS is
running without problems. Users responses below. At the end I included
a) I would be very interested in any responses that you get. We are
seeing similar behavior on our 3.4 M040 on Solaris 8, with one
Our fileserver randomly stops functioning. So far this year this has
happened 6 times. We have sent our dump file to PTC and their only
solution was for us to install the M062 fileserver. They said it would
work, and they would support it, running with a M040 dataserver. We
tested it and it did work but stopped short of putting that
configuration in production. After more discussions with PTC, they told
us, "just restart the fileserver when it happens". Well, that is what
b) We often see multiple nfsserv -alone processes. I have never
confirmed with PTC, but I believe a new -alone process is started each
time the client requests files. Normally these end once the files are
transferred but if something goes wrong this process can get hung up -
this seems to happen more often now that we have people using VPn from
home so they sometimes lose the network connection during check out.
Usually these hung processes don't cause any problem (I've had some of
them hung up for months as long as the main nfsserv process is running.
If the main nfsserv process dies then no check ins or check outs work.
We are running 3.4 M030 but this is the behavior I've seen with every
version of Intralink we've used (3.0, 3.2, 3.4).
c) On Solaris 10 w/Ilink 3.4 M060 I have the following:
server3# ps -ef | grep nfsserv | grep -v grep
root 2941 2938 0 May 09 ? 17:53
/opt/ptc/fileserver3.4/sun4_solaris_64/obj/nfsserv -alone 7777
root 2938 1 0 May 09 ? 0:00
Notice there are only 2 nfsserv processes running: 2938 (the parent) and
2941 (a child of 2938).
I would suggest you do the following:
stop the fileserver process "/etc/rc2.d/S99fileserver stop"
check for any "orphan" nfsserv processes with "ps -ef | grep nfsserv |
grep -v grep"
if you find any then kill them with "kill pid" or "pkill nfsserv"
restart the fileserver process "/etc/rc2.d/S99fileserver start"
recheck the nfsserv processes with "ps -ef | grep nfsserv | grep -v grep
Bear in mind that that checkins, checkouts, or updates from this
fileserver will not work until after step 4. However depending on how
many users you actually have and how fast you are at running commands
this may not be a problem.
d) I have a test setup of Intralink 3.4 M050 on Solaris 9. It has only
those two processess:
root 487 1 0 Aug 21 ? 0:00
root 488 487 0 Aug 21 ? 0:00
/opt/ptc/fileserver3.4/sun4_solaris/obj/nfsserv -alone 7777
Please note that if you have more than one fileserver process that means
you have more than one fileserver which is running. Also please note
that this makes the functionality a little difficult. This may lead to
the error message which you are receiving. In my opinion I think you
have 2 fileserver installed on the machine which is why you are facing
this issue. Please check and once you get please install the one which
is not required. [comment: we installed ONLY one FS M062]
Q for PTC:
If you could check for me this one thing with your ptc developers: how
many nfsserv -alone 7777 processes there should be on Solaris 10 when
fileserver is running(ONLY one or multiple are allowed).
Answer form PTC:
Please note that I tried to found about the number of process and it
should be only one. [comment: according to above responses from users
some of them have multiple nfsserv -alone 7777 processes also]
This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.