TMR Backup Problem

[CaptainSnort]

I have an intermittent problem backing up the TMR. The Desktop-launched job returns an FRWTD0026E (timeout) error. Neither extending the timeout on the Desktop job, nor performing the job as root makes any difference.

Performing 'top' on the relevant server reveals CPU allocation being given to a tar process, even after failure.

'top' also shows other processes lingering (often duplicated) such as Library_prog1, repository_skel1 and profile_organizer - amongst others. These processes are reported as having been run by tmersrvd.

The environment is TMF 4.1.1 FP6.

Any help greatly appreciated

 

[martincarnegie]

How big is your environment (managednodes and tmrs)? What OS?

Do you also run the wchkdb to verify there is nothing wrong?

The lingering processes almost sound like hung/open admin desktops. This would be normal to be run as tmersrvd.

Also use the tmstat and odstat to look at the processes. The top command does not tell you if Tivoli is having an issue. It is very possible that one managed node is having an issue and it is hanging the backups.

Martin

Martin Carnegie
GulfBreeze Software -

http://www.gulfsoft.com

GulfBreeze Blog -

http://www.gulfsoft.com/blog

 

[martincarnegie]

Oh and BTW, as you may have seen this site is not used much and I just happen to check it today for probably the first time in a month or more.

For faster responses, check out

IBM Devworks Forums

http://www.ibm.com/developerworks/forums/tivoli_forums.jspa

IBM Tivoli Techical Mailing list

http://www-01.ibm.com/software/sysmgmt/products/support/TME10.html

You will probably find more on the email list than devworks for FW/TCM stuff.

Martin Carnegie
GulfBreeze Software -

http://www.gulfsoft.com

GulfBreeze Blog -

http://www.gulfsoft.com/blog

 

[CaptainSnort]

Thanks for your reply Martin,

The environment is comparitively small; single TMR, 2 managed nodes, about 200 endpoints. The host servers are HP-UX. There don't seem to be any general health concerns and wchkdb reports nothing untoward.

In situations such as these shutting down TEC, the database and the TMR before restarting them, seems to provide a workaround - however inelegant and potentially disruptive.

I will have to run tmstat and odstat when the situation next occurs. It seems to happen once a month so it might be as well if updates on this forum are slow!

Thanks for your help; it is much appreciated.