Skip site navigation (1)Skip section navigation (2)
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>