[Cerowrt-devel] procd support for core daemons?

[David Personette]

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 <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
> 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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140122/46ceaae6/attachment.html>