[IRCServices] unhappy restart quirks with 5.0.9

[Andrew Church]

     I'm technically not supposed to be on the Internet right now (doctor's
orders), but off the top of my head:

>Firstly, on an /msg operserv shutdown, services SQUITs from the ircd - but
>then on almost all occasions the binary continues to run, and will not be
>killed by any signal short of a KILL (-9).

     Can you look up exactly where this is occurring?  (Use gdb to attach to
the process when it's in the "hung" state.  If you're not familiar with gdb,
there are at least a couple other people on this list who can help you.)

>On a related note, /msg operserv restart normally fails in precisely the
>same manner - but on the one occasion that it came straight back up, all
>registered channels with a +k mode in their modelock had mysteriously lost
>their +k and key.  Which was a bit of a pain ;)

     Corrupted database?  That's the only possibility that comes to mind.
Are you sure your CPU and memory aren't acting up?  (Try a tool like
memtest86 [http://www.memtest86.com/].)

>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 @.

     That would probably be the result of CSSetChannelTimes.  A bug (or
feature?) in Unreal requires a +/-o or similar mode change in order to
update the channel's creation time.  Since the first user to join a channel
always gets +o anyway, Services assumes that it's safe to send another +o
for that first user, since it will later process the +o from the remote
server and deop the user properly.  I don't think the case of a netjoin
with multiple users on a channel is handled properly, though.  I'll take a
look when I'm off vacation; for now, try turning off CSSetChannelTimes.

>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.

     This would happen if your databases were not saved after the NickServ
IDENTIFY command.

>On a final possibly unrelated note, I've also been getting
>
>[Mon Feb  3 23:23:24 2003] - select irc.theonering.net[127.0.0.1]:Bad file 
>descriptor
>
>error messages popping up in Unreal's ircd.log every 2-16 hours or so.
>As services is the only thing connected to a fd on 127.0.0.1, I'm
>wondering if there's a connection here to the above problem.

     This is an Unreal bug, though it may be triggered by something in
Services.  You'd have to ask the Unreal people for more details.

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