Date: Thu, 07 Jun 2018 09:00:01 -0600 From: Brad Davis <brd@FreeBSD.org> To: Eugene Grosbein <eugen@grosbein.net>, Ian Lepore <ian@freebsd.org>, rgrimes@FreeBSD.org Cc: Konstantin Belousov <kostikbel@gmail.com>, Alexander Leidinger <Alexander@leidinger.net>, Kyle Evans <kevans@FreeBSD.org>, "src-committers" <src-committers@FreeBSD.org>, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org Subject: Re: svn commit: r334617 - in head: . etc Message-ID: <1528383601.2883538.1399851720.3D636725@webmail.messagingengine.com> In-Reply-To: <5B19453E.1030503@grosbein.net> 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>
index | next in thread | previous in thread | raw e-mail
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 Davishome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1528383601.2883538.1399851720.3D636725>