[IRCServices] unhappy restart quirks with 5.0.9

[Andrew Church]

     Updates on two of these:

>Moreover, whilst users in the channel access lists were correctly reopped
>on reidentifying on the server coming back up - in every channel a random
>user also acquired an @.  On being deopped, Chanserv once again enforced
>the secureops correctly and refused to let them be reopped. Almost all the
>channels have Options: Topic Retention, Secure Ops.  Even more
>disturbingly, not all users on the channel were able to see the @ that the
>mysteriously-opped user had acquired. (Either in the form of a channel
>mode +o event or similar).

     As I mentioned earlier, this is because of improper assumptions in the
SJOIN code; this bug is fixed for the next release.

>Finally, in the WhatsNew for services v5, I was overjoyed to see:
>
>  + The Services stamp of the last user to identify for a nick is now
>        recorded on disk, removing the necessity to re-identify when
>        Services is restarted.
>
>But so far, when /msg operserv restart works at all - everyone is forced
>to reidentify nonetheless (combined with the quirks listed above).  So I'm
>guessing that there's something going wrong here.

     WFM with Bahamut 1.4.30.  The only thing I can suggest is that your
databases aren't getting saved; using the OperServ QUIT (instead of RESTART
or SHUTDOWN) command or killing Services with any signal other than SIGTERM
will cause Services to quit immediately without saving the databases, so
make sure you aren't using any of those.

  --Andrew Church
    achurch at achurch.org
    http://achurch.org/