From owner-svn-src-all@freebsd.org Thu Apr 19 15:55:34 2018 Return-Path: Delivered-To: svn-src-all@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 B4698F86E66; Thu, 19 Apr 2018 15:55:34 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (unknown [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5CEE773C50; Thu, 19 Apr 2018 15:55:34 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lf0-f45.google.com (mail-lf0-f45.google.com [209.85.215.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 1291E20A3D; Thu, 19 Apr 2018 15:55:34 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf0-f45.google.com with SMTP id d79-v6so919127lfd.0; Thu, 19 Apr 2018 08:55:34 -0700 (PDT) X-Gm-Message-State: ALQs6tAdX42tIGnje9ygiEq7fC4vAp0eIA8POD1J9N5RBqgSia+mfTME 86ke82Yvi+aMnUTr85B3giFvn4U7yqy2UGmRyFE= X-Google-Smtp-Source: AB8JxZpTw+8FRbsYWmdqtRsDmiYhZaDbUjdZM3VlUb1BHEiEULdb/MeELWqPDSZzQG75IRIGG7FnSJ7q8a6wPRgoAps= X-Received: by 2002:a19:7904:: with SMTP id u4-v6mr388588lfc.129.1524153332640; Thu, 19 Apr 2018 08:55:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.129.90 with HTTP; Thu, 19 Apr 2018 08:55:12 -0700 (PDT) In-Reply-To: <201804191540.w3JFesdQ066488@pdx.rh.CN85.dnsmgr.net> References: <201804191540.w3JFesdQ066488@pdx.rh.CN85.dnsmgr.net> From: Kyle Evans Date: Thu, 19 Apr 2018 10:55:12 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r332773 - head/etc/rc.d To: "Rodney W. Grimes" Cc: Warner Losh , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 15:55:35 -0000 On Thu, Apr 19, 2018 at 10:40 AM, Rodney W. Grimes wrote: >> On Thu, Apr 19, 2018 at 10:21 AM, Kyle Evans wrote: >> > On Thu, Apr 19, 2018 at 10:19 AM, Warner Losh wrote: >> >> >> >> >> >> On Thu, Apr 19, 2018 at 9:17 AM, Kyle Evans wrote: >> >>> >> >>> On Thu, Apr 19, 2018 at 10:16 AM, Rodney W. Grimes >> >>> wrote: >> >>> >> Author: kevans >> >>> >> Date: Thu Apr 19 15:02:53 2018 >> >>> >> New Revision: 332773 >> >>> >> URL: https://svnweb.freebsd.org/changeset/base/332773 >> >>> >> >> >>> >> Log: >> >>> >> Fix ddb rc script >> >>> >> >> >>> >> r288291 added a call to limits(1), which isn't available before >> >>> >> partitions >> >>> >> are mounted. This broke the ddb rc script, which does not provide its >> >>> >> own >> >>> >> start_cmd. >> >>> >> >> >>> >> Alleviate the situation here by providing a start_cmd. We still have >> >>> >> other >> >>> >> problems with diskless setups that need to be considered, but this is >> >>> >> a >> >>> >> start. >> >>> > >> >>> > Thanks, >> >>> > Also didn't cy identify a second one of these? >> >>> > Or am I confusing yet another issue? >> >>> > >> >>> >> >>> He identified a second early script that didn't specify start_cmd, but >> >>> it was a non-issue because it's invoked independently of rc.subr. >> >> >> >> >> >> One would think that it shouldn't invoke limits at all if foo_limits= wasn't >> >> specified... Would make the feature much less invasive. > > I agree. This should be implemented, > if it isn't already working that way. > >> >> >> > >> > foo_limits was introduced long after the initial invocation, which was >> > introduced to enforce consistent limits of daemons run from rc.subr. >> > Not doing this due to the lack of foo_flags would certainly kill the >> > original intent, I'm afraid. >> >> I do wonder if some kind of kenv var or something would be appropriate >> to disable this whole mess for some setups that it just clearly won't >> work in, but maybe that's a terrible thought. > > I think you miss understood Warner. He is saying that if there is no > rc var *_limits there should be no invocation of limits(1) at all, > making much of this whole mess for many of us a NOP. No, I understood that perfectly... the *_limits rc var was introduced much later just so one can add extra flags to this limits(1) invocation. This would be counter-productive to the original intention of the limits(1) invocation, which had no concept of foo_limits until lately and was intended to just generally apply to all rc scripts without a bunch of redundant crud in every rc script that it can apply to. > I actually believe that is how the code already works, but not sure. Negative, as I've already mentioned a couple of times... limits(1) is applied basically unconditionally.