Startd is an init daemon, loosely based on SysVInit. It starts the system, shuts it down, and allows services to be manually started, stopped and restarted, amongst other functions. Shell scripts are still used for one off or unusual cases, including basic system setup.
Services are configured using start files, which are stored in two system directories (/lib/starts and /etc/starts, by default, similar to Udev). Start files are simply Standard Config files, and can also be used with the start command (directly or as scripts), which duplicates most of the functionality of Startd, from the command line. This functionality includes redirection of standard I/O (either ignored or into a logfile), running services as different users and groups, setting the working directory, chrooting, copying files into the chroot, use of Linux capabilities, scheduling, and setting environment variables. Command line arguments are either specified directly, or stored in Standard Config format and translated into a number of common formats.
Upon bootup, an initial service is started, which doesn’t execute any program itself, but starts other services that it “needs”. In an ideal system, this is all that should be required. ;) After the system is running, commands can be sent to startd as required. One binary is used for both the daemon and administration, with the admin instance communicating with the daemon through a local socket.
Startd was written as an improvement upon SysVInit, and was based on the start command, which was originally intended to implement OS/2 program objects (similar to GNOME desktop files). However, in recent years Startd has also become a potential remedy for the social engineering of Systemd.
Start and Startd were written from scratch, starting on 2001-08-29 and 2008-08-06 respectively, in GNU C, using Emacs and Vi, and the command line (ie. old school).
Automation of starting, stopping, restarting and supervising processes, including those needed by others, avoiding the use of scripts for most tasks.
Initialises the execution environment of a process, including working directory, chroot, user and group, capabilities, environment variables, detachment from the terminal and stdout and stderr logging.
Uses multiple start config files, instead of only one (/etc/inittab), in a simple format.
Uses named services instead of run levels.
Handles system shutdown internally, including CTRL-ALT-DEL and power failure.
No direct equivalent of run levels 0 or 6. Instead there are only different ways to finally shut down the system (halt, poweroff and reboot).
Parallel startup of services.
Open source in practise. Ie. runs existing programs without modification (although many work better with small modifications - features which many others have had for years).
Predictable starting of services during bootup.
Uses shell scripts for unique initialisation tasks, such as initial bootup (basic init), networking setup, firewall, pre shutdown, etc. This allows all necessary scripts to be provided in a single package.
No equivalent of systemd-boot, udev, systemd-mount, systemd-logind, systemd-journald, systemd-networkd, systemd-hostnamed, systemd-timedated, systemd-resolved, systemd-journal-gatewayd, X11 keymaps, dbus, kdbus, systemd-importd, factory reset, systemd-kitchensinkd, etc.
Everything in a single binary, with small utility programs that aren’t strictly needed. Relies on only four libraries (Libc, Standard Config, and libcap and libattr if using Linux capabilities).
Designed for Linux, but doesn’t rely on any Linux only features.
Also uses it’s own log file format, but just simple text.
Also uses the kernel command line, but only via the service option.
Stops services simply by using the terminate signal, followed by kill after a an adjustable delay - just like a system admininstrator does manually.
Start files are much simpler than unit files, and can be used via the start command (without startd at all).
Since start files are only accessed prior to execution of commands, they should never need to be manually reloaded (although they can be).
A minimal level of stupidity and incompetance.
Nb. Systemd does have a few good features, like sandboxing of services, that Startd currently lacks.
startd: The main init process. Also run from the command line to send commands to the main init process.
start: Starts a command as specified by a start file, just like startd. Allows easy testing of start files, and use for other purposes (eg. by an ordinary user, to start GUI programs).
udlog: Scans Startd style log files and translates Unix dates into other formats. Has head and tail options, to only view lines from the start or end of the files.
shutdown: Runs startd to command the main init process to shut down the system. Can be run securely by non-root users.
args-log: Displays and logs the arguments and environment variables of a program.
killme: Simply blocks all signals, requiring it to be killed to stop it. Used for testing.
exampled: An example server.
See the INSTALL file for generic install instructions - this package uses the Autoconf compilation and installation system.
Nb. you need to install the Standard Config package first.
Once the main startd binary is installed (probably in /sbin/), it will be called “startd_new”, to avoid deleting any current version being used. A symbolic link from “startd” or “startd_new” to “init” is necessary for it to be started by the kernel, without using init=/sbin/startd on the kernel command line.
In order to allow non-root users to shut down the system, using the shutdown command, run chmod 4755 /sbin/shutdown as root (if installed in /sbin/).
There are sample init scripts and start files in init-scripts/ and starts/, as well as a kernel patch to start startd directly. Nb. the iptables script is missing (use your own).
An init daemon is the most important element of userspace, and so must be simple, secure, reliable and predictable. It should be written in standard C, and rely on a minimal number of libraries. It should be easy to use, both on a day to day basis and when configuring a new service.
An init daemon must be open-source, and should be a good example for other programmers to follow. This means that it’s goals must be clear, and not open-ended. Open-source isn’t just a matter of open publication and debate - the individual freedom of programmers also depends on the modularity and conservative structure of their operating system. Programmers must be able to work without undue fear of obsolescence and need to learn new commands and interfaces.
An init system should automate all basic tasks, including bootup, shutdown and manual administration of services. It should use simple shell scripts for one off or unusual tasks, since they are merely an automated version of the command line. An init system that rejects such a traditional approach is rejecting the elegant simplicity of the command line itself.
There should be no need for centralised system logging, since every service should have its own log file, and the date should be taken by the program that generated the log entry, for maximum accuracy. Ideally, a number of different standard daemons should be used to automate various computing tasks, like mounting and unmounting devices, logging in and out, changing system settings, etc. The design of these daemons, as a basic part of a unified GUI, is a very challenging task, that cannot be avoided. Such a task can only be undertaken by a large community of programmers with different ideas and experience, in consultation with ordinary users.
There is always a temptation for an init daemon to do more, in order to simplify the system from the point of view of the inexperienced user. However, this can only make the system harder for experienced users, and compromise its overall integrity. With computer technology becoming essential to democracy and individual liberty, a corporate style, monolithic init system must be rejected as a matter of principle, regardless of any other benefits it might have.
The daemon and associated utilities are licensed under the GNU General Public Licence (GPL).
The major version of the GPL used is only 2, in rejection of version 3’s social engineering. Forks of Startd may use GPL version 2, version 3, or later versions.
Found a bug? Please send the details to bugs@cinfinity.info. Mention the program being used, package (with version and/or release number) it came from, command line and config file options, and ideally the backtrace provided by gdb (with the bt command). Please don’t send core files (unless requested).
Any ideas for improvements can be sent to marks@cinfinity.info.
If you want to make a contribution, you can send patches to patches@cinfinity.info. I can’t guarantee I’ll accept them though, since Startd is designed to be minimalist, so for anything substantial, you should probably ask first. Patches should be in unified diff format, created with diff -u <original file> <modified file>. Nb. I don’t use git or any other source code version control system, since I believe that every package should have a single author, and that large projects should ideally be broken down into a number of independent libraries.
My name is Mark Skinner. I’m an Australian, self taught computer programmer, with a degree in engineering (specifically, computer control systems).
I write all my source code using a simple text editor, and compile and test it via the command line. My Xwindow GUI consists of a text editor, web browser and a number of terminals.
Last modified: 2022-05-15 07:10:03 UTC.