Troubleshooters.Com®, Linux Library
and Steve Litt's Systemd Subsite Present:
What You Can Do About Systemd
Copyright © 2014 by Steve Litt
If you value your GNU/Linux OS as much as I do, and if you believe, as I do, that ubiquitous use of systemd takes your OS in the wrong direction, then you need to take action. Several actions, actually. You need a concerted plan.
Join the Modular-Debian mailing list. The Modular-Debian list also serves as a place to plan our next steps regarding systemd. I think it's likely more than one Free Software project will emerge from the Modular-Debian list.
This list also serves as your contact to the systemd-free community if you lose your posting privileges on Debian-User. Be on Modular-Debian, and be known, before that happens.
The #debianfork channel on irc.freenode.org appears to have about 250 people, and is very active. I was on there for 10 minutes and learned that it's fairly easy to make a systemd-free Manjero, and a pointer to the docs on how to do it.
This is the most important thing you can do. We have a lot of work to do, so we need each other.
There are many solutions to this systemd lock-in problem, so we'll need many projects to save the modular Linux we know today. No one solution will satisfy everyone, any more than any one distro satisfies everyone. We need to populate projects in parallel. A few examples:
We're all in this together. The Modular-Debian list isn't the only place to find folks who understand the lock-in, difficulty of repair, and lessened admin power brought by systemd. Bring others into the fold, introduce them to each other, and try to be an integral part of the road past systemd.
Continue to discuss your position on systemd. The average LUG dweller has a very incomplete picture of what systemd is and does and its pros and cons. Help articulate the position that systemd is entangled to the degree that it greatly impedes troubleshooting, design, installation and maintenance.
There are many who trivialize the change that systemd brings. Be sure to set the record straight in the communities you inhabit. Don't flame, just communicate the true nature of the problem. Ignore those who tell you you're offtopic, or tell you to post to a different list, unless the list rules specifically prohibit talk of the relative merit of init systems.
Understand, you'll be greeted by disbelief and outright hostility. That's OK, that's life. Some day you'll be able to say "I told you so."
One more thing. Don't get so wrapped up in systemd email discussions that it gets time consuming. State your case and move on. Now that Debian and its descendants have, for practical purposes, rejected other init systems, your top priority is finding a suitable systemd-free computer environment. Don't let arguments keep you from that goal.
Oh yes, and one more thing after that. When you discover, install, and migrate to your new systemd-free situation, be sure to tell everyone about it. Especially tell it on the Debian-User mailing list. Sure, you'll get a lot of "shut ups" and hostility, but remember, Debian-User still has list inhabitants trying to escape from systemd.
I'm in a tough spot. If you believe, as I do, that systemd is a bad direction for the OS you use for your daily work, you're in a tough spot too. Our escape from the situation requires our thoroughly reexamining our priorities, because life won't be as easy, post systemd as it was before.
There are many possible solutions and workarounds enabling systemd independence or at least reduction in dependence. Just like no one Linux distro suits everyone, no one of these solutions is a magic bullet, and they're all valuable. Pick one or two, and get to work. Here are some possibilities:
If you're running servers, I would think that a BSD would be a trivially easy escape. Most major server software is ported to *BSD. For many years, *BSD has been known to be a great server -- many would say better than Linux. I would think that for many people deploying servers, going *BSD would be relatively painless.
It's tougher on the desktop, because there's always that one necessary program that doesn't run on BSD. Meanwhile, Docker doesn't run on a BSD kernel, so you can't do it that way. Virtual Machines could be a way out, but OpenBSD, which IMHO is the best OS known to man, doesn't support hardware hooked virtual machines. It's possible that some other BSD's might.
We need people to experiment with, use, document, and exchange information about all the BSD versions, especially in respect to the desktop. Which ones have reasonably consistent package managers? Which ones can run hardware-enhanced virtual machines? Which ones run which programs? Which ones can work with which hardware? Yes, we'll need to go through that whole hardware thing again.
If we're very lucky, this whole thing might be solved by finding, moving to, and thoroughly documenting the right BSD version. Here are a few of the BSD versions available:
Note:
I don't advise using Debian kFreeBSD. Some of the myriad of conflicting information written about Debian/systemd says that kFreeBSD will not be maintained in a systemd world. Is this true? Who knows? Internet-hosted systemd writings are all over the map. The point is, you don't want to invest your scarce time in something with as iffy a future as kFreeBSD.
If you're cool with compiling every package, and remembering to specially set the flags for many package compiles, and the possibility that a bad package addition could brick your OS, then this is the way to go. People who like *too distros love them to death, and these are people I have a lot of respect for. And these are rolling distros, so there's no such thing as major upgrades.
Funtoo has made a point of never supporting systemd, and had a developer extract systemd's dependencies out of Gnome, so you get a systemd-free Gnome with Funtoo.
It should be noted that these distros require many hours to install, because they compile everything. These hours require a small but significant amount of human intervention, so it's not a "start the install and go to to sleep" type of thing. They're rolling distros, so you only install them once unless you brick them, but if you have six machines to do, that could be a problem. Also, if you're anything like me, every once in a while you do brick your OS, at which time the 30 minute Debian or Ubuntu install looks a whole lot better than the *too install.
If one of us makes truly unambiguous documentation of one of these, that will help immensely. Another piece of needed documentation would be an overview of the philosophy and structure of one of these "compile it yourself" distros. A third piece of desperately needed documentation is what to watch out for when installing software, so you don't ruin other software or the whole OS. With the proper documentation, these "compile it yourself" distros could become our way forward.
Obviously, if you use Gentoo or Funtoo or any ports type distro, make sure to do bare-metal backups.
Slackware is kind of crude, and its "package manager" doesn't do dependencies, but I have a lot of friends who swear by Slackware. I'll be trying Slackware soon.
We need good, unambiguous Slackware documentation, and I hope someone writes it soon.
Uselessd bills itself as an unentangled, PID1 only systemd workalike. With uselessd, I'm not sure what you'd use for Pam and ConsoleKit and the like, but uselessd could be interesting. Anyone who has used it successfully, please email me.
Once upon a time, more than ten years ago, a guy named Daniel J. Bernstein, from now on referred to as djb, wrote a daemonizer for his other software such as qmail and djbdns. It was called daemontools, and was so simple, functional, and free from dependencies and entanglements, that many still celebrate its design. In fact, daemontools inspired several people to write their own software in djb's style. Three such daemontools inspired programs are init programs nosh, s6 and runit. These programs have everything you need to bring a system up, everything you need to bring it down (halt, poweroff, and reboot functionalities), and everything you need, while the computer is up, to manage programs. They're tiny and uncomplicated compared to sysvinit, so you can imagine how uncomplicated they are compared to systemd.
We need people to document their experiences running Linux with a nosh, s6 or runit PID1. How did you install it? How did you get rid of systemd? How did you obtain software not depending on systemd? What kinds of problems did you have, and how did you solve them? Did you find any problems that seemed insurmountable?
These programs do nothing about systemd-annexed software such as Pam, ConsoleKit, udev and the like, but I think it might be possible to work around some of those lock-in problems. Get familiar with these programs, either by trying them out, or meeting people who have tried them out.
This is practical only for distributions that retain sysvinit compatibility.
My opinion is that we should treat sysvinit as a temporary step, after which we should transition away from sysvinit, to a well built PID1, as soon as possible. The continued existence of sysvinit generates systemd advocacy.
Systemd incorporates modules formerly separate from PID1, and it appears that interactions between those modules could lead to hard to troubleshoot feedback loops. You can minimize the preceding problems by starting most of your daemons with daemontools, or something similar. In other words, systemd runs daemontools, and daemontools runs all your daemons.
It might seem that this is the worst of all worlds: systemd interactions and dependencies, along with needing to learn daemontools and migrate all your init scripts to daemontools run scripts. But it only seems that way. In fact, starting your daemons from daemontools, which itself is started by systemd, carries the following advantages:
You can also use other daemontools-inspired software with systemd. Bruce Guenter's daemontools-encore is a superset of daemontools. There's also nosh service manager, that can be run under systemd, to spawn your daemons.
Daemontools was never intended to start up daemons in a specific order, which initially seems a problem. Certainly, you want your network running before running httpd. This is not a show-stopper, because you can use any combination of three mechanisms to start things up:
It's pretty simple. You make sure that all service directories start out containing a file called down, which prevents them from starting. Your startup script deletes those down files, one at a time, to facilitate starting in order. Depending on the services, you might need sleep commands between the deletions.
There's also a shutdown script that, in reverse order, first writes a down file so it won't automatically start on daemontools startup, and then sends a svc -d to the service to stop it.
A good case could be made for some services being truly system services, that should be run before, and completely apart from, services like httpd. You could run run those services from a different instance of daemontools. For instance, the system processes such as getty, the filesystems, the network, and the like, could be run from a daemontools supervising directories under the /servicesys directory. These services would probably use a start order script.
The remainder of the scripts could be later run in a second daemontools instance, supervising directories under the /service directory. Those are much less likely to need a start order script, because the first daemontools instance has started all the necessary system processes.
Daemontools uses run scripts for the same purpose as sysvinit's init scripts and systemd's unit files. Daemontools' run scripts are between 1 and 2 orders of magnitude smaller than init scripts, and about the same size as unit files. Because run scripts are full-blown shellscripts, the astute admin can customize them in any way needed, for any use case, whether currently predicted or not.
If starting a service before its dependencies could cause a serious problem, the run script for the service could test for the dependencies being active, retry, and eventually, if too many failures, write a down file to the service's directory so it won't try to start, issue an error message, and move on. I guess a systemd advocate might call that a kludge. I call it the ability to address any use case, whether anticipated or not.
Bottom line, much of what many of us find objectionable about systemd can be at least partially mitigated by placing daemontools, or one of its descendants, between systemd and our daemons.
I find this intriguing. Toward the end of his Broken by design: systemd essay, Rich Felker (dalias) posts a 16 line C program to serve as PID1. The last thing the code does is hand off execution to the /etc/rc program, and of course it's simple enough to change that to any executable in any directory. That executable could then spawn necessary services via daemontools or other software.
So far, all I've done with this is compile the software (I had to add a #include <wait.h> to get it to compile without warnings), but soon I'm actually going to try it. Because if this works, it's a monument to "do one thing and do it well", and it's the way I like my computer to work. If anybody has gotten a computer working with this, please let me know.
Other alternatives are popping up every day, now that a large community is discussing the matter. For instance, from what I hear, it's not difficult to convert Manjaro Linux from systemd to OpenRC.
There's a Linux distro called Gobo Linux that uses directories kind of like djb (Daniel J Bernstein) would. It has the tiniest imaginable community, so it's not easy to get up to speed, but it's the farthest thing from systemd, and might make an excellent server, or even a limited use desktop.
OpenSolaris stopped development years ago, but its successors roll on, in the form of Illumos, OpenIndiana, and other non-Ellisonware OpenSolaris successors. OpenIndiana is under development and you can download either release ISOs or the latest development builds. These do not have systemd, and they sound like they might be very interesting.
Depending on your needs, it's possible that the Plan 9 operating system might be of value. It's not Unix (it was made to be the successor to Unix), so the learning curve will be substantial. As of today, it has no web browser. It's a niche, probably for servers, and of course it has no systemd. You can obtain a live CD from http://plan9.bell-labs.com/plan9/download.html. If nothing else, it serves as an interesting experiment.
There are other no-systemd distros. Porteus, pcLinuxOS, Slackware, and several more. For starters, see
First, we need to make a community with others wanting to mimimize or eliminate systemd from our computers. A good, strong, and technology diverse community to work on any and all alternatives to running systemd, as well as finding, listing and using programs not dependent on systemd.
After that, those of us who don't want systemd controlling our systems need to make a new plan. Just like there are different distros for different people, different people will like one or more of the following plans:
And while we're doing the aforementioned, we need to be evangelizing systemd-free alternatives, and educating the Linux-using world in general why going systemd-less is better, and give pointers on how to learn more.
[ Training | Troubleshooters.Com | Email Steve Litt ]