From owner-svn-src-all@freebsd.org Thu Jun 7 15:00:02 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 BAD83FDC743; Thu, 7 Jun 2018 15:00:02 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5E9516DCC2; Thu, 7 Jun 2018 15:00:02 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id DA2AF21EB0; Thu, 7 Jun 2018 11:00:01 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute5.internal (MEProxy); Thu, 07 Jun 2018 11:00:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=3DpScF afcLbZUdJ1HOCJVWYv/7U3PN/ktlP6Nbjm3t0=; b=F6PxpFfT1FaixWRI4Fqkc+ M4oWyREEyIjtjTdGFXXWF7/RPuiHwNB3S0mtyAuOGfjM7tVvjm+KsF4YjOkfhnll 8dXLRx/QE5HHUS7uqCE517GPrFGiVhzKHpuMJAyDPBaBVLKHnMKsGrUQYIogcU/0 QloMeFsOCvHmdOV8WIZTA/vzvYA2q6+NQQkDFFErikOO3ggiHLjLNiHhvKFVZs8W jLDyy7SyhG5VFS+cq/w7h466oCEUixcM6wPfVK2crPoXDjtav+OuHHpaRb2SDZEn 8+/MLRgP7BEOHR3fNfE9v1Fj4J5NxHVgkXItk5O3hmAch6fDb7Pe2DrfnDODQl7g == X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 77FC2BA50D; Thu, 7 Jun 2018 11:00:01 -0400 (EDT) Message-Id: <1528383601.2883538.1399851720.3D636725@webmail.messagingengine.com> From: Brad Davis To: Eugene Grosbein , Ian Lepore , rgrimes@FreeBSD.org Cc: Konstantin Belousov , Alexander Leidinger , Kyle Evans , "src-committers" , svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-fb4a77ea In-Reply-To: <5B19453E.1030503@grosbein.net> Subject: Re: svn commit: r334617 - in head: . etc References: <201806061833.w56IXWBC006288@pdx.rh.CN85.dnsmgr.net> <1528315608.25377.3.camel@freebsd.org> <5B187A4C.4080009@grosbein.net> <1528377453.2843918.1399734904.04D5276A@webmail.messagingengine.com> <5B19453E.1030503@grosbein.net> Date: Thu, 07 Jun 2018 09:00:01 -0600 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.26 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, 07 Jun 2018 15:00:03 -0000 On Thu, Jun 7, 2018, at 8:46 AM, Eugene Grosbein wrote: > 07.06.2018 20:17, Brad Davis wrote: > > >>> I don't understand the drama over this. rc.d startup scripts are > >>> *binaries*. > >> > >> This is plain wrong. Example: before introduction of rcNG we had /etc/ > >> rc.serial > >> supposed to be user-modified to contain local settings for serial ports > >> (uncluding USB serial). > >> Now it is moved to /etc/rc.d/serial largely unchanged and is still > >> supposed to be user-modified. > > > > We can change this script to advise the user to copy it to /usr/local/etc/rc.d. > > Yes, we could. However, /usr/local/etc/rc.d has its limitations > comparing to /etc/rc.d: > it is not possible to run a script from /usr/local/etc/rc.d before > FILESYSTEMS > early/late divider that is critical if one needs to query local UPS over > serial port > to ensure its battery has enough energy (say, above 5%) to delay fs > mounts until it charges enough. > For example, statically linked "apctest" utility placed to /root/bin/ > does that just fine > with some small scripting. > > You see, my point is that you can never know beforehand of all > challenges a sysadmin faces in fields. > And there should be really good reason to break things that work before. > Like, solving some significant issue we have with current setup. Do we > have such? This is not affected by my changes, you can install *additional* things in /etc/rc.d and they won't be touched just as today. We can also make the rc subsystem more flexible to handle more things.. Regards, Brad Davis