From: Dave Taht <dave.taht@gmail.com>
To: David Personette <dperson@gmail.com>
Cc: "cerowrt-devel@lists.bufferbloat.net"
<cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] procd support for core daemons?
Date: Sat, 25 Jan 2014 11:14:21 -0500 [thread overview]
Message-ID: <CAA93jw5cS9rCff=z7ca_TzhDAz-qhrcUMP9nwH9yp+p9y_QQvg@mail.gmail.com> (raw)
I moved pimd, ahcpd, polipo, avahi-daemon, rngd, and the cerowrt and
luci configuration web servers into being managed by procd. (The
lighttpd/cerowrt fix actually fixed a longstanding bug in restarting
those competing webservers.)
Left to convert are babeld (which was the only one of the above I
really cared about, sadly. I am bogged down on understanding the
uci_validate routine).
The trival changes required to those init scripts (not warranted to be
correct at this point) are at:
http://snapon.lab.bufferbloat.net/~cero2/procd/
could use eyeballs on all that(?).
The WIP on converting babel is there also. (I found it necessary to
patch babel to run without a pid file, not that I'm right...)
I didn't touch minissd or upnp 'cause I don't know enough about them
to be able to test. (and I understand that they are busted
for some people, and that I/we need to fix that first. and I just
nabbed a playstation to observe)
I don't plan to convert xinetd.
Didn't get around to converting snmpd.
That's it for "core daemons". (a fingering change is generally you
want to do a /etc/init.d/whatever reload rather than
restart)
of the other commonly installed ones, there are samba, openwrt,
strongswan and ipsec, that I know of. All these are packages that
haven't been installed or tested for a while (by me, anyway)...
I am travelling back to california tomorrow and don't plan an actual
build until next weekend.
On Wed, Jan 22, 2014 at 1:45 PM, David Personette <dperson@gmail.com> wrote:
> It sounds like a good project, I'll look into it this weekend.
I left you the hard bits. :( - nearly all the above are checked into
ceropackages-3.3 and cerofiles-next.
>
> --
> David P.
>
>
>
> On Wed, Jan 22, 2014 at 1:08 AM, Dave Taht <dave.taht@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@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
--
Dave Täht
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
next reply other threads:[~2014-01-25 16:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-25 16:14 Dave Taht [this message]
2014-01-25 16:43 ` Toke Høiland-Jørgensen
2014-01-25 16:50 ` Dave Taht
2014-01-25 17:06 ` Toke Høiland-Jørgensen
2014-01-25 17:18 ` Dave Taht
2014-01-25 20:23 ` Aaron Wood
-- strict thread matches above, loose matches on Subject: below --
2014-01-22 6:08 Dave Taht
2014-01-22 18:45 ` David Personette
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAA93jw5cS9rCff=z7ca_TzhDAz-qhrcUMP9nwH9yp+p9y_QQvg@mail.gmail.com' \
--to=dave.taht@gmail.com \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=dperson@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox