# Debian Jessie with Mate and without systemd ## Rationale I am a Debian user and there are packages I don't like to be installed on my computers. The most visible one I skip is [Gnome3](https://www.gnome.org/gnome-3/). I really tried to use it on Wheezy. After a month of use, I expected a minimal "get it" moment about that new system. Didn't happen. My workflow doesn't fit at all with Gnome3, and it's a ressource hog on your computer. I am now a [Mate](http://mate-desktop.org/) user. I also remove routinely [Avahi](http://www.avahi.org/) (which only merit seems to bring noise on your LAN) and [PulseAudio](http://www.freedesktop.org/wiki/Software/PulseAudio/). This last one is installed by default with Mate, but often gave me no sound after a fresh install [^1]. When I replace it with Gstreamer, I get sound automagically, and there is one less daemon filling my process table. [^1]: And yes, I did the obvious verifications: unmuting, chosing the correct audio device... On Jessie I tried also [systemd](http://www.freedesktop.org/wiki/Software/systemd/) for a while, read a bit of all the flamewars going on about it and here also I decided it's not for me. My arguments are the following: 1. The existing documentation about systemd is not usable to understand how it works internally; and that is a precondition to be able to debug problems confortably. 2. The claim at modularity from systemd proponents is completely false: as all the various daemons and executables comprising systemd share a huge common codebase, what you have in reality is a monolitic system. The above two facts are enough to stay away from systemd, whose main programmer, surprise, was also the one involved in coding Avahi and PulseAudio. But my main grief about systemd is that it's actually less and less an init system, so it may contaminate too much of your software in the future. I would not object much to systemd if it was only a SysV init replacement. But Debian give it's users the choice to skip the init part of systemd while keeping the problematic non-init part mandatory. So the topic of that article is to explain what you can do to limit the use of systemd on your Jessie system, including the non-init part. As I said above, I use Mate on Debian, so I will cover the use of that desktop on that distribution. ## Debian Jessie with Mate and systemd init So, let's start with a fresh Jessie install. To avoid cluttering my computers with packages I probably won't use, I chose to install only the "standard system" from tasksel before the first reboot. At that point, you will have systemd running, with the following daemons: * systemd (this is the process with PID 1) * systemd-journal * systemd-logind * systemd-udevd (previously called "udevd") For good measure, even it is only "recommended" by systemd, there is also dbus-daemon running. We will need it anyway for a desktop GUI. After the first reboot, I uncheck the "download recommended packages" in [aptitude](https://wiki.debian.org/Aptitude) options, then proceed to install Mate as a task [^2]. [^2]: And if Avahi-daemon is no more installed, the default for Mate is still to use PulseAudio. You can get rid of the PulseAudio daemon by replacing package *mate-settings-daemon-pulse* by package *mate-settings-daemon-gstream*, then suppressing package *pulseaudio*. The installed systemd related packages are then the following: | Package | Installed size | Number of files | Mandatory dependencies | Remark | | :----------- | :-----------: | :------------------: | :---: | -----: | | *systemd* | 12MB | 700 | 20 | | | *libpam-systemd* | 300KB | 15 | 10 | Was installed by Mate | | *systemd-sysv* | 50KB | 25 | 10 | | | *libsystemd0* | 200KB | 10 | 70 | | | *udev* | 6MB | 120 | 85 | | | *libudev1* | 100KB | 10 | 90 | | The mandatory dependencies figure is especially important for *libsystemd0*, *libudev1* and *udev*. *libsystemd0* is mostly used to ensure systemd is present, and the additional functionality offered in that case is (for now...) limited. We have been living with *udev* since a long time and it is needed by *initramfs-tools* and several desktop packages, so it is difficult to get rid of it. The fact that *udev* development was taken over by systemd is the real trouble here; but more about that in the conclusion. ## Debian Jessie with Mate and SysV init Now let's try to replace systemd init by SysV init; this is done by replacing *systemd-sysv* with package *sysvinit-core*. At reboot, from the 4 systemd related daemons present initially, there is only systemd-logind left, and process with PID 1 is now the traditional init. But the 5 other packages related to systemd are still there! So you can still execute commands like "journalctl" or "systemctl", just these are now mostly empty operations. Only "systemd-cgls" and "systemd-cgtop" still provide useful information. So systemd is still sitting on your system, waiting for an upgrade to pull in again *systemd-sysv* and recover its full functionality. At this point, you can put *sysvinit-core* on hold in aptitude. In addition, new packages *systemd-shim*, *cgmanager* (it launches a daemon) and some dependencies have been installed on your system. The following figure shows the dependencies between some packages in our new configuration. [[!img dep-systemd.png size=600x]] ## Debian Jessie with Mate, SysV init and *consolekit* *mate-power-manager* may not be installed on your host (it's mostly a laptop thing). In that case, you can skip that section. Exploring the packages dependencies in [aptitude](https://wiki.debian.org/Aptitude) gives you the following alternative set of packages dependencies: [[!img dep-consolekit.png size=600x]] where package *consolekit* replaces *systemd* at several places. Notice that it is not possible to change/suppress the dependency of *udisks2* and *policykit-1*. So let's go to change to the above figure by installing *consolekit* [^3], as a first step to limit your systemd exposure. [^3]: In the process of installing *consolekit*, you may have lost (or not) the ability to resume/suspend from your Mate desktop; the conditions under which it happens are not clear for me at the moment. But continuing until the end what I suggest in this article will recover eventually that functionality. ## Debian Jessie with Mate, SysV init and a modified *libpam-systemd* As *libpam-systemd* is the only package left depending on *systemd*, the idea is here to modify *libpam-systemd* to get rid of it. To do that, I took the Debian systemd source, which I modified to build a new package *libpam-systemd*. The main steps were the following: 1. In debian/control file, I only allow building of *libpam-systemd*, and added that it breaks and replaces *systemd* 2. I deleted all source files not needed in the compilation of the PAM module and the daemon "systemd-logind" 3. Some other tidying up was done (debian/rules, documentation...) This results in a smaller source package (but not so much, which contradicts the claim to systemd "modularity"). For your convenience, all of the source files and the .deb package (for i386) are here: [[systemd_215-17+deb8u7bu1.dsc]] [[systemd_215-17+deb8u7bu1.tar.gz]] [[systemd_215-17+deb8u7bu1_i386.changes]] [[libpam-systemd_215-17+deb8u7bu1_i386.deb]] If you have installed the needed development packages, it's easy to rebuild file "libpam-systemd_215-17+deb8u7bu1_i386.deb" with these simple commands: # the 2 source files have to be downloaded in your current working directory dpkg-source -x systemd_215-17+deb8u7bu1.dsc cd systemd-215 dpkg-buildpackage -rfakeroot cd .. To install it, you will need some local package repository. An easy method to do it is to run: mkdir -p ~/my-repo/dists/jessie/main/binary-i386 mv libpam-systemd_215-17+deb8u7bu1_i386.deb ~/my-repo/ (cd ~/my-repo; dpkg-scanpackages . /dev/null | gzip > dists/jessie/main/binary-i386/Packages.gz) Notice that "dpkg-scanpackages" is available through package *dpkg-dev*. Then add line (if you are user "joe"): deb file:/home/joe/my-repo/ jessie main to /etc/apt/sources.list and update the available packages in aptitude to take the content of your local repository into account. You can then try to upgrade to the new *libpam-systemd* with aptitude. You will get a conflict. Choose to solve it by suppressing *systemd*, proceed with the upgrade and you are done! Some people may ask why I haven't changed the name of the new package replacing *libpam-systemd* and suppressed in it any reference to systemd. First, its source code is still pure systemd at that point. And secondly: not having string "systemd" in your computer will not make that software vanish from the universe, like not saying "Voldemort" doesn't make that guy disappear as by magic. ## Final remarks Installing the modified package *libpam-systemd* proposed above will allow you to get rid of package *systemd*, while keeping your Mate desktop fully functional. On your computer there will be only packages *libpam-systemd*, *libsystemd0* and *udev*. As said above, there is (for now...) no more harm to continue using packages dependent on *libsystemd0*, as there is to use packages dependent on *libpulse0* (to access PulseAudio) or *libavahi-client3* (to use Avahi), even if you don't have PulseAudio or Avahi daemons running. *udev* is a bit more annoying as its functionality has been used for a long time, so it has penetrated deep in our Debian systems. Someone is working on an independent replacement for *udev* called [*vdev*](https://github.com/jcnelson/vdev). The work seems promising, and I will at one point experience his work. For a more organized solution to avoid systemd in Debian, you can also look at the [Devuan distribution](https://devuan.org/), a fork of Debian; *vdev* is here also a candidate for *udev* replacement. Meanwhile, the last Devuan release has shipped with [*eudev*](https://wiki.gentoo.org/wiki/Eudev), a *udev* fork pushed mainly by Gentoo.