NOTE: this page treats the treatment of systemd in MX Linux. For an overview of systemd itself, see Systemd overview.
On this page:
MX Linux ships with systemd present but disabled by default. The MX Linux team strongly urges users to remain with this configuration which uses sysvinit instead. This page simply provides information for those interested in the question.
(thanks to Timkb4cq on MX Forum)
Systemd is an init & service manager, largely written by the developers of pulseaudio & udev.
It is more integrated than prior init systems, and can better do parallel operations during startup.
Its service manager and dbus implementation are integrated in the init system, so they all run under PID1 (the first program ID)
Obviously there are strong disagreements whether this is a good idea
or not. Traditionally the init program running under PID1 was as small
as possible so there was less that could go wrong which made your system
unbootable. Also configuration files & log files from these
processes were fairly simple text files for ease of troubleshooting.
Systemd violates these traditions. Logs are binary files by default.
Boot dependencies are taken care automatically instead of manually in
Arguably it adds functionality e.g. in better control of the state of services, and faster boot times because of the dependency optimization.
But in any system things *will* go wrong sooner or later. The more complex the system the more likely it is to happen. And when systemd does go wrong, troubleshooting & repair is more difficult.
The systemd argument is largely an argument about the Unix philosophy:
Write programs that do one thing and do it well.
Write programs to work together.
Write programs to handle text streams, because that is a universal interface.
Systemd doesn’t follow that philosophy very well.
In another way it’s an automatic transmission vs stick shift argument. Do you want full control of your system? Sysadmins are far more likely to notice the drawbacks than the average desktop user. To be fair, systemd is good enough for most users and it’s actively maintained which is no longer the case with sysvinit. OTOH, sysvinit has had a *long* time to weed out the bugs so one wouldn’t expect it to need a lot of maintenance.
Finally, which init system to use is by no means an open and shut case for many people. MX LInux follows the lead of anticapitalista, Bitjam, and the rest of the antiX dev team.
When the GRUB screen is displayed on MX-17, click on Advanced options… and select to use systemd.
- Check Apt GPG may recognize only the Debian repo at first; seems to correct itself after rebooting and updating/upgrading
- Installing Skype sometimes causes problems with the desktop.
- You may find that your /tmp directory is not emptying quite as often as you might like. this causes some odd behavior for a couple of apps, but the fix is easy.
1. copy tmp.conf from /usr/lib/tmpfiles.d to /etc/tmpfiles.d
sudo cp /usr/lib/tmpfiles.d/tmp.conf /etc/tmpfiles.d/tmp.conf
2. add a couple of lines to the /etc/tmpfiles.d/tmp.conf to make your config look like this:
# This file is part of systemd.
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
# See tmpfiles.d(5) for details
# Clear tmp directories separately, to make them easier to override
D /var/tmp 1777 root root –
D /tmp 1777 root root –
#q /var/tmp 1777 root root 30d
# Exclude namespace mountpoints created with PrivateTmp=yes
For some reason, by default, systemd doesn’t empty our /tmp folder like happens with our sysVinit configuration, leading to a never ending buildup of pulseaudio checkfiles, among other things. you are only impacted if you are using systemd for boot/init.