Loading ...
Sorry, an error occurred while loading the content.

Re: [dansguardian] Doesn't all stop when stopped!

Expand Messages
  • Philip Allison
    ... No, it s not - I just found the same problem myself yesterday. ... Those would be the logging process and the URL caching process. There s a bug in 2.9.1
    Message 1 of 4 , Dec 1, 2005
    View Source
    • 0 Attachment
      On Wed, 2005-11-30 at 18:53 +0000, nealcartwright wrote:
      > Sorry if this is answered elsewhere - I've looked but can't find...

      No, it's not - I just found the same problem myself yesterday.

      > They're always the first two PIDs after the master process.
      > Every time DG is restarted there are another two.
      > 'killall' and 'kill' don't touch them, only 'kill -9'
      > The childspawning settings in dansguardian.conf make no difference -
      > always the two.

      Those would be the logging process and the URL caching process. There's
      a bug in 2.9.1 (and possibly earlier, I can't say exactly when it was
      introduced) that causes the main parent process to crash mid way through
      killing the child processes, always leaving at least these two hanging.

      This has been fixed for the next alpha, which could be out at any time
      now. :)

      --
      Philip Allison
      Programmer
      SmoothWall Ltd. - http://www.smoothwall.net/

      This email and any attachments transmitted with it are confidential to
      the intended recipient(s) and may not be communicated to any other
      person or published by any means without the express permission of
      SmoothWall Limited.

      Any views expressed in this message are solely those of the author.
      See:
      http://www.smoothwall.net/emailnotice.html for the full text of this
      notice.
    • nealcartwright
      ... What s really odd is that today (after leaving DG running overnight) stopping it works fine - no processes left running. I d be guessing it was busy doing
      Message 2 of 4 , Dec 1, 2005
      View Source
      • 0 Attachment
        --- In dansguardian@yahoogroups.com, Philip Allison
        <philip.allison@s...> wrote:
        >
        > On Wed, 2005-11-30 at 18:53 +0000, nealcartwright wrote:
        > > Sorry if this is answered elsewhere - I've looked but can't find...
        >
        > No, it's not - I just found the same problem myself yesterday.
        >
        > > They're always the first two PIDs after the master process.
        > > Every time DG is restarted there are another two.
        > > 'killall' and 'kill' don't touch them, only 'kill -9'
        > > The childspawning settings in dansguardian.conf make no difference -
        > > always the two.
        >
        > Those would be the logging process and the URL caching process. There's
        > a bug in 2.9.1 (and possibly earlier, I can't say exactly when it was
        > introduced) that causes the main parent process to crash mid way through
        > killing the child processes, always leaving at least these two hanging.
        >
        > This has been fixed for the next alpha, which could be out at any time
        > now. :)
        >
        > --
        > Philip Allison
        > Programmer
        > SmoothWall Ltd. - http://www.smoothwall.net/
        >
        > This email and any attachments transmitted with it are confidential to
        > the intended recipient(s) and may not be communicated to any other
        > person or published by any means without the express permission of
        > SmoothWall Limited.
        >
        > Any views expressed in this message are solely those of the author.
        > See:
        > http://www.smoothwall.net/emailnotice.html for the full text of this
        > notice.
        >

        What's really odd is that today (after leaving DG running overnight)
        stopping it works fine - no processes left running. I'd be guessing it
        was busy doing some initialising in the background & that my being
        hasty (start, stop, start,stop) was triggering/causing the problem. Or
        maybe I was altering dansguardian.conf while it's running?

        Neal
      • Philip Allison
        ... Altering the config while it s running shouldn t be a problem - it only gets read in on startup, or after issuing -r or -g. Also, -q only consistently
        Message 3 of 4 , Dec 1, 2005
        View Source
        • 0 Attachment
          > What's really odd is that today (after leaving DG running overnight)
          > stopping it works fine - no processes left running. I'd be guessing it
          > was busy doing some initialising in the background & that my being
          > hasty (start, stop, start,stop) was triggering/causing the problem. Or
          > maybe I was altering dansguardian.conf while it's running?

          Altering the config while it's running shouldn't be a problem - it only
          gets read in on startup, or after issuing -r or -g. Also, -q only
          consistently fails if someone's actually browsing at the time of the
          shutdown - i.e. if some of the child processes are busy. If they aren't
          busy, there crash isn't triggered (it's a double free issue). :)

          The primary reason this bug didn't get caught earlier is that with the
          next alpha's persistent connection support, child processes remain busy
          for much longer than they used to, since they don't become idle as soon
          as a single HTTP request has been serviced (if a persistent connection
          has been established). It's likely that previously, since I'm the only
          user in my dev environment, signals only got tested when all child
          processes were idle.

          --
          Philip Allison
          Programmer
          SmoothWall Ltd. - http://www.smoothwall.net/

          This email and any attachments transmitted with it are confidential to
          the intended recipient(s) and may not be communicated to any other
          person or published by any means without the express permission of
          SmoothWall Limited.

          Any views expressed in this message are solely those of the author.
          See:
          http://www.smoothwall.net/emailnotice.html for the full text of this
          notice.
        Your message has been successfully submitted and would be delivered to recipients shortly.