It sounds like a good project, I'll look into it this weekend. -- David P. On Wed, Jan 22, 2014 at 1:08 AM, Dave Taht wrote: > 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". > > http://wiki.openwrt.org/doc/techref/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 > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel >