From owner-svn-src-all@freebsd.org Mon May 16 19:59:11 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8DD00B3EC79; Mon, 16 May 2016 19:59:11 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 4A9BB11AD; Mon, 16 May 2016 19:59:11 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-qk0-x22e.google.com with SMTP id n63so103057837qkf.0; Mon, 16 May 2016 12:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=FPDpXGTFSiyYeAMri94Yg2q3McOlaNEfs+/WiP0F8gs=; b=qmtGmBRedbyRYrgRHm3kGclJT+MG42mTMvL8hZh51x60s4En54FucgmvWKI+Wbo5HJ wWNO5FEY8hBF9xb6CSZiY50p/IqklRDVVm6lTB3h5Hg9U6oKjMKayG8SyA4FCi+VMF9k EFeeDHERxbVQkMRdVWCwLse6D0iajbp1AJk0Tj+EgEtB0jw4w9bX22PkLJOHEKZ/xxug fs5WsOYFLAK4VDvq3Yj2iKau4He0ox9TlaQOq1spYMjAGgzC8bMP9Q29Vu9kpPGUB8QB ubadUziQj+ihzE21BJ9/6yyghdZ0iIaetjz3AXeAR6uxnDkYOPujahGcnVRjPhHyCmf+ FLIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=FPDpXGTFSiyYeAMri94Yg2q3McOlaNEfs+/WiP0F8gs=; b=EmFfwvvptYC1A+KxzLWo/A1TfLsCC5m84sIDdamFmEYpena7fFOn8jA6zq87pXg9iz mq3LF71c0Ot0qW+jSIwsq8Zp21q4f7RV1rjgYizypFsEYmmEmeus9vm3x5zViPjgjJPk EzA8B49mmd5Slolwv0GIhqXgLk28my1YqhYlCLbV53J25enBSTij9eEXIcoGfGxOZGxI X/QRcqvygiWY2StoeafQPo7pF8gw5Og3tyka0gP6uqz+G5yHLF4cF7Vd2TdycL+Q+avd QVhEXmRRfaS4l+YL6HUZgh34FYoOCWpYG7hwOCH6fW6FTXAceqsklrBHIN7m5chdRXv9 nGxw== X-Gm-Message-State: AOPr4FWvGc5NCKWnZbuk+nzHdriEf7noMLJHbmGKMPAC3yxMbEskmvSinGpeFtQlDt9PjlGssz66JDWfcmoMPg== MIME-Version: 1.0 X-Received: by 10.55.73.199 with SMTP id w190mr33367455qka.77.1463428750501; Mon, 16 May 2016 12:59:10 -0700 (PDT) Received: by 10.55.170.201 with HTTP; Mon, 16 May 2016 12:59:10 -0700 (PDT) In-Reply-To: <1463330757.1180.154.camel@freebsd.org> References: <201605150438.u4F4coNR080598@repo.freebsd.org> <1463330757.1180.154.camel@freebsd.org> Date: Mon, 16 May 2016 12:59:10 -0700 Message-ID: Subject: Re: svn commit: r299839 - head/etc/rc.d From: Ngie Cooper To: Ian Lepore Cc: Garrett Cooper , "src-committers@freebsd.org" , "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.22 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: Mon, 16 May 2016 19:59:11 -0000 On Sun, May 15, 2016 at 9:45 AM, Ian Lepore wrote: > On Sun, 2016-05-15 at 04:38 +0000, Garrett Cooper wrote: >> Author: ngie >> Date: Sun May 15 04:38:50 2016 >> New Revision: 299839 >> URL: https://svnweb.freebsd.org/changeset/base/299839 >> >> Log: >> Make FILESYSTEMS, dumpon, and var not depend on zfs and zvol >> >> Make zfs and zvol come before all of the items that depended on >> them >> previously > > I'm trying to figure out why these changes are needed. rcorder works > just fine when a requirement has no providers (yes, it whines, but > that's why /etc/rc invokes it with 2>/dev/null). If FILESYSTEMS > requires zfs and nothing provides zfs, then it's as if the requirement > weren't in the list at all. > > The manpage for rcorder is wrong, the DIAGNOSTICS section implies that > rcorder will abort on a missing requirement, but it doesn't. > > Changing requirements to BEFOREs seems like it has a lot of potential > for messing with peoples' out-of-tree customizations. (And for some > reason I've always had the impression that BEFORE was to be avoided in > the base rc files, but I can't remember why I think that.) Hi Ian, Answering both you and Ravi, I agree that the general boot case will "just work" (tm), but it masks issues. In the vanilla case, /etc/rc redirects stderr to /dev/null . This unfortunately hides both missing rc.d dependencies called out as REQUIREs, as well as circular dependencies (which you might notice if you ran rcorder on the directory after r287197 on head -- see: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202726 ), which means that if anyone is running rcorder without directing the stderr to /dev/null, they'll be confused by circular dependencies or missing PROVIDEs if rc.d script aren't installed; I do this sometimes by cd'ing to the etc/rc.d directory and running rcorder `make -VFILES`. Anytime there's a circular dependency, rcorder tosses the whole thing out and screws up the boot order. In the $work case, we use a different system internally at $work for running parallel boot that calculates rc.d script dependencies in a lot more pedantic way. If a dependency is missing, our boot will fail, so we've created a bunch of dummy provides for missing rc.d scripts that are REQUIREments that we don't install. This bloats the rc.d graph more than necessary. All in all, this entire thing is a mess; I'm just shuffling deck chairs right now so I can replace boards and refinish parts of the metaphorical deck enough that things will work "ok" for 11.0-RELEASE. I'll talk with mmacy about launchd and come up with an official proposal for how to move forward with boot in 12.0, because rc is a dated system and needs to be replaced with something more performant and more flexible/logical (run things based on events instead of a one-time static boot order). Thanks, -Ngie