1 Reply Latest reply on Sep 11, 2013 9:48 PM by brad

    Pharos Signup service crashing constantly

    brad Pioneer

      So, we have this problem that we've encountered today, without any changes being made to the system - the Pharos SignUp service stops 15-20s or so after it is started. What we have tried thus far to resolve it is:

       

      • Restart ALL Pharos services on both the database server and the signup/print server
      • Reboot the signup/print server
      • Investigated Event Logs, Pharos SIP logs, etc. The Event logs were about as useful as most Microsoft logs generally are - it told us the Signup service had crashed. The SIP logs did have a few errors in right before the logs stop each time, but I couldn't make much of it - this has been referred to our Support vendor to investigate ([06/Sep/13 10:47:17:902 P23440 T23380C00001 e] Socket 448 reply error: An established connection was aborted by the software in your host machine)

       

      In the mean-time, users have, thankfully, been able to at least get onto the machines to access the internet and our catalogue (we're a public library service), by way of the offline mode that our internet PCs are configured for. However, each time the signup service tries to restart itself, they all get booted off again.

       

      Does anyone have any suggestions on what it is we can look at/for in order to try and resolve this issue, while we wait to hear back from our support vendor?

        • Re: Pharos Signup service crashing constantly
          brad Pioneer

          OK. Reporting back, on the off chance someone comes across a similar issue, now that we've resolved it this morning.

           

          The problem turned out to be that our login script was not handling bad data well, causing iplgnext.exe to crash multiple times which in turn was bringing down the Signup service. It appears the login process keeps a temporary store of requests, because restart the service and/or the server had no effect.

           

          In order to stop this from happening, we needed to drop the service and remove the login script from it. Start it back up and let it run. Drop it again and re-attach the login script, and start it back up again, at which point the service was back to behaving itself.

          Will now be investigating the script to see if it's possible (and easy!) to modify the script to strip any non-alphanumeric characters from input to the script prior to any processing. Will also be taking a look to see if either of the two versions above us (we're on 8.2) offer any improvement in that area.