Opera 3 SQL SE - The Pegasus Opera Service is Unreachable

alex

Hi all,

We have a site that has been running SQL SE for a while now. They are currently running version 2.92.00 and will be upgraded to v2.93.01 soon. However, this particular issue spans multiple previous versions so is not limited to 2.92.00.

This site works unusual hours and they start work very early in the morning, usually between 2am and 4am. Sometimes, when they come in at that time the first person who tries to log into Opera will receive the message 'the Pegasus opera service is unreachable'. We've now given them a batch file to run which restarts the service on the server and once this has run they can log in and work normally. It doesn't always occur at this time however, there is no pattern to the days/times and it can happen during the day as well.

They were getting this issue regularly until we installed an upgrade that was meant to fix this issue - v2.91.02. However, the issue has not completely gone away.

I've scoured the SAM logs and SQL logs and can't find anything helpful. The Windows event viewer just seems to log when the service is restarted.

They do have another service which is linked and polls the Opera service every couple of minutes to check if any data needs importing/exporting. The event viewer reports an issue under this service (PODFather) when it can't 'ping' the Opera service. The Opera service is still showing as running when this happens but it's like it's stopped responding.

Has anyone else come across anything similar or has any ideas about where to start looking to get this resolved? The issue probably occurs on average once a week now, sometimes a bit more often and sometimes less. Their IT company want the issue resolved so the batch files to restart the service can be removed from the users desktops (they say this is a security risk).

Any pointers anyone can give would be gratefully received.

Thanks,

Alex

FordUS_ship_req.pdf

colin-avey

Hi Alex,

This is a long shot, based on an issue we had with another piece of software.  Essentially, something was consuming the available TCP/IP ports until various services stopped being able to communicate.

We use the following batch file to collect stats on the ports usage.  It dumps a load of txt files into a folder createdin E:Work with the date and time as the name. mwes.exe is the suspect program in the example below.

It needs to be run as Administrator before restarting the service. You can run it again directly after to see of 1000s of ports have been released.

HTH

Colin

@echo off
REM See stackoverflow.com/.../1143274
FOR /f %%a IN ('WMIC OS GET LocalDateTime ^| FIND "."') DO SET DTS=%%a
SET DateTime=%DTS:~0,4%-%DTS:~4,2%-%DTS:~6,2%_%DTS:~8,2%-%DTS:~10,2%-%DTS:~12,2%
echo %DateTime%

MD E:Work%DateTime%

netstat -ano >E:Work%DateTime%Stats.txt
netstat -anob >E:Work%DateTime%StatsB.txt
netstat -an | find /c "TIME_WAIT" >E:Work%DateTime%StatsTW.txt
netstat -an | find /c "ESTABLISHED" >E:Work%DateTime%StatsE.txt
netstat -anob | find /c "mwes.exe" >E:Work%DateTime%StatsMWES.txt
netsh int ipv4 show dynamicport tcp >E:Work%DateTime%Ports.txt
netsh int ipv4 show dynamicport udp >>E:Work%DateTime%Ports.txt
netsh int ipv6 show dynamicport tcp >>E:Work%DateTime%Ports.txt
netsh int ipv6 show dynamicport udp >>E:Work%DateTime%Ports.txt