From owner-svn-src-stable@freebsd.org Mon Apr 9 15:36:50 2018 Return-Path: Delivered-To: svn-src-stable@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 DA792F89B3D; Mon, 9 Apr 2018 15:36:49 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com [209.85.215.48]) (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)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C6CD83709; Mon, 9 Apr 2018 15:36:49 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mail-lf0-f48.google.com with SMTP id j20-v6so7224369lfk.2; Mon, 09 Apr 2018 08:36:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=C7LezMUtjWuvFLw5pdRHZ37U6/aXh9f+gHl6wQnjOTg=; b=Jy2zoCROJQuEOfVgBCdQHsOCyxwx2If5xfYHXVss/yy0iiuLZ2ldReEAdLRMoDqKld C8/TqX6zjSZUN/u01WwrMXVo6Q9cn4ncCwfOTNLp36zy53oFlZ376i7LZi4gnLoN6/qe pmqYy/pY1NbmxkMHI8IteYZSKX8jpXS1YgcB4it7XlwjgjysYV7Lhl9nbAZx52Ftux/r xDVGaxRPFBtbxrMuBdLQGOeBxuPX033kT9pdQr1bZrK9sDVJ4jnigt7ABcGKuGn7Rzsg vGZ2aQs2EXO/iA6v/y7566cVr6NR296WHbUqede9DHbiFQZR9zYgtmXmYkdTz6yzRXrQ h9Sw== X-Gm-Message-State: ALQs6tBhgg2hrdK1f7iaNS/K+nf56mDgedBVh7PL6x4Ig02P2lJ7OPrw 7I1rNw6VG6hCOKBvwv6PXl9bo9cN X-Google-Smtp-Source: AIpwx4/fhLEZBuoPG1+irzjWXzjNiQ74rG0mYhDeA079IdNPwy3CAPmXn3O91tBxzaxtLqGOwgY56g== X-Received: by 2002:a19:b516:: with SMTP id e22-v6mr22990297lff.47.1523288207100; Mon, 09 Apr 2018 08:36:47 -0700 (PDT) Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com. [209.85.215.46]) by smtp.gmail.com with ESMTPSA id z19sm117823ljz.1.2018.04.09.08.36.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Apr 2018 08:36:46 -0700 (PDT) Received: by mail-lf0-f46.google.com with SMTP id x70-v6so7208789lfa.0; Mon, 09 Apr 2018 08:36:46 -0700 (PDT) X-Received: by 2002:a19:c4c8:: with SMTP id u191-v6mr23141263lff.109.1523288206725; Mon, 09 Apr 2018 08:36:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.129.90 with HTTP; Mon, 9 Apr 2018 08:36:26 -0700 (PDT) In-Reply-To: <201804091530.w39FU3vU019211@pdx.rh.CN85.dnsmgr.net> References: <201804091530.w39FU3vU019211@pdx.rh.CN85.dnsmgr.net> From: Kyle Evans Date: Mon, 9 Apr 2018 10:36:26 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r331880 - stable/11/etc To: "Rodney W. Grimes" Cc: Niclas Zeising , svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers , svn-src-stable-11@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: svn-src-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for all the -stable branches of the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 15:36:50 -0000 On Mon, Apr 9, 2018 at 10:30 AM, Rodney W. Grimes wrote: >> On Mon, Apr 9, 2018 at 10:14 AM, Rodney W. Grimes >> wrote: >> >> On Mon, Apr 9, 2018 at 9:46 AM, Rodney W. Grimes >> >> wrote: >> >> >> On 04/02/18 17:39, Rodney W. Grimes wrote: >> >> >> >> Author: kevans >> >> >> >> Date: Mon Apr 2 15:28:48 2018 >> >> >> >> New Revision: 331880 >> >> >> >> URL: https://svnweb.freebsd.org/changeset/base/331880 >> >> >> >> >> >> >> >> Log: >> >> >> >> MFC r328331: Support configuring arbitrary limits(1) for any rc.conf daemon >> >> >> >> >> >> >> >> Usage is ${name}_limits, and the argument is any flags accepted by >> >> >> >> limits(1), such as `-n 100' (e.g. only allow 100 open files). >> >> >> >> >> >> >> >> Modified: >> >> >> >> stable/11/etc/rc.subr >> >> >> >> Directory Properties: >> >> >> >> stable/11/ (props changed) >> >> >> >> >> >> >> >> Modified: stable/11/etc/rc.subr >> >> >> >> ============================================================================== >> >> >> >> --- stable/11/etc/rc.subr Mon Apr 2 15:07:41 2018 (r331879) >> >> >> >> +++ stable/11/etc/rc.subr Mon Apr 2 15:28:48 2018 (r331880) >> >> >> >> @@ -773,6 +773,8 @@ check_startmsgs() >> >> >> >> # >> >> >> >> # ${name}_login_class n Login class to use, else "daemon". >> >> >> >> # >> >> >> >> +# ${name}_limits n limits(1) to apply to ${command}. >> >> >> >> +# >> >> >> > >> >> >> > Caution, limits(1) is in /usr/bin, this code can fail if used before >> >> >> > /usr is mounted. (Ie, our rc.initdiskless) is probably broken by >> >> >> > this change if a call is made to limits. >> >> >> > >> >> >> > >> >> >> >> >> >> Sorry for jumping on this so late. This is also an issue in CURRENT, >> >> >> and has been since at least 2016. >> >> > >> >> > I was aware that it was an issue and why I made a comment about it >> >> > being MFC'ed. Though I had forgot a bug report existed. >> >> >> >> I'm kind of surprised we haven't had more complaints about this- the >> >> original commit for this stuff landed before stable/11 was even >> >> branched, so it's been broken for all of 11.x's lifetime. >> > >> > History has taught me it takes a long time for this type of >> > breakage to usually surface in a noticable way. Also I think >> > until you merged this last ${name}_limits thing it actually >> > didn't cause an issue, except for the few like me running >> > diskless systems and or seperate /usr. >> >> I don't see how this merge could possibly have been the cause of any >> claimed issues- like I said before, it didn't add any limits >> invocations, it added an arg to the limits invocation that already >> existed. You can see this pretty clearly from the diff, we didn't even >> change any conditions for limits to be invoked. > > limits_mysql="NO" is defined by the startup script for mysql, > that now causes /etc/rc to try and use that variable in a > different way. > > You added a variable, one that was already in use by some other > /etc/rc* related component. Collision of differening uses is > causing errors. > Ah, apologies, I misread your previous e-mail and had interpreted it as you claiming again that this broke things for those of you "running diskless systems and or seperate /usr." -- this other breakage, these are things we can fix and aren't really large hurdles to climb over. We just need people like 0mp that are actually inclined to address it in ports, and we need to actually communicate changes like this with ports people and assess what's going to break and make a plan to get it fixed. IMO this in particular wasn't a major change, and it shouldn't have been too big of a deal (unlike the commit that it built upon). I don't think it should've been broken in head for two months in the various ports that 0mp has identified- even if people don't run these databases on head, we should've assessed the fallout and fixed it somewhere in the two month's time. We're not talking half the ports tree, we're talking < 30 ports. =(