systemdont - how to avoid installing systemd in any distro

Siljrath · 09-02-2014, 06:50 AM

~~~~this content is now a wiki page too, ~which is much nicer, tidier, and will more likely be kept up to date.
http://wiki.linuxquestions.org/wiki/...d_installation
happy de-systemd'ing ~~~~

(disclaimers: use at own risk ~ i have not tested all these methods ~ on distros that have become very systemd-centric there may be bumps in the road ~ if uninstalling systemd to liberate, please ensure you have an init system in place, or are capable of restoring from another os/live environment and chrooting, or happy to reinstall from scratch without systemd in the first place, if your distro so permits)
(disclaimer disclaimer ~ ^ that's just to cover my ass. i'm sure it'll be fine. crack at! enjoy the liberation.)

as seen on my blog, but skipping the outraged rant about systemd and where it seems to be heading (potteringOS), here are the practical tips to help you avoid systemd.

to prevent systemd being installed on your system during upgrades or other package installs:

for debian based systems:

in your /etc/apt/preferences, add:

Code:

Package: systemd
Pin: origin ""
Pin-Priority: -1

or, perhaps overkill:
http://hastebin.com/gihiwasoxi.avrasm

there are more suggested ways to be fished out of: http://forums.debian.net/viewtopic.php?t=116770

(thnx to KittenGNU for this tip...)
https://eurynome.mirbsd.org/debs/debidx.htm
"The MirOS repo has some virtual packages to prevent lennartware to install"

for gentoo/funtoo based systems using portage:
simply include the "-systemd" useflag in your /etc/portage/make.conf, like:

Code:

USE="-systemd"

(along with whatever other useflags you have of course)

for archlinux based systems:
add in your /etc/pacman.conf:

Code:

NoExtract=usr/lib/systemd/system/*

(as advised in the pacman page of archwiki)

for fedora:
best i could find was a thread full of people saying to use another distro. seems fedora is close enough to the belly of the beast, that you're not free to pick your init.
http://forums.fedoraforum.org/showthread.php?t=297418
~please share if u have a solution.
~ maybe switch to something like LSD linux (less systemd linux). *shrug*

for slackware:
you're still good, for now.

for dragora:
you're still good, for now.

for exherbo:
in /etc/paludis/options.conf

Code:

*/* -systemd

you are likely skilled enough to have figured this out for yourself so far, and as with other distros you can find your own choice of init to install.

additionally:
another way to accomplish freedom from systemd and keep the distro you love, is to put that distro into a bedrocklinux installation as a client distro. then you even get to do some cool mix-and-match cross-distro magic, and retain (and leverage) the empoweringness of nix & foss.

please share tips how to avoid systemd in other distros / package managers, and maybe i'll remember to revisit this and keep this original post up to date.
any other corrections, updates, elaborations or softly worded criticisms welcome.

smallpond · 09-02-2014, 08:09 AM

This would be a good idea for a wiki page.

Siljrath · 09-02-2014, 11:07 AM

great idea. i've been looking for a good excuse to get engaged with wiki editing.

http://wiki.linuxquestions.org/wiki/...d_installation

^ my first wiki page.

(not bad for a first go, tho could do with more wiki links, and better arrangement of external links yet.)

i like how writing for wiki encouraged a more objective info-based style, and got me checking my facts more too.

thanks for the suggestion smallpond.

Soderlund · 09-02-2014, 01:54 PM

Quote:

Code:

Package: systemd
Pin: origin ""
Pin-Priority: -1

Nice! This will be useful when upgrading to Jessie. It will otherwise automatically bring in systemd, right?

Siljrath · 09-02-2014, 02:09 PM

Quote:

Originally Posted by Soderlund

Nice! This will be useful when upgrading to Jessie. It will otherwise automatically bring in systemd, right?

that's right.

though i make no guaruntees that all these methods are 100% effective, or will remain 100% effective, but that disclaimer aside, i am fairly confident pinning "systemd*" to a negative number should prevent systemd infestation on a debian system.

if in doubt, go for the overkill method (hastebin link), and/or look before you leap, when installing things to see if anything else ever tries to sneak through. [edit - and then pin in /etc/apt/preferences accordingly if so]

sundialsvcs · 09-02-2014, 03:06 PM

I must admit that you have finally piqued my curiosity. Aside from blah-blah about "evil corporations" and so on, what exactly is "so utterly wrong" about this thing?

lleb · 09-02-2014, 07:02 PM

Quote:

Originally Posted by sundialsvcs

I must admit that you have finally piqued my curiosity. Aside from blah-blah about "evil corporations" and so on, what exactly is "so utterly wrong" about this thing?

yup same question. not wanting to start a flame war by any stretch of the imagination. my personal experience with systemd stems from Fedora 17-20 and now CentOS v7. outside for firewalld in CentOS v7 not functioning properly, i have had very good results with the new systemd. so id like to know what all the hubbub is all about.

Thanks for the info in advance.

Randicus Draco Albus · 09-02-2014, 08:26 PM

All hubbub is not about whether or not systemd works. It is about a disagreement between two camps:
On one side are the people who do not agree with the UNIX-inspired modular design being replaced by an integrated system that puts many processes under the control of one programme.

On the other side are those who believe an integrated system that removes the "problems" of modularity and choice is a good thing.

It is an argument that will not end.

jpollard · 09-02-2014, 09:00 PM

When it works it seems to work...

1. Unfortunately it uses a thundering herd scheduling for a lot of services... What works today may not work tomorrow just by enabling another service.

2. It now permits corrupted logs from being read (they are binary, and not readable except by a custom tool - which doesn't work if something happens to corrupt the file - even a little).

3. It can't be debugged by an administrator when things go wrong.

4. boot hangs, shutdown hangs... and little information about why. Doesn't happen very often with simple systems though... but trying to fix something under pressure is problematical.

5. It depends on network analysis to determine when things should/should not be started/stopped. There are some nice features there, but it is an NP hard problem to solve, and doesn't scale well.

6. It puts all your eggs in one basket. A failure of any part will cause a cascading failure in the rest.

Randicus Draco Albus · 09-02-2014, 09:06 PM

But according to Poettering, it will end the "fragmentation of Linux."

ReaperX7 · 09-02-2014, 09:38 PM

Was GNU/Linux ever in need of such strong-armed consolidation? It was fragmented for a reason, to allow communal contribution to the overall of the whole and segregate services so that if anything went foul, the system would still be working. The only keystone daemon/service of the system was init. Init was the only service that had to not fail under any circumstance.

However, the more you pack into and try to run through PID1, the bigger the instance that if something fails, when it fails, and it fails, the entire system is lost. I dread to think about D-Bus not just being ran through PID1 but the kernel also.

Even smaller alternative init systems don't allow anything into PID1 but the init service supervisor. Everything else is ran separately.

jpollard · 09-02-2014, 10:13 PM

I have a slightly less issue with the part of dbus added to the kernel - it isn't everything, and I think it will be more reliable. And I think what does get there will at least have more security controls available that what currently exists.

Right now Fedora/RH 7/CentOS 7 has some rather big DOS vulnerabilities:
1) using tmpfs for /run AND allowing user writable files permits it to be filled - causing problems for service restarts/starts/login. A big failure here is that the evidence is wiped out when the system reboots or the user logs out.

2) using tmpfs for /tmp at the same time allows the system to be deadlocked.

ReaperX7 · 09-02-2014, 10:24 PM

I never understood one thing about why we needed systemd.

We had Daniel Bernstein's daemontools back nearly a decade ago that did process supervision, parallel service execution and launching, and was able to allow PID1 to self-sustain the system and keep services running if they failed.

How come no distributions ever used that project to supplement sysvinit?

lleb · 09-02-2014, 11:11 PM

interesting inputs. thanks for the heads up.

k3lt01 · 09-02-2014, 11:45 PM

Well here's yet another systemd thread that has gone from a pure help thread that is worthwhile to those who don't want to use systemd, to a thread of lets discuss and bag out individuals. If you use systemd then that is your preference, if you don't that also is your preference. I'd like to see at least 1 systemd thread that doesn't get into bagging individuals or making value judgements about the worthiness of individual distros based on them having or not having systemd. Will I see that in my lifetime (I've probably got another 40 years to go)? probably not.

In Debian Jessie systemd is working fine. I have multiple Jessie installs and not one has a systemd related problem. I would add to this that they all seem to boot slightly quicker with systemd than with the old init system.