After starting init(8) or similar on Linux and other UNIX flavors, older-style system startup activity includes running several shell processes to interpret about 2-3 dozen rc scripts/etc/rc.d/*   /etc/rc* or a few large ones.  On many systems, each shell also interprets secondary scripts loaded with shell functions used as shared or common services.  Although shell scripts are simple enough to create and maintain, their ease and convenience comes at a cost.  While the overhead from runtime interpreting scripts is undesirable, always running tasks serially is about the slowest way to execute most workloads, meanwhile most other CPU resources are left idle.  These issues and a motivation for faster boot times led to methods of executing startup workloads in parallel, especially on modern hardware with many CPU cores/threads.  While some methods modestly reduce system startup time, most include one or more forms of runtime interpreting and a mix of elements like these:


was named with a dual-meaning from the phrase "concurrent startup" and from being written in C.  The overall design follows a UNIX philosophy – minimal, fast, and efficient.  The primary focus is minimizing runtime for the startup workload and faster boot times.  Major elements are a parallel execution engine, translator, and display/disassembler.  Each element works with system startup and shutdown workloads — see operating modes.   To support most systems and for versatility, workloads are listed in ASCII config files, and these are translated to binary for runtime performance.  While avoids complexity and heavy excess found in other startup services, similarly there are no high-overhead elements like attempting to auto-convert rc scripts/etc/rc.d/*   /etc/rc* or divine prerequisites between startup tasks.  Custom extensions and new config-driven internal functions are sometimes written to suit unique embedded systems.  Design summary:

Target hardware requirements are CPUs with at least 4-cores/8-threads.
Example platforms include embedded systems, servers, and HEDTs.


After init(8) or similar on most Linux and other UNIX flavors, can often reduce startup runtime by about 33%.  A wide range of hardware configurations and startup workloads can lead to reductions that also vary widely, ranging roughly 19% to 77%.  A mix of several factors contribute to runtime reductions with , eg:

For overall workload optimization, a tuned thread count can lead to saturating hardware resources while avoiding overloading and excess context switching.  Some startup processes can be replaced with custom internal functions and further reduce startup runtime, eg: high resource consumers and frequently run simpler processes.