software/!RELEASES/ircservices/achurch.org/services/lists/ircservices/2003/003552.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
   2 <HTML>
   3  <HEAD>
   4    <TITLE> [IRCServices] unhappy restart quirks with 5.0.9
   5    </TITLE>
   6    <LINK REL="Index" HREF="index.html" >
   7    <LINK REL="made" HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20unhappy%20restart%20quirks%20with%205.0.9&In-Reply-To=Pine.LNX.4.44L0.0302051649120.19589-100000%40foxtrot.siarch.net">
   8    <META NAME="robots" CONTENT="index,nofollow">
   9    <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
  10    <LINK REL="Previous"  HREF="003547.html">
  11    <LINK REL="Next"  HREF="003556.html">
  12  </HEAD>
  13  <BODY BGCOLOR="#ffffff">
  14    <H1>[IRCServices] unhappy restart quirks with 5.0.9</H1>
  15     <B>Andrew Church</B>
  16     <A HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20unhappy%20restart%20quirks%20with%205.0.9&In-Reply-To=Pine.LNX.4.44L0.0302051649120.19589-100000%40foxtrot.siarch.net"
  17        TITLE="[IRCServices] unhappy restart quirks with 5.0.9">achurch at achurch.org
  18        </A><BR>
  19     <I>Fri Feb  7 12:19:00 PST 2003</I>
  20     <P><UL>
  21         <LI>Previous message: <A HREF="003547.html">[IRCServices] unhappy restart quirks with 5.0.9
  22 </A></li>
  23         <LI>Next message: <A HREF="003556.html">[IRCServices] unhappy restart quirks with 5.0.9
  24 </A></li>
  25          <LI> <B>Messages sorted by:</B>
  26               <a href="date.html#3552">[ date ]</a>
  27               <a href="thread.html#3552">[ thread ]</a>
  28               <a href="subject.html#3552">[ subject ]</a>
  29               <a href="author.html#3552">[ author ]</a>
  30          </LI>
  31        </UL>
  32     <HR>
  33 <!--beginarticle-->
  34 <PRE>     I'm technically not supposed to be on the Internet right now (doctor's
  35 orders), but off the top of my head:
  36
  37 &gt;<i>Firstly, on an /msg operserv shutdown, services SQUITs from the ircd - but
  38 </I>&gt;<i>then on almost all occasions the binary continues to run, and will not be
  39 </I>&gt;<i>killed by any signal short of a KILL (-9).
  40 </I>
  41      Can you look up exactly where this is occurring?  (Use gdb to attach to
  42 the process when it's in the &quot;hung&quot; state.  If you're not familiar with gdb,
  43 there are at least a couple other people on this list who can help you.)
  44
  45 &gt;<i>On a related note, /msg operserv restart normally fails in precisely the
  46 </I>&gt;<i>same manner - but on the one occasion that it came straight back up, all
  47 </I>&gt;<i>registered channels with a +k mode in their modelock had mysteriously lost
  48 </I>&gt;<i>their +k and key.  Which was a bit of a pain ;)
  49 </I>
  50      Corrupted database?  That's the only possibility that comes to mind.
  51 Are you sure your CPU and memory aren't acting up?  (Try a tool like
  52 memtest86 [<A HREF="http://www.memtest86.com/].">http://www.memtest86.com/].</A>)
  53
  54 &gt;<i>Moreover, whilst users in the channel access lists were correctly reopped
  55 </I>&gt;<i>on reidentifying on the server coming back up - in every channel a random
  56 </I>&gt;<i>user also acquired an @.
  57 </I>
  58      That would probably be the result of CSSetChannelTimes.  A bug (or
  59 feature?) in Unreal requires a +/-o or similar mode change in order to
  60 update the channel's creation time.  Since the first user to join a channel
  61 always gets +o anyway, Services assumes that it's safe to send another +o
  62 for that first user, since it will later process the +o from the remote
  63 server and deop the user properly.  I don't think the case of a netjoin
  64 with multiple users on a channel is handled properly, though.  I'll take a
  65 look when I'm off vacation; for now, try turning off CSSetChannelTimes.
  66
  67 &gt;<i>Finally, in the WhatsNew for services v5, I was overjoyed to see:
  68 </I>&gt;<i>
  69 </I>&gt;<i>  + The Services stamp of the last user to identify for a nick is now
  70 </I>&gt;<i>        recorded on disk, removing the necessity to re-identify when
  71 </I>&gt;<i>        Services is restarted.
  72 </I>&gt;<i>
  73 </I>&gt;<i>But so far, when /msg operserv restart works at all - everyone is forced
  74 </I>&gt;<i>to reidentify nonetheless (combined with the quirks listed above).  So I'm
  75 </I>&gt;<i>guessing that there's something going wrong here.
  76 </I>
  77      This would happen if your databases were not saved after the NickServ
  78 IDENTIFY command.
  79
  80 &gt;<i>On a final possibly unrelated note, I've also been getting
  81 </I>&gt;<i>
  82 </I>&gt;<i>[Mon Feb  3 23:23:24 2003] - select irc.theonering.net[127.0.0.1]:Bad file
  83 </I>&gt;<i>descriptor
  84 </I>&gt;<i>
  85 </I>&gt;<i>error messages popping up in Unreal's ircd.log every 2-16 hours or so.
  86 </I>&gt;<i>As services is the only thing connected to a fd on 127.0.0.1, I'm
  87 </I>&gt;<i>wondering if there's a connection here to the above problem.
  88 </I>
  89      This is an Unreal bug, though it may be triggered by something in
  90 Services.  You'd have to ask the Unreal people for more details.
  91
  92   --Andrew Church
  93     <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">achurch at achurch.org</A>
  94     <A HREF="http://achurch.org/">http://achurch.org/</A>
  95 </PRE>
  96
  97 <!--endarticle-->
  98     <HR>
  99     <P><UL>
 100         <!--threads-->
 101         <LI>Previous message: <A HREF="003547.html">[IRCServices] unhappy restart quirks with 5.0.9
 102 </A></li>
 103         <LI>Next message: <A HREF="003556.html">[IRCServices] unhappy restart quirks with 5.0.9
 104 </A></li>
 105          <LI> <B>Messages sorted by:</B>
 106               <a href="date.html#3552">[ date ]</a>
 107               <a href="thread.html#3552">[ thread ]</a>
 108               <a href="subject.html#3552">[ subject ]</a>
 109               <a href="author.html#3552">[ author ]</a>
 110          </LI>
 111        </UL>
 112
 113 </body></html>