<div dir="ltr">It sounds like a good project, I'll look into it this weekend.<br><div><div><div class="gmail_extra"><br clear="all"><div>-- <br>David P.</div>
<br><br><br><div class="gmail_quote">On Wed, Jan 22, 2014 at 1:08 AM, Dave Taht <span dir="ltr"><<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

this is not a list of "must haves" but a "would likes".<br>
<br>
Earlier this year, openwrt started working on a replacement for the first<br>
process in the system, the "init" process. Most distros have migrated<br>
away from init towards things like systemd (which provide kitchen sink services)<br>
<br>
Openwrt went in another direction for something simpler and lighter weight,<br>
called "procd".<br>
<br>
<a href="http://wiki.openwrt.org/doc/techref/procd" target="_blank">http://wiki.openwrt.org/doc/techref/procd</a><br>
<br>
Documentation on it is pretty sparse, the best way to learn how to use<br>
it is to grep USE_PROCD /etc/init.d/* and read those files.<br>
<br>
 A huge disadvantage<br>
of old init system is once a daemon dies, it stays dead until a human<br>
restarts it. If that daemon is critical you are hosed.<br>
<br>
The principal advantages of procd are that it can restart a process<br>
after it crashes, and that it integrates with other messages sent<br>
along the ubus so that multiple restarts can be suppressed as<br>
various network things get configured.<br>
<br>
There are a ton of daemons in cero that while pretty reliable, can be made<br>
more so, if wrapped by procd. Converting an existing init script in /etc/init.d<br>
is pretty easy if you look at the code already done there, and how dependencies<br>
work in /etc/config/ucitrack .<br>
<br>
And: that ton of daemons in cero has not been converted to procd yet.<br>
Doing a couple of these would be a good project(s) for someone(s) as<br>
the conversion can be done directly on the router, and tested, no need<br>
for a toolchain. Getting  grip on how uci works<br>
is very helpful for scripting tests and the like, and getting a working package<br>
is only a bit more work. (and the work can quickly go upstream to openwrt)<br>
<br>
the core non-procd daemons in cero currently are<br>
<br>
dbus: I don't even know if this needed anymore (?)<br>
<br>
babeld: of all these, when babeld crashes it's most bad, the router<br>
drops off the mesh. Right now the yurtlab is down... However converting<br>
it to procd looks kind of involved, so I pinged the babel list if they<br>
were interested<br>
<br>
xinetd: if xinetd crashes it's very bad, things like ssh stop working. However<br>
in practice xinetd has been very mature code and has never crashed. I kind<br>
of like it existing independently of procd. That said, I'd like closer ties<br>
with things like dhcpv6-pd so that ipv6 permissions get added and deleted.<br>
<br>
someday procd will gain xinetd-like functionality.<br>
<br>
lighthttpd: cero runs two instances of the lighttpd web server. One is outward<br>
facing, drops root permissions, and the other is for configuration,<br>
and keeps root.<br>
<br>
If it were up to me, these would be disabled after installation, and the only<br>
path into the router would be by ssh secure key. Since it isn't, it would<br>
be nice to keep them running no matter what. Getting two separate instances<br>
started would be a matter of some uci syntax in /etc/config/lighttpd, but<br>
doing the full lighthttpd.conf file format in uci an exercise in pain.<br>
<br>
I'd like it if there was some way to to have it start from xinetd (and die when<br>
unneeded). would like to run one daemon with non-root privs talking to fcgi<br>
with root privs, too. can't have everything.<br>
<br>
polipo: if nobody but me is using polipo, we can disable it by default, but it<br>
too would be nice to be more network aware and use procd.<br>
<br>
ahcpd: this has been a pita generally. I don't know what to do about<br>
it. Of all these, this needs the most love to work right in our<br>
dynamic ipv6 universe.<br>
<br>
rngd: the random number daemon. It used to be that if this crashed,<br>
ssh connections and wpa wifi came to a near halt. It's unknown if it's<br>
still needed after all the random number<br>
fixes that went into the kernel...<br>
<br>
I just moved rngd to procd. (I'd like it if folk running wpa and heavy<br>
crypto stopped rngd for a day to see what happened)<br>
<br>
pimd - this too, I just moved to procd. not that we think it's working.<br>
<br>
snmpd: looks easy<br>
<br>
minissdpd: looks easy but we have other problems with it<br>
miniupnpd: looks easy<br>
avahi: looks easy<br>
<br>
There are several other optional daemons like ipsec, samba, & openvpn<br>
that could use<br>
a procd treatment.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Dave Täht<br>
<br>
Fixing bufferbloat with cerowrt: <a href="http://www.teklibre.com/cerowrt/subscribe.html" target="_blank">http://www.teklibre.com/cerowrt/subscribe.html</a><br>
_______________________________________________<br>
Cerowrt-devel mailing list<br>
<a href="mailto:Cerowrt-devel@lists.bufferbloat.net">Cerowrt-devel@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/cerowrt-devel" target="_blank">https://lists.bufferbloat.net/listinfo/cerowrt-devel</a><br>
</font></span></blockquote></div><br></div></div></div></div>