[Cerowrt-devel] procd support for core daemons?
dperson at gmail.com
Wed Jan 22 13:45:30 EST 2014
It sounds like a good project, I'll look into it this weekend.
On Wed, Jan 22, 2014 at 1:08 AM, Dave Taht <dave.taht at gmail.com> 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
> 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
> is pretty easy if you look at the code already done there, and how
> 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
> 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.
> 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
> 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
> 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
> 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:
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cerowrt-devel