Search arXiv⌕ Search
Home/Archive/arXiv

arXiv · 0706.2748

A Survey of Unix Init Schemes

Yvan Royon·Stéphane Frénot
View original source ↗Read source document ↗Export metadata ↓

Abstract

In most modern operating systems, init (as in "initialization") is the program launched by the kernel at boot time. It runs as a daemon and typically has PID 1. Init is responsible for spawning all other processes and scavenging zombies. It is also responsible for reboot and shutdown operations. This document describes existing solutions that implement the init process and/or init scripts in Unix-like systems. These solutions range from the legacy and still-in-use BSD and SystemV schemes, to recent and promising schemes from Ubuntu, Apple, Sun and independent developers. Our goal is to highlight their focus and compare their sets of features.

Explore related subjects

cs.OS

Keep this discovery

Explore connections, maps & timelines

BibTeXRIS

Yvan Royon, Stéphane Frénot. 2007-06-20. A Survey of Unix Init Schemes. https://arxiv.org/abs/0706.2748

Cite the original work for its findings. Save a collection to share your selection of sources.

KEEP EXPLORING

Related papers

arXiv2026

CXLResume: Retained-State Checkpoint and Restore for In-Memory Services

Checkpointing and restoring an in-memory service typically require writing its memory pages to checkpoint images and refilling them at the destination. When application state already resides in shared memory that remains accessible after failover, copying those pages into and out of checkpoint images is unnecessary. We present CXLResume, a prototype that retains the service's main heap objects in shared memory while checkpointing the remaining execution state and mapping metadata. Checkpointing preserves the shared heap at the same freeze point as the serialized process state. During recovery, CXLResume remaps the same shared memory at its original virtual addresses before restoring execution, preserving direct pointers within and across shared and private memory. We evaluate CXLResume with Redis and Memcached using QEMU CXL functional emulation. At 6 GiB, CXLResume reduces combined checkpoint and restore time from 15.015 s to 0.242 s for Redis and from 19.770 s to 0.276 s for Memcached in the evaluated deployments. These results show that retaining shared application state removes large application heaps from the checkpoint data path and substantially reduces checkpoint and restore latency.

cs.OS↗
arXiv2026

Behind a Simple Read: Understanding Work and Waiting in the Linux I/O Stack

A simple read interface provides uniform semantics but unpredictable performance. Using synchronous large-buffer Linux reads, we decompose the buffered-read path into work volume, processing time, and critical-path exposure. Reducing local cost or accelerating request submission need not shorten a complete read. Linux uses large folios to reduce metadata work and I/O-copy overlap to hide most cold-read copying; an experimental kernel prototype shows that more aggressive overlap and parallelism can shorten the host path when these mechanisms fail. Device waiting dominates SSD cold reads. We abstract first-completion wait F and subsequent completion capacity B_CQ from request-batch timelines. Real-SSD experiments characterize their variation with request and batch size, while MQSim traces explain their internal origins. A wait chain along the folio-bio-request mapping connects device completion to upper-layer waiting. Under strict batching, the median absolute cross-layer prediction error is at most 7.43%. Finally, we apply the completion model and wait chain to request supply, Linux readahead, data layout, and waiting policies. Cases cover gains, no gains, and reversals, comparing predictions with interventions to close the loop from observation and modeling to understanding and control and provide a measurable basis for layered I/O decisions.

cs.OS↗