Jump to content
Sign in to follow this  
Guest

trouble creating service on Fedora Core 2

Recommended Posts

Guest

Hello,

 

We have two Fedora Core 2 clients, which were working great with Retrospect 7.0. We upgraded to Retrospect 7.5 (server and clients), and one of them still works. The other one now gives error -540 "trouble creating service" errors.

 

This error happens on the root filesystem. After that, it continues on with other filesystems on the same machine, and works fine.

 

With the standard logging, the only odd message in retroclient.log is:

1140590000: TransStart: waitpid failed with error 10

1140598636: connTcpConnection: invalid code found: 111

 

With logging set to "9" I get a much bigger log file, but I don't know

what I'm looking for (I don't see "invalid code" in it).

 

We tried reverting to the 7.0 client, but it does not change the behavior. Any other ideas for what to try? Apparently, Fedora Core is not supported, although it's essentially the same as RHEL.

Share this post


Link to post
Share on other sites

Quote:

Fedora Core is not supported, although it's essentially the same as RHEL.

 


 

people always say this, but no one seems to know the exact differences. are you suggesting that RHEL is a bag of goods? somehow i doubt this.

 

one question though, when you went back to 7.0 client did the install prompt you for a password? if not, try this kb article:

 

http://kb.dantz.com/article.asp?article=8346&p=2

 

and see if that clears things up. if so, i'd suspect corruption in the retroclient.state file.

Share this post


Link to post
Share on other sites
Guest

Quote:

are you suggesting that RHEL is a bag of goods? somehow i doubt this.

 


 

No, I'm suggesting that the difference is support from Red Hat. I would expect vendor support to not care about whether I get support from Red Hat - not everyone pays Microsoft for Windows support, after all.

 

Quote:

one question though, when you went back to 7.0 client did the install prompt you for a password?

 


 

Yes.

Share this post


Link to post
Share on other sites

Whether it's supported or not doesn't really matter here. This is a community forum. I've looked around for differences between the two and haven't found much. This is the page on the Red Hat site that lists a few bullet point differences, nothing particularly technical:

http://www.redhat.com/en_us/USA/rhel/migrate/whichlinux/

 

Basically the main difference seems to be that RH is thoroughly tested by the company whereas FC is left to the people. So, while FC is not necessarily unstable, it's stability is not guaranteed like RH.

 

I'm sorry I don't have an answer for you, Spawn, but I hope you find one.

Share this post


Link to post
Share on other sites

Quote:

No, I'm suggesting that the difference is support from Red Hat

 


since i find this so interesting i thought i'd check out the fedora site to see what they have to say:

 

http://www.fedorafaq.org/#fedorarhel

 

of note: "Fedora is also much more cutting-edge than RHEL is". i take that too mean there is something different besides support from Red Hat. i've always suspected there is a fundamental difference, but i still have not found a direct comparisson.

 

Quote:

I would expect vendor support to not care about whether I get support from Red Hat

 


 

i don't think EMC really cares about that. there seems to be another issue here.

Share this post


Link to post
Share on other sites
Guest

Is there a way to get more verbose info in the (server operations) log? All I get right now is:

Remaining: 2283 files, 110.1 MB

Completed: 1773 files, 2.6 GB, with 74% compression

 

It would be nice to know what it is dying on, as that might be a clue as to the fix.

Share this post


Link to post
Share on other sites

hi spawn,

 

i would try to up the logging on the client. when you start the retroclient from the rcl script, add in '-log 9'. you can then do a 'rcl stop', 'rcl start', and i believe you'll find the loging in /var/log. you can post an excerpt here.

 

if you want to know all of the options, do a '/usr/local/dantz/client/retroclient --help'.

Share this post


Link to post
Share on other sites
Guest

Thanks waltr, but if you read upthread, you'll see I've already done that. I don't see anything obvious in the client log to post an excerpt of, which is why I was asking about the server operations log.

Share this post


Link to post
Share on other sites

hi spawn,

 

ah, my bad. you can get into the 'secret' prefs by holding down, "ctrl-alt" and then typing "p, p" on the keyboard. look for the top catagory, 'Debug Logging'.

 

i'm thinking you'd want to do 'Networking' to maybe 6 (FWIW, i think the highest is 7 in here--which is not so consistent w/ the clients) but i have _no_ idea how to read this. if you don't see anything there that's obvious, try turning that back down (always a good idea to do one debug item at a time to avoid confusion) and turn up 'Trees and Volumes'. once again, i have no idea of what we will be looking for here. hopefully it will be obvious.

Share this post


Link to post
Share on other sites
Guest

Quote:

