[IRCServices] unhappy restart quirks with 5.0.9

[Arathorn]

Hi,

I just upgraded from 4.5.43 to 5.0.9 (at last!) for use with unreal 3.2b14
and have so far been very pleased with the transition.  After a few days
of use I've found a few unexpected pieces of behaviour which I'm confused
about:

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

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 ;)

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

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.

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 all happening on a dual PIII 1.26GHz box running Debian Woody with
a 2.4.18 kernel; everything compiled with gcc 2.95.4 (unreal compiled with
not default linux threads, fwiw).  It's all worked perfectly with
IRCServices 4.3.x, 4.5.x coupled with df467 and unreal 3.1.x on precisely
the same hardware.

Any help would be very much appreciated;

cheers,

A.

_________________________________________
Matthew Hodgson   arathorn at theonering.net
  Arathorn: Co-Sysadmin, TheOneRing.net®