Date: Sun, 23 Feb 2014 13:39:23 -0500 From: Nikolai Lifanov <lifanov@mail.lifanov.com> To: freebsd-current@freebsd.org Subject: Re: libinit idea Message-ID: <6d0ef0394dedb04335d4f61fb2b55f7f@mail.lifanov.com> In-Reply-To: <0DB376E3-8C7F-4F20-9DEE-4DB98C078571@FreeBSD.org> References: <BLU179-W28221A0539478FDDF45ADDC6840@phx.gbl> <62A9DF47-C938-464B-92B6-9A2A96B5A9C9@FreeBSD.org> <530A39BB.6070003@allanjude.com> <0DB376E3-8C7F-4F20-9DEE-4DB98C078571@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2014-02-23 13:17, David Chisnall wrote: > On 23 Feb 2014, at 18:11, Allan Jude <freebsd@allanjude.com> wrote: > >> sysrc solves this nicely, it is in base now, and is great for >> programmatically adding, removing and changing lines in rc.conf style >> files. It is also in ports for older versions of FreeBSD where it is >> not >> in base. > > The problem is, there is no such thing as an rc.conf style file. > rc.conf is just a shell script. If you only edit it with sysrc, or > you are careful to preserve the structure, then it's fine. There is > absolutely nothing stopping you, however, from writing arbitrarily > complex shell scripts inside rc.conf. Sure, it's a terrible idea to > do so, but when has that ever stopped anyone? > > An rc-replacement could enforce this by only accepting purely > declarative files for configuration, guaranteeing that if they were > syntactically valid they would also be machine editable, no matter > what the user does to them. > > David > Just my $0.02: I don't believe our current RC is broken. It's faster than most, it supports an early-late divider, virtual targets (NETWORK, etc.), dependencies, etc. Rewriting scripts (units) in C has a non-trivial cost to customization for end users. I have custom, packaged, RC scripts in /usr/local that are pretty easy to add and maintain. Shell script logic can go there and not in rc.conf proper. The rcorder program provides a pretty good idea for when these can be run, and, as already pointed out, sysrc can be used to add/remove/configure these on clusters of (automatically) managed machines. If all scripts a properly written, "service foo status" can also provide something that can be acted upon by configuration management systems. Serialization is great (libnv), but it's just gravy. The only feature I see that's missing is (SMF-style) service management, but for hardware events, like losing a network link or a disk, can be plugged in to devd configuration, also easily. Also, in real-life deployments, shutting down service dependencies is not practical either. For example, if postfix crashes, I don't want to stop postgey or dovecot. I just want to nanny postfix back up rather than trying to bring up the whole stack. Also, forking a shell does not have any significant cost to it when bringing up something like MySQL, since it's a small fraction of where the system spends its time to bring up a useful service. Rewriting scripts in C doesn't provide service management or give any on-demand (inetd, read: launchd) functionality. - Nikolai Lifanov
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6d0ef0394dedb04335d4f61fb2b55f7f>