[Cerowrt-devel] procd support for core daemons?

Dave Taht dave.taht at gmail.com
Wed Jan 22 01:08:02 EST 2014

this is not a list of "must haves" but a "would likes".

Earlier this year, openwrt started working on a replacement for the first
process in the system, the "init" process. Most distros have migrated
away from init towards things like systemd (which provide kitchen sink services)

Openwrt went in another direction for something simpler and lighter weight,
called "procd".


Documentation on it is pretty sparse, the best way to learn how to use
it is to grep USE_PROCD /etc/init.d/* and read those files.

 A huge disadvantage
of old init system is once a daemon dies, it stays dead until a human
restarts it. If that daemon is critical you are hosed.

The principal advantages of procd are that it can restart a process
after it crashes, and that it integrates with other messages sent
along the ubus so that multiple restarts can be suppressed as
various network things get configured.

There are a ton of daemons in cero that while pretty reliable, can be made
more so, if wrapped by procd. Converting an existing init script in /etc/init.d
is pretty easy if you look at the code already done there, and how dependencies
work in /etc/config/ucitrack .

And: that ton of daemons in cero has not been converted to procd yet.
Doing a couple of these would be a good project(s) for someone(s) as
the conversion can be done directly on the router, and tested, no need
for a toolchain. Getting  grip on how uci works
is very helpful for scripting tests and the like, and getting a working package
is only a bit more work. (and the work can quickly go upstream to openwrt)

the core non-procd daemons in cero currently are

dbus: I don't even know if this needed anymore (?)

babeld: of all these, when babeld crashes it's most bad, the router
drops off the mesh. Right now the yurtlab is down... However converting
it to procd looks kind of involved, so I pinged the babel list if they
were interested

xinetd: if xinetd crashes it's very bad, things like ssh stop working. However
in practice xinetd has been very mature code and has never crashed. I kind
of like it existing independently of procd. That said, I'd like closer ties
with things like dhcpv6-pd so that ipv6 permissions get added and deleted.

someday procd will gain xinetd-like functionality.

lighthttpd: cero runs two instances of the lighttpd web server. One is outward
facing, drops root permissions, and the other is for configuration,
and keeps root.

If it were up to me, these would be disabled after installation, and the only
path into the router would be by ssh secure key. Since it isn't, it would
be nice to keep them running no matter what. Getting two separate instances
started would be a matter of some uci syntax in /etc/config/lighttpd, but
doing the full lighthttpd.conf file format in uci an exercise in pain.

I'd like it if there was some way to to have it start from xinetd (and die when
unneeded). would like to run one daemon with non-root privs talking to fcgi
with root privs, too. can't have everything.

polipo: if nobody but me is using polipo, we can disable it by default, but it
too would be nice to be more network aware and use procd.

ahcpd: this has been a pita generally. I don't know what to do about
it. Of all these, this needs the most love to work right in our
dynamic ipv6 universe.

rngd: the random number daemon. It used to be that if this crashed,
ssh connections and wpa wifi came to a near halt. It's unknown if it's
still needed after all the random number
fixes that went into the kernel...

I just moved rngd to procd. (I'd like it if folk running wpa and heavy
crypto stopped rngd for a day to see what happened)

pimd - this too, I just moved to procd. not that we think it's working.

snmpd: looks easy

minissdpd: looks easy but we have other problems with it
miniupnpd: looks easy
avahi: looks easy

There are several other optional daemons like ipsec, samba, & openvpn
that could use
a procd treatment.

Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

More information about the Cerowrt-devel mailing list