Audits, Time messages, midnights not showing on console

[curtismo]

Noticed in the past few days AUD000 and TIM000 messages have stopped showing up on my TTY. Also not seeing Midnights running either.

System is 7.6 HA.

The TTY is set as follows:
TTY 14 SCH MTC BUG 11:38
OVL111 IDLE 0

The last AUD/TIM messages were right before a set of messages with the system bouncing IP connection to a remote MGC cabinet.

Will a swap of processors in LD 135 possibly resolve the issue? Stat of Health and CPU show the system as redundant. Or will I possibly need to manually INI the active processor?

 

[KCFLHRC]

My guess is TTY 14 is a PTY, correct? I would drop the connection and reestablish.

 

[curtismo]

Yes, it is a PTY through a cslogin on a Sig Server. I've done that once but will try again. I have done a PRT AHST in LD 22 and it doesn't show the AUD000/TIM000 either after the point in time the issue started.

 

[KCFLHRC]

Why in the world are you going through the Signal Server to log into the PBX? Why not just go straight to the PBX via Putty?

 

[curtismo]

I've just had better luck with retaining connection to the call server hosts when going through the sig server.

 

[KCFLHRC]

Interesting, problem is when you use a PTY you actually never know for sure which one you are going to hit unless there is just one. One time you may hit 14 the next time you may hit 15.

 

[curtismo]

Like right now the rlogin PuTTY session timed out and dropped off my computer (and will survive CPU swaps). While the session through the SS stays active.

FYI, during the time connected I did not see any AUD000/TIM000 logs. I still have a serial terminal (16 years old but still going) on the CPU TTY but is 8 blocks away from this location; I'll have to check to see whether it is logging to it.

 

[KCFLHRC]

I think the Putty Session times out because of the VxWorks and the SS is Linux, that's my guess anyway. I have seen the same thing. But I never leave any of the PTY's up and connected either. I think I would disable and enable the pty's before going the INI route or swapping CPU's.

 

[curtismo]

Well, for reasons unknown the in-service CPU did an INI a few minutes ago causing the standby CPU to INI and take over control of the MGCs and D-channels.

At least now audits and TIM000 messages are appearing so the problem has corrected itself. Just in working hours.

 

[KCFLHRC]

Sounds like it wasn't happy.

 

[curtismo]

Problem has returned, but looking back through TTY log today is showing an IOD040 error pointing to our ACD printer TTY, and it is disabled (along with the PRT) which is attached to a buffer box. Going through and disabling the RPRT on all of our ACDs (no longer needed) and waiting until after hours to perform a manual INI.

Going back through when AUDs stopped the last time and found the IOD040 message there also. Hopefully disabling all the PRT output will stop this, or figuring out why the buffer box failed.

 

[KCFLHRC]

Look at the Schedule Block also and remove the printer there if not needed.