4.2 server stops responding

[five0.4tluv]

here is my setup. The VSS database lives on a Samba server. Windows VSS users connect with VSS 6.0d. I then have a SourceOffsite 4.2 server living on a VMware server (2 procs 4G ram) for Linux users to check out code to run scripts against (command-line) and some SOS gui users who refuse to use VSS.

We are getting occasional login hangs and unresponsive server. I have to restart the server twice to get it to act right. After getting it up and operational linux sos users get the following scenario:

* users explanation to me *
a parse error on some ~/.sos/exch* file
I press OK and now all the working folders have disappeared
When I type in the working folder, it doesn't know the status of any files - it is listed as unknown or something like that
So I mark them all, and get the latest copy and it overwrites anything checked out and modified locally

so the user looses all locally check-ed out code that they were modifying.

so the main thing is how do I troubleshoot why my server stops responding when VSS users can still work on the database. and what is the correct method to recover the user information after they can get back in.

[lbauer]

Which version of the VSS Automation Component is the SOS Server using? This may have an impact on SOS performance.

To determine the SourceSafe Automation Component (ssapi.dll) version used by SOS Server, look under this registry key:

HKEY_CLASSES_ROOT\CLSID\{783CD4E4-9D54-11CF-B8EE-00608CC9A71F}\InprocServer32

The value will have the path to the specific ssapi.dll file used by SOS Server. For the version information, locate the ssapi.dll file. Right click on the ssapi.dll file, choose Properties->Version.

[five0.4tluv]

the version is 06.00.9848

another reported how he got back in after he was able to login back in to the SOS server

1. exit sos
2. kill all sos processes ("ps -aef | grep -i sos", then kill any running processes)
3. remove corrupt files "rm -fr ~/.sos/servers"
4. restart sos, log in, refresh file lists, and reset working directories
5. re-get files to update status from "Unknown" (force file transfer and overwrite, might need to copy and save files that are checked out and modified, i didn't have any)

[lbauer]

There's a problem with the VSS 6.0d 98.48 SourceSafe Automation Component. It crashes with concurrent connections. There's a registry edit that can help this:
http://support.sourcegear.com/viewtopic.php?t=10

Let me know if this does not resolve the problem.