Jump to content

7.6 Linux client broken


Recommended Posts

I was pleased to see that error -540 is supposed to finally be fixed in version 7.6 - we have been running a separate 7.0 install to back up our Linux systems.

 

However, the 7.6 Linux client is completely broken (at least on Centos 5.x); I get a bunch of messages like this:

 

pmcTrans: requested 158: expected code 216 and 218 bytes, got 202 and 4 bytes

connTcpConnection: invalid code found: 158

 

Fortunately, the 7.5 Linux client seems to continue to work correctly.

 

Link to comment
Share on other sites

What steps did you take to install the new client? Did you uninstall the old client first? Did you step the retroclient process before doing the install?

 

Are you trying to use the Java GUI?

 

What steps are you taking to reproduce the error messages?

Link to comment
Share on other sites

What steps did you take to install the new client? Did you uninstall the old client first? Did you step the retroclient process before doing the install?

 

I just installed the RPM over the old one. When that gave me the errors, I uninstalled and tried installing it again. When I run "service rcl status" I get the error messages.

 

Are you trying to use the Java GUI?

 

No.

 

Link to comment
Share on other sites

I can pitch in here a little bit..

 

I installed the client on Fedora Core 8, and it works for backup. The problem seems to be when I go to check the client status, and retrocpl is invoked.

 

When I try to check the status of the client, I get this:

 

[root@inara download]# /usr/local/dantz/client/retrocpl

1215377555: pmcTrans: requested 158: expected code 216 and 218 bytes, got 202 and 4 bytes

Retrospect client is not running

[root@inara download]#

 

Ah, but it is running:

 

[root@inara ~]# ps -ef | grep retro

root 1868 1 0 Jun28 ? 00:11:53 /usr/local/dantz/client/retroclient -ip 192.168.0.63 -daemon

root 27236 1868 8 17:01 ? 00:00:09 retropds.23

root 27254 26298 0 17:03 pts/1 00:00:00 grep retro

 

Okay, so it's running but the retrospect control panel can't figure that out. So what's going on?

 

Doing a system trace on retrocpl tells me that it's something network-protocol-related that it doesn't like.

 

Here's what I see.

 

First, retrocpl connects to localhost port 497:

 

socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3

connect(3, {sa_family=AF_INET, sin_port=htons(497), sin_addr=inet_addr("127.0.0.1")}, 16) = 0

 

Then, it does some handshake over the connection it just opened, and fails:

 

send(3, "\0e\0\0\0\0\0\0\0\0\0\0", 12, 0) = 12

recv(3, "\0\311\0\0\0\0\0\332\0\0\0\0", 12, 0) = 12

recv(3, "\0\22\0\0\1\0\0\0\1\0\0\0\0\4\0\0\0\1\2\7\0\0\0\0\0\0\0\0\0\0\0\0"..., 218, 0) = 218

send(3, "\0\236\0\0\0\0\0\0\0\0\0\0", 12, 0) = 12

recv(3, "\0\312\0\0\0\0\0\4\0\0\0\0", 12, 0) = 12

recv(3, "\0\0\2(", 4, 0) = 4

time(NULL) = 1215377415

write(2, "1215377415: ", 121215377415: ) = 12

write(2, "pmcTrans: requested 158: expecte"..., 78pmcTrans: requested 158: expected code 216 and 218 bytes, got 202 and 4 bytes

) = 78

 

What's the client sending back to the control panel over localhost:497 that is causing it to fail here?

 

\marc

 

Edited by Guest
Link to comment
Share on other sites

I guess I am confused and/or unclear on this..

 

This is not using the GUI per se. It is the retrocpl binary, but when called without any arguments, it is supposed to check the status of the daemon and exit (as per the manpage). The GUI is never launched.

 

In fact, retrocpl is the command that is called from the /etc/init.d/rcl script.

 

Thus, if you do:

 

# service rcl status

 

it ultimately calls:

 

status)

$CLIENTDIR/retrocpl

 

..which gives you the error above:

 

[root@inara ~]# service rcl status

1215407027: pmcTrans: requested 158: expected code 216 and 218 bytes, got 202 and 4 bytes

Retrospect client is not running

 

And it reports the client is not running when, in fact, it is.

 

Again, this is NOT running the GUI. And, this command is failing when it is doing its handshake with the Retrospect client daemon.

 

So I'm wondering -- what is that error, and why is it failing?

 

Are you saying that the entire retrocpl binary is broken in 7.6 and that, inadvertently, this breaks the status check command?

 

Thanks again!

 

\marc

Edited by Guest
Link to comment
Share on other sites

It sounds like the old retroclient never got killed before installing the new client or you are somehow still using an old retroclient running.

 

We tested the new retrocpl under Red Hat and did not see these issues.

 

Maybe try to kill the Retroclient processes, uninstall and then try a reinstall. If this doesn't work, then we get try to get some debug logging to see more of about this failure.

Link to comment
Share on other sites

You are correct!

 

I'm not really sure how it happened, but the old Retrospect daemon had never stopped.

 

I did a manual kill -9 on the old client, wiped any vestiges of the old Retrospect client off the machine, and did a fresh reinstall.

 

That came up without issue.

 

All is good here. Thanks for your suggestions and help!!

 

\marc

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...