Add procd as an init_manager in oe

[troth]

OE-core currently has three init_managers:

• BusyBox
• sysv init
• systemd

The current state in meta-openwrt uses one of those and that ends up creating /etc/rcN.d directories that are not used in the openwrt-base-image (procd only uses /etc/init.d and /etc/rc.d directories).

Since procd is the init process in OpenWRT/LEDE, it should be added to the list of init_managers. The implementation should be mostly done in meta-openwrt, but there may be a need to add some hooks into oe-core (which should know nothing about meta-openwrt) to get this working.

From discussions with Khem at ELC-NA 2017.

[danielfdickinson]

Should this work be first done in meta-openembedded/meta-oe (currently libubox lives there in recipes-devtools)?

[danielfdickinson]

Per the ML, should this be closed? We can already (with my updates) use meta-openwrt to use procd as init_manager and dev_manager, and since you mentioned you didn't think it belonged in meta-oe, I guess it's fine in meta-openwrt only.

[kraj]

I think I did not mean no to common place. We have poky tiny which is a small footprint distro. and procd could be an appealing option for it, provided its not too tied into openwrt way of doing things

[danielfdickinson]

ok; I'll keep the work I've been doing on that then, but incorporate it into meta-openwrt first; not sure if I'll figure out a way to have both use cases in one recipe or if I'll need two.

[kraj]

If we can treat procd as standalone init that will be a win, but most of openwrt is very monolithic in nature so I Doubt if that will work over long time.

[danielfdickinson]

I got procd building an launching gettys with just ubus and libuci as dependencies. The interface rather weird though for starting services and such (openwrt uses funky wrappers to use json from shell). I'm not sure I want to replace those scripts, but as it is they are very tied to openwrtisms. it's theoretically doable but I'm not sure it's maintainable.

[danielfdickinson]

I guess the question is whether is worth introducing another init system into OE-core, even for poky-tiny, when it would require adding initscripts for every package you wanted to use with the procd. I don't think it's practical to make sysvinit initscripts work out of the box with procd, so you'd end up even worse off than busybox-init. (That is the sysvinit scripts would all need modification to work with procd). I suppose if you wrote a frontend that allowed for using systemd .service files it'd be different (and I think systemd .service files are closer to the kind of situation that procd expects than sysvinit, so it might actually save a lot of work of converting scripts).
I'll have to think about it some more, but if I can make that work, it might actually make procd worth using outside the openwrt case. (Need to think about the .socket case as well, since currently procd doesn't have an equivalent AFAIK).

[kraj]

yes its not an easy problem to solve. However, there is a need for a tiny init system which is not based on shell scripts and yes it will be different. we dont expect poky-tiny to build everything in OE so as long it can build a small subset we are ok.

[MatthiasMichel]

Hi, how can I solve this problem on a yocto build? Is there a workaround to use procd? Which is the correct VIRTUAL-RUNTIME_init_manager?

[danielfdickinson]

Procd can be used with the meta-openwrt stack but not standalone at the moment.

[danielfdickinson]

@kraj @MatthiasMichel I've looked over procd and netifd and [openwrt]firewall enough to know that there is too much openwrt-specific 'stuff' going on for me to think it a good idea to use it as a generic solution.

TL;DR Devices small enough for procd and friends to matter as a possible solution probably don't have a value proposition for making it generic (i.e. non-openwrt specific).

All the words

Unless I have reason to believe that small (< 32MB) flash device will be common (or are wanted to be common for future devices and the financial backing for supporting them is there, but the issue is lack of distros for them)), I don't want to spend a lot of time on optimizing the size of the init/network stack; for me I've got enough projects I'm interested in that flogging a concept that isn't going to go anywhere (and of course I need to be able to earn a living doing it), doesn't make sense.

I think the procd/netifd combo does things that current distros don't handle well, and I'm more interested in a solution that implements some of the interesting features within a more standard linux environment. I think the forward path is the get systemd to be better at handling daemons that affect network state and being able to model the current network state and changes needed to get the desired network state. procd triggers are very nice, and would be good to have in systemd. I think firewalld is nice for the firewall though and see no need to go with openwrt's firewall in a normal distro.

I suspect that 8 and 16MB flash routers are simply too small for me to care about as a basis for a forward-looking project (given that even openwrt is not really caring about the ar71xx routers very much going forward (based on http://lists.infradead.org/pipermail/openwrt-devel/2018-May/012538.html), and old routers in general, I think it'd make more sense for old routers to live as forks of openwrt that caters to those wishing to use old equipment (of course someone would have to actually care enough to do it at the same time has having skills for it; I think it'd be an interesting project, but I have more than enough that I want to do with newer tech), and really 16MB can probably do standard OE with systemd networking just fine. Again I'm not sure there is enough value in the tiny case to be worth working on it.

Having said all that, I enjoyed working meta-openwrt and previously on openwrt, and like what it's been able to do with very small devices, and consequently things I've able to work on with very constrained resources. A big bonus of procd/netfid/firewall is that it's much simpler than dealing with systemd. OTOH simplicity can be limiting. Getting used to OE's build systemd vs. openwrt's biuldroot-ish system, for instance is a steep learning curve, but I'm getting the point where I see the benefit's in terms of what I can do with it. OE has a potential (done right) to produce more robust firmware than buildroot, and I think a similar principle applies to procd vs systemd.