Hello:
I have a second instance of SER running on the same box as the first instance. The first instance is our proxy server the second exists only to integrate SEMS with the failure_route block. It seems that each instance of SER and possibly SEMS too must be started in a specific sequence. Has anyone looked into this?
What I'm seeing is that if the 2nd instance of SER is started first then administrators using serctl experience problems accessing certain functions. Specifically I am seeing a 'ul_dump' does not exist error when issuing the serctl ul show command.
If I start the 1st instance (proxy) of SER first I do not get this error.
Thinking this was due to missing loadmodules in the 2nd config file I copied the loadmodule statements from the 1st config file to the 2nd. I no longer have issues with serctl regardless of the startup sequence but now calls that use to fail over to SEMS are getting a fast busy.
Am I missing something about the startup sequence of 2 instances of SER ?
Thanks,Steve
On Jul 14, 2004 at 09:14, Steve Blair blairs@isc.upenn.edu wrote:
Hello:
I have a second instance of SER running on the same box as the first instance. The first instance is our proxy server the second exists only to integrate SEMS with the failure_route block. It seems that each instance of SER and possibly SEMS too must be started in a specific sequence. Has anyone looked into this?
What I'm seeing is that if the 2nd instance of SER is started first then administrators using serctl experience problems accessing certain functions. Specifically I am seeing a 'ul_dump' does not exist error when issuing the serctl ul show command.
The problem is you start both ser instances with the same fifo, so the ser started the last will always delete the first ser fifo and you will be able to access only the second ser via serctl.
Set fifo=/tmp/some_other_file in one of your ser.cfgs and use SER_FIFO=fifo_name serctl ul_dump to distinguish between the 2 sers.
Andrei
Andrei:
I had tried this suggestion once before without success. I just went back and tried again only to discover that the fifo pointed to by the sems.conf was the proxy fifo. Interestingly messages were being recorded and delivered for some users while the fifo statements were incorrect.
Anyway your suggestion worked. The system seems to behave as expected now.
Thanks
Andrei Pelinescu-Onciul wrote:
On Jul 14, 2004 at 09:14, Steve Blair blairs@isc.upenn.edu wrote:
Hello:
I have a second instance of SER running on the same box as the first instance. The first instance is our proxy server the second exists only to integrate SEMS with the failure_route block. It seems that each instance of SER and possibly SEMS too must be started in a specific sequence. Has anyone looked into this?
What I'm seeing is that if the 2nd instance of SER is started first then administrators using serctl experience problems accessing certain functions. Specifically I am seeing a 'ul_dump' does not exist error when issuing the serctl ul show command.
The problem is you start both ser instances with the same fifo, so the ser started the last will always delete the first ser fifo and you will be able to access only the second ser via serctl.
Set fifo=/tmp/some_other_file in one of your ser.cfgs and use SER_FIFO=fifo_name serctl ul_dump to distinguish between the 2 sers.
Andrei
-
Andrei Pelinescu-Onciul -
Steve Blair