SOS Command Line Client Return Codes seemed to have changed.

[BattelleV]

We have been experiencing some errors with the behavior of the SOS command line client.

I am paraphrasing from some emails that our IT staff and an engineer have been experiencing.

To the best of our knowledge, the SOS client did not change, the SOS server did not change. The SOS server was rebooted and still the aberrant behavior was observed in that the return codes from certain commands seemed to have changed.

The SOS documentation for the SOS Command Line client (http://www.sourcegear.com/sos/manual/soscmd.txt) says that a call to the command line client that is successful will return an exit code of 0, and an exit code of -1 on failure (the -1 will end up being mapped to 255).

It seems that these return codes are still being used for most invocations of the SOS Command Line client, but
what is now happening is that for some SOS commands the SOS Command Line client is returning an exit code of 255 for success, and an exit code of 0 for failure.

So far this morning, I have only been able to confirm this behavior on the "GetProjectTree" command to SOS.
I've worked around it so far, but I cannot understand why it should have changed.
Were there any changes on the SOS Server side or the VSS Server side this weekend?

-----Original Message-----
Franco,
I don't think anything has changed on the dev server (.29). Do you consistently have the same issue when using the GetProjectTree command? It sounds like you are only having the problem on some Linux boxes but not all?

The only thing I can think of is if the SOS server is in a bad state and either the service or the server needs to be restarted. If it seems to get worse I can do this today, just let me know when would be a good time. Otherwise I can reboot the server tomorrow morning and see if that resolves any issues.

Thanks
Dwight
-----Original Message-----
Dwight,
I consistently see the same behavior of the SOS Command Line client when running the GetProjectTree command, from all of the linux boxes where I have tried it.

The last time I can verify that GetProjectTree was working would have been early Friday morning (1AM).
It is possible that it may have already started sometime Friday, but I didn't notice it because I don't necessarily run that command very often. It is definitely run once a night by the automated build scripts that run at 1AM on the server.

I'll keep an eye on it and let you know if I see a change.

Franco

--
Franco Barber

-----Original Message-----
From: Mickley, Dwight J
To: Barber, Franco


I rebooted the dev box (107.29). Let me know if the issue is still happening.

Thanks
Dwight

Dwight,
Yes, it still is doing it today. Again I tried from two different linux boxes.
GetProjectTree is returning the wrong return code.
GetProject (for example) is returning the right code.

As I go along my work, if I discover any more commands that return the wrong codes I'll let you know.
Franco

--
Franco Barber

[lbauer]

What version of SourceOffSite client and server are you using? Are you using the SourceOffSite UNIX commandline client?

[BattelleV]

The client is 4.2 standard edition and encrypted editions

The server is also 4.2

We are using the Linux Command Line client for Fedora.

[lbauer]

We made changes to the return codes SOS 4.x. Is it possible you were previously using the SOS 3.5 Unix client?

[jclausius]

I traced through some of the CLC code. For a command like GetProjectTree, the CLC will return a positive number for any success. That return code is basically the number of bytes received from SOS client after the send of the request. This byte stream could be any kind of number 100, 255, 500, 875, 1000.

If there was some kind of error in the response, it appears as if a -1 will be returned.

Is it possible the response is a valid 255, and whatever is parsing the output cannot distinguish this from -1?

[BattelleV]

Your description about what you are returning disagrees with standard documentation regarding Unix process exit statuses.

You can't really return a negative number or value greater than 255 in a Unix process. The exit status is limited to an 8 bit unsigned value.

For reference the man page for bash (search exit status) which explains the exit statuses that Bash can make available to a script or user when a process exits
http://www.gnu.org/software/bash/manual/bashref.html
The wait man page explains the exit statuses to a program that executes a process.
http://linux.die.net/man/2/wait

Our problem isn't so much the value of the return code although that is interesting, what we can't understand is why the exit status would change over the weekend when we didn't change our kernel, the client, the server or VSS.

[jclausius]

My bad... I was looking at the line which set's nRetVal = ExecuteCommand(). Although you can return any kind of int, it will be unsigned and squashed to 0 - 255.

Within main(), nRetVal = ExecuteCommand() which executes the command specified on the command line.

At the end of main() is the following snippet:

Code: Select all

if (theRequest.bOldReturnCodes)
   return nRetVal;

/* error?  return -1 */
if (nRetVal >= 400 || nRetVal < 0)
   return -1;

return 0;
}

Notice, (theRequest.bOldReturnCodes). If the "oldreturncodes" was specified, then the actual return code would be returned. In the example, if nRetVal was set to 255 from ExecuteCommand, then the CLC would actually return 255. Without that specifier, it looks as if the CLC will return -1 or 0.

What is strange is if the return value is >= 400 bytes, then the CLC will return -1. I'll do some more digging here.

[BattelleV]

Jeff,

Thanks for looking into it. We aren't using the old return codes. We did a little experimental test here and found that indeed the directory listing we were getting compressed was greater than 400 bytes (433 bytes). The code returned was -1 (255). When we did a test on a new database with fewer files it returned 0 since the size was 100. We understand what is happening; we would be very curious to learn why it is happening (the logic behind the conditional being there) and what implications it has for our project (our project directory listing is only expected to get bigger).

[jclausius]

Right now, this seems to be a bug. It looks like at one time, the CLC was returning the SOS Protocol return code for the CLC, where anything >= 400 is an actual error.

So the question is, is the return from ExecuteCommand() returning the SOS protocol return code or the bytes received. Again, my analysis was just from "looking" at the code, not debugging it. More research will be needed, and I'll log a work-item to make sure it gets done.

My guess is the code snippet from the earlier post could be replaced with:

Code: Select all

if ( !theRequest.bOldReturnCodes )
{
   /* error?  return -1 */
   nRetVal = (nRetVal >= 0) ? 0 : -1;
}

return nRetVal;

I don't have a work around for this. However, if you cannot wait for an upcoming fix, you could contact Linda at support dot sourcegear dot com, and she can provide you with the *NIX source code in which you could build your own client with the fix.