Date: Mon, 9 Apr 2018 08:30:03 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@pdx.rh.CN85.dnsmgr.net> To: Kyle Evans <kevans@freebsd.org> Cc: "Rodney W. Grimes" <rgrimes@freebsd.org>, Niclas Zeising <zeising+freebsd@daemonic.se>, svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers <src-committers@freebsd.org>, svn-src-stable-11@freebsd.org Subject: Re: svn commit: r331880 - stable/11/etc Message-ID: <201804091530.w39FU3vU019211@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <CACNAnaHqiXfOziCxr4PeM-YZV24XCX2D9DiGW%2BvNg07Jj_Xk1Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Mon, Apr 9, 2018 at 10:14 AM, Rodney W. Grimes > <freebsd@pdx.rh.cn85.dnsmgr.net> wrote: > >> On Mon, Apr 9, 2018 at 9:46 AM, Rodney W. Grimes > >> <freebsd@pdx.rh.cn85.dnsmgr.net> 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. > > This latest issue is a name space collision between base and ports. > > > > People who see limits issues due to missing /usr files usually > > know how to work around it, and they do, they just cp /usr/bin/limits > > to /bin, and do not submit a bug report or send an email. > > > > That saddens me. =/ Sorry for the reality check. Breakage can often take years before someone notices some side effect that was never for seen. Its just the nature of the beast. I am *still* dealing with the fall out that was the FreeBSD 6.0 conversion from standalone ata code to ata over cam. Our error reporting and handling is still not as robust as that which I have in my 5.4p8 based systems. I think it was near 2 years before someone noticed that a change to telldir() caused Samba performance to go in the tank. And iirc that change was done to make it Posix compliant! I try to keep in mind that every bug being fixed often has an unknown new bug being introduced, and some times 2. If you do not believe this, go look at the coverty graphs, despite the fact that many coverty errors have been fixed, we are actually increasing the number of issues over the long term. In the statistic process model of manufacturing when you see this the first thing that comes to mind is "we have an open loop and out of control manufacturing system". Now that saddens me. =/ -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201804091530.w39FU3vU019211>