libinit idea

[Nikolai Lifanov]

On 2014-02-23 13:17, David Chisnall wrote:
> On 23 Feb 2014, at 18:11, Allan Jude <freebsd at 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