From owner-svn-src-head@freebsd.org Wed Feb 28 16:24:39 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 923CBF32AB0; Wed, 28 Feb 2018 16:24:39 +0000 (UTC) (envelope-from srs0=awtu=fw=freebsd.org=kp@codepro.be) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 93852815AD; Wed, 28 Feb 2018 16:24:37 +0000 (UTC) (envelope-from srs0=awtu=fw=freebsd.org=kp@codepro.be) Received: from [192.168.26.135] (254.158.dhcp.conference.apricot.net [220.247.158.254]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id 7359E2CB6B; Wed, 28 Feb 2018 17:24:35 +0100 (CET) From: "Kristof Provost" To: rgrimes@FreeBSD.org Cc: src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org Subject: Re: svn commit: r330105 - head/etc/rc.d Date: Wed, 28 Feb 2018 22:09:31 +0545 X-Mailer: MailMate (2.0BETAr6104) Message-ID: <4EC3BE57-F14C-4CBD-ADC1-10293B96142C@FreeBSD.org> In-Reply-To: <201802281619.w1SGJGPD020976@pdx.rh.CN85.dnsmgr.net> References: <201802281619.w1SGJGPD020976@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 16:24:39 -0000 On 28 Feb 2018, at 22:04, Rodney W. Grimes wrote: > So might it be better to correct what it was attempting to do, > and wrap that in a conditional? I may or may not want this > to exist after a reload, and that should be my option, alternative > is for me to either edit this file, or write my own. Or having > to execute a bunch of -F commands by hand. > > It was clearly the intent of the original author to have these > flushed, fixing the mistake by removing the flushes is one way > to fix it. I am asking for consideration on that there is another > desired solution, and that both can exist with a simple knob. > Yes, but what was originally attempted was to keep the existing connections. This is currently the case. There’s no point to flushing anything before loading the new rules. If you want to be able to choose wether or not to keep the existing connections we could add a conditional `pfctl -F states`, but you can already accomplish this by calling `/etc/rc.d/pf restart` rather than `/etc/rc.d/pf reload`. I'm not sure it's worth adding a new knob. Regards, Kristof