Loading today’s stories
Build1 distinct publisher2 min readPublished
systemd earns its 5.10 kernel floor and glibc toolchain only when services need readiness ordering and resource limits. Plenty of fixed-function devices need neither.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
The only brake on a crash loop under BusyBox init is the one-second sleep in its main loop, and upstream's own `init/init.c` documentation says as much: unlike sysvinit, it does not stop processes from respawning out of control [14]. So before treating a `respawn` entry as your supervision story [13], price the loop. A binary that exits immediately draws roughly 3,600 restart attempts an hour and about 86,400 a day [1], each one writing whatever it writes on the way down. That is the argument for the `syslogd` applet's `-C[size_kb]` option, which keeps the log in a shared-memory circular buffer that `logread` reads, and which the dev.to write-up calls the policy you usually want on a flash-based device [16].
BusyBox also ships a `watchdog` applet, with `-T N` to reboot after N seconds without a reset (60 by default), `-t N` for the reset interval and `-F` for foreground, and it runs from `inittab` as a `respawn` entry [15]. What that detects is a box that stopped petting the watchdog, not a unit that stopped answering. Of the three capabilities the piece credits systemd with earning its price [2], one is therefore partly covered by a binary already in the image, which leaves readiness ordering and resource limits as the actual purchase [2].
The write-up's four forces are a usable checklist for that purchase: image budget from the bill of materials, service topology (whether any service can fail without exiting), the platform floor of C library and kernel version, and the maintenance horizon, meaning how long you must ship security updates [6].
The avoidable error is buying PID 1 to get `/dev`. Buildroot keeps init and device management in separate menus and hides the `/dev` choice only when `BR2_INIT_SYSTEMD` is selected, so real udev rules for a USB modem or a camera are not a reason to take systemd with them [8]. Its general-purpose init list is longer than most summaries admit: `BR2_INIT_BUSYBOX` as the default, plus SysV, OpenRC and systemd, alongside four special-purpose options that are mostly container reapers [10]. On the Yocto side, `INIT_MANAGER` offers `sysvinit` (the Poky default, with udev), `mdev-busybox` and `systemd` [9].
What makes the BusyBox recommendation hold is the size of the thing you have to understand. `/etc/inittab` entries carry one of eight actions, from `sysinit` to `shutdown`, and the runlevel field is not even used [11]. Buildroot's default file mounts a few filesystems, runs `/etc/init.d/rcS` and starts a getty [12]. That is the entire boot in one readable file, which is the cheapest review any embedded team gets.
Ranked by verification strength, evidence, and original report placement.
For most embedded products with a fixed set of services and no user-installable software, BusyBox init is the right default: small, no dependency chain, and its behaviour fits in one readable file.
Choose systemd when the device genuinely needs supervised, interdependent services (readiness ordering, watchdog-backed liveness detection, resource limits), and accept in return a much larger image, a kernel floor of 5.10, a dependency set maintained for the life of the product, and, if building with Buildroot, a glibc toolchain for the whole system.
The systemd vs BusyBox init choice is one of the first structural decisions in an embedded Linux product and one of the hardest to reverse: PID 1 defines how services declare dependencies, how failures are detected, and which libraries stay in the image forever.
Many teams inherit the init choice from the vendor BSP without recording why, then work around it for two years; the problem is the unrecorded decision, not the inherited default.
The decision only arises once a product moves past a single application binary: a device that boots, runs one process and reboots on failure needs nothing beyond a supervising parent. The forces appear when the product gains a second and third long-running service with an ordering relationship.
Four forces decide the choice: the image budget from the bill of materials, doubled in an A/B layout; the service topology, meaning whether any service can fail without exiting; the platform floor, meaning the C library and kernel version committed to; and the maintenance horizon, meaning how long security updates must ship.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Documentation-grounded, single publisher
Most load-bearing claims are checkable configuration and upstream-behaviour facts stated precisely enough to verify: INIT_MANAGER and VIRTUAL-RUNTIME_dev_manager values, the Buildroot init menu options, inittab grammar and actions, watchdog and syslogd applet flags, and a direct quotation from BusyBox init/init.c on uncontrolled respawning. Evidence is capped below high because the entire cluster is one self-published article with no second publisher, no measurements for the 'much larger image' and maintenance-cost assertions, and a body that is truncated inside the systemd discussion.
No adoption data in cluster
The cluster contains no release, deployment, usage-disclosure or benchmark evidence. Build-system defaults are described (BR2_INIT_BUSYBOX as Buildroot's default, sysvinit as the Poky default), but nothing in the supplied material measures how many shipping devices use BusyBox init versus systemd, so no adoption level can be scored without inference.
Broadly aligned, slight framing slack
Claims are conservative and mostly mechanical, and the piece argues for the cheaper default rather than a novelty, so there is little overstatement. A small positive gap remains because the framing lists watchdog-backed liveness detection among the three capabilities that justify systemd while the same article documents BusyBox's watchdog applet, and because the systemd cost side ('much larger image', dependency set for the life of the product) and the 'work around it for two years' assertion are stated without any measurement or case evidence.
Low visible commercial pull
Observable from the text itself: the single source is a developer-platform article that sells no product, vendor BSP, distribution or service, recommends the zero-cost default already present in the image, and states the costs of both options rather than only one. Pull that does exist is the ordinary engagement incentive of a comparison-format post on a developer publishing platform, plus a stated editorial stance ('longer than most write-ups suggest') positioning against other write-ups. No sponsorship, funding or affiliation disclosure is present either way, so this score reflects only what the article shows.
Moderate: verifiable mechanics, unmeasured trade-offs
Confidence is moderate. The technical mechanics are specific and checkable against upstream sources, so the factual spine is likely to hold. It is held down by single-publisher sourcing with no corroboration, a truncated systemd section, no adoption evidence at all, and the fact that the decisive trade-offs an adopter cares about (image delta, patch burden) are qualitative in this cluster.
build
Buildroot's two-command ARM image, and the directory that will brick your board1 distinct publisher
build
A 28-host Debian 12 cutover, and the 02:13 failure Ansible could not have prevented1 distinct publisher
build
The database was fine: a one-in-three DNS failure hidden by an app that logs nothing1 distinct publisher
build
Debian 13 cleans /tmp, and Plex's EAC3 transcoding dies ten days later1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 25, 2026