i'm thinking you'd want to do 'Networking' to maybe 6 (FWIW, i think the highest is 7 in here

 


 

Been busy with other things, but I shouldn't have set this and left it for a few days - it logs a *ton* of extra stuff, using lots of disk space!

 

Quote:

if you don't see anything there that's obvious

 


 

This isn't obvious to me...

 

necoIncoming: cmd 203 [ 4 bytes]: 1c 02 00 00

necoDispatch: transaction 13: result -540

 

Quote:

turn up 'Trees and Volumes'. once again, i have no idea of what we will be looking for here. hopefully it will be obvious.

 


 

Trying that next, thanks...

Share this post


Link to post
Share on other sites
Guest

This is a little more enlightening:

 

necoCmd: transaction 12: 'VGet' on "retropds"

necoDispatch: transaction 12: result 0

necoCmd: transaction 13: 'FFet' on "retropds"

vlocRDiskDoFileCreate: device number = 0x1

FEncEnd: not started <--- repeats 8 times

vlocRDiskDoFileCreate: device number = 0x1

File "/var/spool/mqueue/dfk2PCBa3Z010966": can't read, error -1101 (file/directory not found)

necoDispatch: transaction 13: result -540

 

This is a mail server, so of course the mail queue contents are going to change. This sure looks like a bug in Retrospect 7.5 - version 7.0 would complain at the end about the files that had "gone missing" but it wouldn't abort the backup!

Share this post


Link to post
Share on other sites

Hi

 

Does the 540 occur every time you get an 1101 error or just when backing up the mailserver files?

 

Thanks

Nate

Share this post


Link to post
Share on other sites
Guest

Not getting the 540 error on any other machines - I'll have to turn the logging on again to see if there are additional 1101 errors.

Share this post


Link to post
Share on other sites
Guest

Quote:

Does the 540 occur every time you get an 1101 error or just when backing up the mailserver files?

 


 

Yes - this is with IMAP data now:

 

File "/home/andrewb/Maildir/.Trash/new/1143830367.P28346Q0M276597.mail.scitechsoft.com:2,a": can't read, error -1101 (file/directory not found)

vlocRDiskDoFileCreate: device number = 0x1

File "/home/andrewb/Maildir/cur/1143830233.28562_2.mail.scitechsoft.com:2,STa": can't read, error -1101 (file/directory not found)

necoDispatch: transaction 13: result -540

Share this post


Link to post
Share on other sites

hi spawn,

 

Quote:

This sure looks like a bug in Retrospect 7.5

 


 

i don't know. client doesn't work on an unsupported OS. that doesn't really sound like a bug.

Share this post


Link to post
Share on other sites
Guest

The problem is happening on the server side, rather than the client side - so whether the client is "supported" or not will not make a difference here.

 

If I went to all the trouble of setting up a "supported" client (i.e. RHEL), would this bug be more likely to get fixed?

Share this post


Link to post
Share on other sites

hi spawn,

 

Quote:

The problem is happening on the server side, rather than the client side - so whether the client is "supported" or not will not make a difference here.

 


 

i disagree.

 

Quote:

If I went to all the trouble of setting up a "supported" client (i.e. RHEL), would this bug be more likely to get fixed?

 


 

yes, i think so. there is only so much that can be done on a forum board. at this point i'd like to suggest you call EMC Technical Support about the issue, but since they don't support your client i can't really do that.

 

so what are the options? live with the problem? i don't think anyone else on the forums can help you at this point.

Share this post


Link to post
Share on other sites
Guest

Quote:

i'd like to suggest you call EMC Technical Support about the issue, but since they don't support your client i can't really do that.

 


 

Today, phone support told me that this is a known issue. Hopefully, a fix will be available in the near future.

Share this post


Link to post
Share on other sites

hi spawn,

 

did you tell them you were using fedora? you may not have the same issue they have logged. i'd hate to see you wait for a 'fix' that doesn't address your particular situation.

 

also, if you did tell them that you are using fedora, any word on when/if they plan to fully support it? inquiring minds want to know.

Share this post


Link to post
Share on other sites
Guest

Quote:

did you tell them you were using fedora?

 


 

Yes.

 

Quote:

any word on when/if they plan to fully support it?

 


 

I don't think that is part of the plan.

Share this post


Link to post
Share on other sites

Though I can't confirm that it's the same problem that you're seeing since FC2 is unsupported, there have been reports of "-540 trouble creating service" for users since upgrading to Retrospect 7.5 backing up various distros. We are currently investigating this issue.

Share this post


Link to post
Share on other sites

Hi Spawn,

 

If the client worked fine in 7.0 and started getting error -540 with 7.5, I would expect this to be the same bug affecting other *nix clients. I don't know what causes this problem yet, but so far I have seen it on a gammut of supported and unsupported (but previously working) operating systems including:

 

Solaris

CentOS

Debian

RHEL 3

and my own Fedora 5 system.

 

As soon as a resolution is found I'll be sure to post here.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×