Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

LSP not taking translations.

Status
Not open for further replies.

SPSANT

Vendor
Jan 25, 2016
22
0
0
US
Good morning all. We have an S8300D - CM Operating system: Linux 2.6.18-400.AV2xen i686 i686
Built: May 19 07:17 2015

Contains: 03.0.124.0
CM Reports as: R016x.03.0.124.0
CM Release String: vcm-016-03.0.124.0
Publication Date: 04 October 2012

list survivable-processor Page 2
SURVIVABLE PROCESSORS
Record Name/ Type Reg Act Translations Net
Number IP Address Updated Rgn

5 atl-svr-phcm LSP y n 10:59 3/16/2018 23
10.17.23.200
No V6 Entry

6 brk-phcm LSP y n 18
10.11.210.210
No V6 Entry



LSP that hasn't updated translations in 2 years. We've removed it, changed the IP address and re-added it in the core. We've patched it and finally we just replaced the blade and reloaded it all over again with a fresh copy of the software. It will register without an issue, but still will not update and save translations. Looking through the system logs, from the LSP, we have found the following:

20180316:095545208:100:LIC(3690):HIGH:[plat_req.c: SockOpen() failure, rc=3]
20180316:095545208:101:LIC(3690):HIGH:[UnixSockMgr::_connect: connect() failed, addr /var/opt/lock/fsync.pipe, errno = 2]
20180316:095545208:102:LIC(3690):HIGH:[fsync_init: failed rc 2 "No such file or directory"]
20180316:095632635:103:prc_mgr(6635):MED:[Release information: R016x.03.0.124.0:drint-18EL:bambooagent:/usr/add-on/field_base1/cm6.3/SP/cm6-124-22619SP.pj@11/10/15 11:12:04 AM]
20180316:095632635:104:prc_mgr(6635):MED:[Shared Memory Segment Sizes: O/P: 0x4a5b8, MCD: 0x500000]

Any ideas of what could be still causing this would be very helpful, especially since we've replaced all the hardware and software? Thank you.
 
From what I can see in the log, the folder is not there, have you tried to create the folder at the linux level?

Have you investigating if there is a PSN related to a bug like this?
What I have done when I have a similar issue, is to create a ticket with AVAYA, so they can investigate about the issue.
 
I have never created a directory in Linux before. Do you know the process for that?
 
I think you need to have root access, do you have that access?

If yes, you need to go to the path where the folder should be created.
Example:

testserver#/var/log
If you need a folder called avaya you will need to use the following commands.

testserver#pwd
This command will show you where you are located.
testserver#pwd
/
Then you need to use cd /var/log
testserver# cd /var/log
testserver# pwd
/var/log

Then to create the folder you will nedd to use the command mkdir avaya
testserver# mkdir avaya
testserver# pwd
/var/log/avaya

This is just an example, you need to check file and directory management in linux.
You can find a lot of information on google about this.
 
Call Avaya if you have support? Under the hood, file sync works via ssh/scp. So, when you 'add' an LSP in a core, it adds that IP to where its going to push the files. When you set up a LSP and you input the filesync addresses and procr of the duplex core, that LSP sets itself up to allow those two specific IP addresses to copy files over to that very special place on the filesystem that contains the translations.

I've seen people mistakenly enter the A&B entries and only get the A right such that the first time CM interchanges and has the B takeover, a particular LSP will never update translations again as long as the B is live.

In your case, it looks like something's gummed up, as in, controlling that /var/opt/lock/fsync.pipe file on the lsp.

 
just curious, have you logged in to the LSP via the web interface, and gone through the steps to set the server role to an LSP? FYI, changing the settings there will cause CM (on that LSP only) to re-boot, but it should come back up and re-register to the core CM...

hope that helps, good luck!!
 
If running SMGR or Third Party certs on CM you must load the trusted root/intermediate certs on the LSP before it will take translations. Assuming it is showing as registered.

 
Would these be the certs that you load on the System Platform? Go Daddy are the certs we've loaded in the past, for the SAL, but we are not using services VM on this LSP. Am I in the right place?
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top