Re: launchd port: Worth it?

["James K. Lowden" <jklowden%schemamania.org@localhost>]

On Thu, 14 Mar 2013 23:21:39 +0100
Julian Djamil Fagir <gnrp%komkon2.de@localhost> wrote:

> I've been looking at the GSoC projects, and I saw this one:
>     http://wiki.netbsd.org/projects/project/launchd-port/
> 
> I don't own an Apple and just looked at the documentation. So I
> wonder: Would we really want launchd? I mean, it's adding complexity
> to the boot process and centralising a system which has been working
> for decades. Is there really a need to integrate cron, inetd and rc?

On Fri, 15 Mar 2013 13:16:28 +0000 (UTC)
christos%astron.com@localhost (Christos Zoulas) wrote:

> Do you know what launchd does?

A search for a problem description turned up
http://www.youtube.com/watch?v=cD_s6Fjdri8, the first 35 minutes of
which is a pretty clear description of what it is and why it exists.  

It's Too Much Code.  Here's another daemon frameworky thing that says,
"Old way bad, new way better."  To use it, programs have to integrate
with launchd.  The apache counterexample in the talk is illustrative.  

It does offer some features not available in NetBSD in the realm of
reacting to environmental changes, a daemonized rc.  That part might be
worth working on, but I doubt there's much appetite for it.  

Here's my distillation of the problem launchd addresses:

1.  Notification of environment changes.  Disk drives being
added/removed, *files* being added/removed, network state changes.  
2.  Name service for notifications.
3.  Watchdog restart of failed processes.  
4.  Standard configuration file, plist. 
5.  Process and resource dependency scheduling.  
6.  [mumble] avoid setuid. 

These are or could be provided by NetBSD without launchd.  For example: 

1.  Notification: kevent(2)
2.  Name service: /proc
3.  Watchdog: todo
4.  Config: proplib or sqlite 
5.  Dependencies: sqlite
6.  setuid: problem unclear

Notification is easy, responding is hard.  It's one thing to write
launchd and have a system-change announcement framework.  It's
something else to modify, say, postfix or mail(1) to respond to ip
address changes.  

I like Aaron's idea of a kind of "launchd-lite" that would react to
changing state.  Such a daemon would require no changes to the launched
processes.  One feature I rather like is services that start/stop based
on the presence of the configuration file.  That solves the DRY problem
of setting up a configuration file *and* modifying rc.conf to turn it
on. 

Configuration and dependencies are related, and IMO sqlite is the best
solution.  Why?  It would radically simplify or eliminate rc.d,
rc.conf, rc(8), and rcorder.  

It is possible to express in tabular form any dependencies, and trivial
to describe programs and their arguments. That done, a simple SELECT
statement could reveal "all things that depend on X" for example, or
the longest serial list of dependencies, or the maximum number that
could start in parallel.  A user-defined function in sqlite would
enable verification of the existence (or, say, modification time) of a
file, the name of which might come from an environment variable.  

The configuration database could also record the termination state and
time of failed daemons.  Today there is no way to ask, "what daemons
are not running that should be?"  ntpd is my favorite.  For this to
work, init would have to be modified.  

By the way, one of the features of launchd is concurency management:
ensuring that process X doesn't read resource A while process Y is
updating it.  That is taken care of by using sqlite. 

However, unlike Apple, NetBSD has no control over what programs are
installed. Consequently the dependency database (however implemented)
will always be fragile, because it can't automatically reflect
dependencies implicit in /etc/foo.conf.  

In sum, NetBSD already offers the system services launchd provides.
Rather than encourage adoption of Apple's framework, it would be better
to rely on what we already have in the form of kevent notifications for
changes to /proc.  But we have no daemon-management supervisor to
start/stop daemons based on those signals, and the existing rc
framework isn't particularly amenable to that purpose.  SQLite would be
a good foundation to build such a supervisor.  

--jkl