attachment upload

[reminder] / Avoid_systemd_on_Debian_Jessie_with_Mate.mdwn

# 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.