** Description changed:

  (I'm putting on the SRU template, but regardless of whether this is SRU-
  eligible, fixing this in the development version is obviously the first
  step.)
  
  [Impact]
- This is a regression from Trusty.
+ This is a regression.
  
  While the main purpose of this is to "reread the filter rules", the
  biggest use by frequency is to reload the SpamAssassin rules. In our
  production deployment, this happens up to daily--every time their is a
  SpamAssassin rule update released.
  
  Without the ability to use "reread", one must fall back on "restart".
  That's a disruptive operation that will result in mail being tempfailed
  for a short period of time.
  
  If sysadmins have not noticed this regression, then rule changes are not
  getting applied properly.
  
  [Test Case]
  Steps to reproduce:
  sudo md-mx-ctrl reread
  
  Expected results:
  Forced reread of filter rules
  
  Actual results:
  Cannot destroy and recreate a Perl interpreter safely on this platform.  
Filter rules will NOT be reread.
  
  [Regression Potential]
  The regression potential is small. The patch changes a ./configure test only. 
The only impact on the application code comes from the SAFE_EMBED_PERL #define 
being correctly enabled again, which it has been "forever".
  
  [Other Info]
  This patch has been accepted upstream:
  
http://lists.roaringpenguin.com/pipermail/mimedefang/2016-September/037862.html
  
  I am running this change in production, as installed from our PPA:
  https://launchpad.net/~wiktel/+archive/ubuntu/ppa

** Description changed:

  (I'm putting on the SRU template, but regardless of whether this is SRU-
  eligible, fixing this in the development version is obviously the first
  step.)
  
  [Impact]
  This is a regression.
  
  While the main purpose of this is to "reread the filter rules", the
  biggest use by frequency is to reload the SpamAssassin rules. In our
  production deployment, this happens up to daily--every time their is a
  SpamAssassin rule update released.
  
  Without the ability to use "reread", one must fall back on "restart".
  That's a disruptive operation that will result in mail being tempfailed
  for a short period of time.
  
  If sysadmins have not noticed this regression, then rule changes are not
- getting applied properly.
+ getting applied properly, though normal slave turnover eventually brings
+ them in.
  
  [Test Case]
  Steps to reproduce:
  sudo md-mx-ctrl reread
  
  Expected results:
  Forced reread of filter rules
  
  Actual results:
  Cannot destroy and recreate a Perl interpreter safely on this platform.  
Filter rules will NOT be reread.
  
  [Regression Potential]
  The regression potential is small. The patch changes a ./configure test only. 
The only impact on the application code comes from the SAFE_EMBED_PERL #define 
being correctly enabled again, which it has been "forever".
  
  [Other Info]
  This patch has been accepted upstream:
  
http://lists.roaringpenguin.com/pipermail/mimedefang/2016-September/037862.html
  
  I am running this change in production, as installed from our PPA:
  https://launchpad.net/~wiktel/+archive/ubuntu/ppa

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1624394

Title:
  mimedefang: md-mx-ctrl reread does not work

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mimedefang/+bug/1624394/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to