Error on Call Manager 7

[oasislegal]

Hi all we have 2 Call Manager 7.1.2.31900-1 boxes. Recently we had a power outage and the servers were not shut down properly. One remaining issue we are having trouble resolving is this error below. It appears in the logs every 15 seconds or so. Any ideas on how to resolve it? I think it might be a corrupt file or file permissions but I can't access the real unix shell so how does one fix this sort of thing?

Cisco CallManager: Not able to create Trace path /var/log/active/cm/trace/dbl/sdi/ccm/. Ensure that the path is valid and the application user has appropriate security settings for this path"

Thanks much in advance

[Manish Gogna]

Hi,

In case of unclean shutdowns like in a power outage there is always a possibility of file system corruption. You should run the recovery cd to fix any file system errors. You can download the recovery iso from here and burn it on a dvd

http://software.cisco.com/download/release.html?mdfid=282421166&flowid=45895&softwareid=282074294&release=7.1%285b%29&relind=AVAILABLE&rellifecycle=&reltype=latest

HTH

Manish

[oasislegal]

Hello Manish. Thanks for your reply. I do have the recovery image and we tried it twice on this server. It did not correct the problem. I was hoping there was some other tool or method we could use to correct this problem.

[Manish Gogna]

Hi,

It looks like a rebuild is needed. Please check the following

https://tools.cisco.com/bugsearch/bug/CSCth53322/?reffering_site=dumpcr

Symptom:

1)System had a non-graceful shutdown.

2)System is in a running state but part of the file system is corrupt causing certain features to fail.

Conditions:

Server goes down non-gracefully for any reason.

A  non-graceful shutdown is any time the server is powered down by means  other than through the GUI or CLI command "utils system shutdown"

Cisco recommends a UPS in the release notes already to avoid this.

Workaround:

Rebuild  the server if their is a non-graceful shutdown regardless if the  recovery disk was required. As any non-graceful shutdown can cause file  system corruption even if no symptoms are seen immediately.

HTH

Manish

[oasislegal]

Wow... thats an (interesting? overboard?) fix. One corrupted file/folder, so dump the whole server and start over?

[Manish Gogna]

There is no guarantee that this is the only corrupted file / folder, there may be others as well which are not yet identified or visible. Because this is cucm 7.1.2 so even TAC may simply ask you to either upgrade to a higher supported version or a rebuild based on the bug, yoou may open a case with them as recovery disk has already been tried.

Manish

[oasislegal]

In this situation, is it advisable to do a backup, rebuild the server, then restore the backup? Or, just rebuild the server and then replicate the database to it from the other node without restoring a backup. I don't want to restore the backup to the new server if it's possible that it might re-introduce problems or corrupted files to the new build.

We just ran a backup on each node, and each one said successful. Based on that, can we trust that we have good data integrity in the backup files?

[Manish Gogna]

If the affected server is a subscriber then you can go for a rebuild and let the database replicate from the Publisher. You will need to install any specific firmware files, custom background images / ringtons etc in that case on the subscriber as they are not copied over by replication. In case its a Publisher that is affected then you will need to reinstall and use a good known backup.

HTH

Manish

[oasislegal]

Since this was a power outage, both servers are affected. The one exhibiting log errors is the subscriber. But as you say there may be issues that have not shown up yet in one or both servers.

Unfortunately we do not have a recent backup that was taken before the power outage.