# Init systems

# Alternatives

Good alternatives to systemd

• sysvinit - the original init
• OpenRC - a dependency-based init system
  • openrc-init - a sysvinit replacement
• s6 - a daemontools-inspired process supervisor
  • s6-linux-init - s6-based Linux init system
  • s6-rc - service manager
  • s6-overlay - integrates s6 with Docker images
  • 66-tools - a suite of s6 helpers made by the creators of the Obarun distribution
• runit - a minimalistic daemontools-inspired process supervisor
• Upstart - an init replacement for sysvinit made by Canonical
• GNU Shepherd - init system and service manager made by GNU, intended for GNU/Hurd and GNU/Guix
• Finit - Finit is an alternative to init system, originally reverse engineered from the EeePC fastinit
• Hummingbird - hummingbird is an init system designed for speed. It can only start and stop the system.
• cinit - cinit is a fast init system with dependency features and profile support.
• initng - Initng is a faster and modern replacement for sysvinit, doing as much as possible asynchronously
• dinit - Dinit is a service supervisor that focuses on portability, clean design, robustness, and usability.

# The bad

Why systemd sucks

• It does not adhere to the Unix philosophy and attempts to handle everything (for example, DNS, bootloader, and networking).

• Systemd was designed essentially on the presumption that nobody other than systemd would be using cgroups, and they even tried to lobby to make cgroups a private property of systemd in the kernel(Making the kernel only work with systemd) but that didn't work either. Systemd appropriates the cgroup tree, takes control of it, and completely messes with any other user of the cgroup tree. Systemd's use of cgroups for process tracking is a fundamentally broken concept; cgroups were never meant for this (making systemd by definition a "hack"), and it's a good way to screw up resource usage.

• Systemd has a strong requirement on glibc for no apparent reason, limiting it to Glibc-based linux systems.

• Systemd relies on DBus for IPC; however, as the term 'Desktop bus' says, DBus was never developed with this in mind, and it shows. DBus was not designed as a transport during early boot, but rather to support IPC within a single desktop session. This is why systemd wanted to promote kdbus so hard, as kdbus fixed several issues with DBus being used as IPC during early boot.

• Systemd's security and general code quality methods are subpar; many security flaws appear in systemd as a result of its insistence on stuffing a lot of code into pid1, adding new bloat features ontop of thousands of lines of bloated code.

• Systemd doesnt care about what maintainers want, by the creator of systemd source

# list

• systemd-importd
  • This is pure evil. Your pid 1 is now able to import complete system images over the network and show them to you as your running system. There is nothing that can go wrong.
• X11 in systemd
  • Of course graphics were missing in pid 1.
• Calendar
  • As you see, your pid 1 should handle your calendars and cron jobs too.
• pid 1 does DNS
  • This change adds another open door to your pid 1, adds caches, new APIs and of course it will never fail and break systemd on your initial boot.
• Clean up directories
  • There is another monster in systemd, it handles tmp files. There are just some cases before it was introduced to have to clean up a directory in the file tree. Now there are hundreds. And easily another case can be added! Of course your init process does that.
• Factory reset
  • Welcome to the Windows OEM world: Factory reset for Linux! Of course it is in your init process.
• init does man
  • My init process is too big, it needs its own file hierarchy and an abstraction layer to find paths.
• remote in pid 1
  • »Everything will end up having a remote API.« I wonder when systemd will understand MIME and e-mail.
• New = better
  • The systemd development process is flawed by always assuming »new is best«.
  • Network configuration should be in my init process.
• sytemd-resolved
  • Every configuration file needs its own process and service.
  • Symlinks are a good way to solve all world problems.
• hostnamed
  • There really should be a process running which exposes the content of a file. Complexity is without cost.
• screen brightness
  • There really should be a process running which exposes the content of a file. Complexity is without cost.
• logind should wait
  • systemd was introduced to decrease the boot up time. Now that they do not understand all implications and dependencies, let us add some artifical time we found out might work for the developers laptops. More on this small world hypothesis of the systemd developers below.
• Systemd does your dns
• Systemd hates when you change your system
• Systemd locks down /etc and makes it read-only
• Systemd does unix NICE
• systemd-nspawn can patch at will any kind of file in a container
  • Paired with transient units and user escalation performable remotely, this can mean that if you house VPS instances somewhere, your hosting provider has means and tools to spy, modify, delete any kind of content you store there. Encrypt everything, read your TOS.
• systemd-logind does sighup and nohup
  • Logout is equivalent to shutting off the machine, so you will NOT have any running program after logout, unless you inform your init system.
• systemd does socat/netcat
• Transient units
  • Temporary services, because we love to reinvent procps, forking, nohup and lsof.
• systemd-journald can do log-rotate
  • Being journal files binaries written with easily corruptable transactions, does this feature make the log unreadable at times?
• systemd replaces sudo and su
  • Please note the command name, machinectl and its features at the manpage. In exchange for a program which contains sudo, su and kill (and does some functions which historically ssh/telnet did), bare metal users have a tons of bloat and a lot of things to disable, if even possible, useful only to people which deal with virtual machines.
• Systemd is now a bootloader
  • Should systemd's PID be changed from 1 to a negative, or imaginary, number? It now exists before the kernel itself, during a bootup.
• Systemd breaks the mouse(again)
  • I dont even know how an init system breaks the mouse
• systemd will be able to kill a process if it needs/wants more RAM
• Don't panic, but Linux's Systemd can be pwned via an evil DNS query
• Systemd Could Fallback to Google DNS?
• DNS search domain not removed from resolv.conf on disconnect
• systemd does not respect system wide resource limits
• Systemd causes outage on Azure
  • Widespread outage was caused on Azure, when systemd 237-3ubuntu10.54 was published to the bionic-security pocket (instances could no longer resolve DNS queries, breaking networking)
• Systemd Renames Network Interfaces
  • Because breaking the name of my network adapter is exactly what I was asking for.
• "lamest vendor"
  • The annual pwnie awards awarded systemd its "Lamest Vendor" prize in 2017, due to its handling of bugs 5998, 6225, 6214, 5144, and 6237.
• a given DNS response will cause systemd to hang entirely
  • Wow - nobody ever warned that there was a massive danger inherent in putting so much arbitrary code into PID 1, did they?
• list-dependencies
  • systemctl list-dependencies --after gdm.service However, this lists all things that contain an "After: gdm-service" in their definition, not the things that are after gdm.service in the dependencies tree.

# Resources

• suckless - "There is a menace which is spreading like a disease throughout the Linux world, it is called systemd."
• darkedgy - "I am not sure I am such a big fan of reimplementing NetworkManager…"
• nosystemd - "If this is the solution, I want my problem back."
• ihatesystemd - "Some things about systemd aren't necessarily bad, they're just damned Ugly."
• Systemd: broken by design - "systemd is broken by design"
• Systemd: Harbinger of the Linux apocalypse - "It might not be the end of the world, but the design of systemd and the attitudes of its developers have been counterproductive"