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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1528383601.2883538.1399851720.3D636725>