I am a Debian user. I am not neither a Debian Developer nor a Debian maintainer. I develop a Debian derivative named Rescatux. There is no such a Debian way so please re-read this article title as: Init systems choice in Debian in the way that adrian15 think the Debian way it is.
This article serves as a one place to redirect everyone who asks me about what I think about all this fuzz about Debian making systemd as their init default choice in x86 and amd64 platforms.
I did not want to write a-yet-another-systemd-article but, as I don’t want to keep searching the Internet to find another article which mostly fits my views, I am writing it.
According to wikipedia Debian entry:
Debian is the name for a Linux distribution that is composed primarily of free and open-source software, most of which is under the GNU General Public License, and packaged by a group of individuals known as the Debian project. At each point in time the Debian project offers three branches named “stable”, “testing” and “unstable”.
The Debian Stable distribution is one of the most popular for personal computers and network servers, and has been used as a base for several other Linux distributions.
Debian is known for its manifesto, social contract, and policies. Debian’s policies and team efforts focus on collaborative software development and testing processes. As a result of its policies, a new major release tends to occur every two years with revision releases that fix security issues and important problems.
Once again according to Wikipedia systemd article:
systemd is a suite of system management daemons, libraries, and utilities designed for Linux and programmed exclusively for the Linux API. Systemd authors characterize the software suite as a “basic building block” for an operating system.
For systems using it, the daemon systemd is the first process that is executed in user space during the Linux startup process. Therefore, systemd serves as the root of the user space’s process tree. The name systemd adheres to the Unix convention of making daemons easier to distinguish by having the letter d as the last letter of the filename.
Systemd is not just the name of the init daemon but can also refer to the entire software bundle around systemd. This includes the daemons systemd, journald, logind and networkd and many other low-level components such as libraries and utilities. In January 2013, systemd author Lennart Poettering described systemd not as one program, but rather a large software suite that includes 69 individual binaries.
Systemd in Debian Background
Ian Jackon proposed a general resolution named: init system coupling in October 2014 which tried to:
This GR seeks to preserve the freedom of our users now to select an init system of their choice, and the project’s freedom to select a different init system in the future. It will avoid Debian becoming accidentally locked in to a particular init system (for example, because so much unrelated software has ended up depending on a particular init system that the burden of effort required to change init system becomes too great). A number of init systems exist, and it is clear that there is not yet broad consensus as to what the best init system might look like. This GR does not make any comment on the relative merits of different init systems; the technical committee has decided upon the default init system forLinux for jessie.
The general resolution was not approved in November 2014.
Problem about systemd controversy
Systemd controversy as I understand it means discussing about systemd without understanding it once and once again. There are many articles about debunking systemd myths so I will not enter into details. You probably know that systemd is not an init per se. One of the systemd components is init yes.
Keeping aside the possible dependencies problem (Gnome pulling out systemd which I think it’s no longer true) what raises my attention, as a sysadmin, is that people are arguing that updating from sysv to systemd leaves their system unbootable.
That’s a pity because Debian is supposed to avoid these problems because it’s stable. These problems should be reported so that next stable Debian Jessie release fixes them if needed. That also means that you cannot draw systemd conclusions from using Debian testing without checking if it’s actually a bug or not. The other concern is that this admin is not worth of his name if he does not know how to get back to the machine previous state (thinking of virtual machine snapshots here). And, also, it’s not worth of his name if he does not learn about systemd and its specific issues.
So, there is an explanation on an Slashdot comment by Tollef Fog Heen which explains a practical view on systemd:
It’s a new system, so some things work differently. Many people seem to fail to see the line between bugs and intentional behaviour. If something doesn’t work as before, it might not be because we’re evil bastards who are out to steal your logs. It might just be that there’s a bug in some package which means your logs aren’t correctly forwarded from the journal.
Sometimes it might be that systemd makes other assumptions about what something means and we’re just failing to catch that in an upgrade check that should warn you about this. An example here is missing devices/mount points in fstab: sysvinit will happily ignore them, systemd won’t consider local-fs.target reached and you’ll have to fix your system for it to boot correctly.
Assumptions, as so often before, are the mother of all fuckups. Asking (preferably in a civilized manner) will get you a long way: “Hey, I’m not seeing my logs appear in syslog, is this supposed to be that way, and if not, can you help debug?”
This might not be the greatest misconception, but I think it’s the most common one. The greatest is possibly the conspiracy theory that this is all a takeover attempt from RH to kill other Linux distributions and that people pushing systemd are either shills or just unwittingly working against the distro they’re pushing systemd into. I’m not sure how adopting a free software component (which sure, happens to be largely maintained by RH engineers, like many other free software components we use to build a distro) will turn us all into corporate-loving robots giving up freedom to be near the source of systemd.
You can also read the Tollef Fog Heen summary on Systemd and Debian which it’s pretty nice.
systemd controversy among Debian is more than one year old at Debian and keep arising once and once again. Some (pro or con systemd) Debian Developers have been upset about some many discussion and have resigned in several of their tasks.
systemd developers also repeatedly suffer the anger of final users which do not like Systemd. If you do not like Systemd do not use it. No one is forcing you to use it. Not even Gnome and if it’s the case fork Gnome but do not complain on systemd people.
What I want to say is that you own the right for complaining but please do complain but only after you have read and tested all you can about systemd and about how Debian works.
Debian lack of resources
If you take a look at Debconf videos you will see that many projects lack manpower and that help is always welcome. Yes, Debian has a lot of users, and a lot of developers but most of them do not get paid for their work. So don’t assume Debian has manpower for meeting your expectations. More than that when people from Debian are asked about Debian Org paying them there’s concern because it goes against Debian spirit.
Another thing Debian is rejecting code that it’s not easy maintainable or similar. You cannot assume that Debian is going to accept everything you request to.
Debian CD should let me opt for sysv
The newest Debian Jessie installer will not have an option for letting you not to install systemd. If you want Debian CD to let you install a systemd free system and presumably with sysv as the default init you need to program yourself it.
Then please contribute back your patch to the debian-cd and debian installer packages as needed.
As you have waited so long at helping Debian people to implement it you will notice that it won’t do it in Jessie. Not in the first release at least.
Too many packages depending on systemd
If you are concerned about so many packages depending on systemd please patch these packages either on upstream or in Debian packages so that they are no so dependent on systemd (There is an init metapackage). Then submit back the patch the Debian
What if my patches do not get accepted
Then fork Debian but not before my previous suggestions are tried. Or, well, if you cannot wait for your changes to be approved please fork but, keep in mind, that your best move is to contribute back to Debian.
Pragmatic steps for avoiding systemd
Just take a look at: Without systemd debian – jessie page. Even if you decide to upgrade to Jessie you can then choose to remove systemd and change your system behaviour so that it makes impossible for systemd to be installed.
First install a good init system# apt-get install sysvinit-core sysvinit sysvinit-utils
Then reboot your machine and remove all the systemd crap# apt-get remove --purge --auto-remove systemd
To keep systemd away from your system you should prevent the package from being installed again.# echo -e "Package: systemd\nPin: origin ""\nPin-Priority: -1" > /etc/apt/preferences.d/systemd
There is also an attempt to release a Debian Jessie installer without systemd but it’s not an official one (as any fork).
What do I think about systemd
As a sysadmin I’m interested in being able to use cgroups so that in a multi web hosting like Virtualmin you can assign resource usage limits to the different webpages. I’m also interested in the declarative ways of setting a system. It seems smarter.
As a Rescatux and Super Grub2 Disk is a new field of opportunities because I can just add an option for bypassing systemd and using sysv at boot (if sysv was not uninstalled) if the former ever fails. But not sure if I will ever implement it.
As per many other open source and free as freedom software projects what really counts is the source code. It’s what your contributions are, not what you think a project should do. So, please, the next time you complain about Debian including systemd by default (only in Linux kernel) just step aside to think carefully about what you can do for Debian and, even, for systemd.