From Electron Cloud
Revision as of 18:31, 8 July 2009 by Ecloud (Talk | contribs) (respawning misc background processes)

Jump to: navigation, search

The "documentation" such as it is, is here.

ifup/ifdown errors

don't seem to have all the variables for eth0

If you think /etc/network/interfaces is set up correctly, and if static config works OK but dhcp does not, here's one more thing to check: if you depend on an external dhcp client rather than the Busybox built-in one,


must be set in the .config file, which by default it is not!

no way to set the route metric via ifup

I wrote up a bug about this, but basically the answer is, don't use ifup/down, use scripts instead.

My reason for wanting to use ifup and ifdown is that ifplugd does it by default, and the desired behavior on most systems is not to try to configure ethernet until a cable is plugged in, and then to do it without any user intervention. (And what to do if some services will not run without a network, is another can of worms) But it's possible to rewrite /etc/ifplugd/ifplugd.action to do something else.

init tricks

These tricks are for busybox; might not work the same with other versions of init, and I'm not sure if some of these behaviors just happen to work that way in the versions of busybox that I've tried, or will always work that way.

parallel startup

One way to get an embedded system to start up really fast is to run two sysinit scripts at the same time; e.g. say you want to do basic system initialization but also start X so you have a graphical environment right away (and assuming that starting X doesn't have unsatisfied dependencies at the time that it starts):


A caveat: if any sysinit script does not exit, then nothing else will be run. So don't put a process that normally doesn't daemonize itself at the end of rcS for example, without a trailing ampersand... if rcS doesn't exit, it will block everything else past that point from being started.

respawning misc background processes

If you have a buggy program that tends to exit unexpectedly (like wpa_supplicant for example, or wpa_cli to run the action script on connect/disconnect events), you can run it without a console by using /dev/null as the console instead:

null::respawn:/usr/local/bin/wpa_supplicant -iwlan0 -c/etc/wpa_supplicant.conf -dd -D driver > /var/log/wpa_supplicant.log
null::respawn:/usr/local/bin/wpa_cli -a/etc/wpa_action -iwlan0 -g127.0.0.1

So it should not be necessary to write another "watchdog" process to keep something running, when init can do that just fine itself. These respawn processes will be run after the "once" actions, which in turn are run after the "sysinit" actions.

Note copied from the documentation page: "note that if BusyBox detects that a serial console is in use, then only entries whose controlling tty is either the serial console or /dev/null will be run". So embedded devices without PC-style displays cannot run things on tty2 or some such just to stick them somewhere, and that's one reason this trick is useful.

doing multiple things at shutdown

As with multiple things at startup, multiple shutdown actions are OK too.

::shutdown:/bin/umount -a -r
::shutdown:/usr/sbin/alsactl store
::shutdown:/sbin/swapoff -a
::shutdown:/etc/init.d/ stop

unanswered questions

...or maybe I just forgot the answer...

  • in this example, what is the hyphen for?