Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Systemd bulletin, 2017

Home 2020 2019 2018 2017 2016 2015

For the list of top articles see Recommended Links section

Top Visited
 Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

[Oct 25, 2017] So after 4 hours of debugging systemd and NetworkManager; nothing but pain linux

Oct 25, 2017 | www.reddit.com

This is old but pretty instructive post. Comments provide important tips on how to deal with systemd problems.

it drops the default route every time I reboot the machine

Can't work out how to resolve this at all. Nothing in logs or anything. Two hours down the pan.

ALL of this is config management stuff related to systemd and NetworkManager. Not at all impressed. Excuse the rant but this is motivating me to move our CentOS 5.x machines to FreeBSD which has some semblance of debuggability, configuration management that doesn't make you want to gouge your eyes out and stability.

This feels like Windows, WMI and the registry which is an abhorrent place for Linux to be. I know because I deal with Windows Server as well.

I know there is a fan following of systemd on here but this is what it's like in the real world for those of us who need to argue with it to get shit done, so Dear Lennart (and RedHat): Fuck you for taking away 4 hours of my life and fuck you for forcing these bits of crap on the distributions.

Edit: please read all my replies before you kick me down.

Edit 2: I've spoken to our CTO. 95% of our kit can be moved to windows as it's hosting JVMs so that's going in the mix as well.

I have a few CentOS 7 servers online and have had no trouble with routes being dropped, during reboot or at any other time.

[–] godlesspeon S ] 2 points 3 points 4 points 3 years ago (3 children)

How did you do the install on these? I'm genuinely interested in where this has gone wrong.

[–] e_t_ 8 points 9 points 10 points 3 years ago (2 children)

I went through Anaconda. It wrote a config file to /etc/sysconfig/network-scripts, which NM picks up. I think the same file could be created with nmtui .

[–] godlesspeon S ] 2 points 3 points 4 points 3 years ago (1 child)

I used nmtui and the sysconfig folder is expected (all contents as expected, correctly configured) and this is good hardware (Intel gbit cards).

I will say that the damn thing has just spontaneously started working which is even more worrying as the whole thing is completely non-deterministic. Ugh.

[–] riking27 9 points 10 points 11 points 3 years ago (0 children)

Nondeterministic? Sounds like a missing ordering dependency to me ( After= , Before= ).

Example: NFS mounts need an After=network-online.target to work; anything using the network on stop needs an After=network.target .

[–] azalynx 67 points 68 points 69 points 3 years ago (124 children)

[...] this is motivating me to move our CentOS 5.x machines to FreeBSD which has [...]

As a fan of systemd, I was going to take your side and agree that these issues are unacceptable, until you said this. You're not helping, seriously. Your problem is related to bugs in a piece of software, not to systemd's design philosophy, and especially not to Linux as a whole.

The fact that your solution to some bugs in the software is to throw the baby out with the bathwater, speaks a lot about your attitude. Chances are the issues you mentioned will be resolved as RHEL/CentOS 7 become more deployed, and others run across similar problems and actually report and/or fix the actual bugs instead of embarking on an anti-Lennart crusade and spewing vitriol all over the place.

I would also be willing to fucking bet that other people have had similar problems with every new version of RHEL or CentOS ever, in history, but because this time there's a convenient bullseye in the form of systemd to assign blame to, everyone loses their shit.

[...] and fuck you for forcing these bits of crap on the distributions.

Woah, what? This fallacy again? Red Hat isn't forcing jack shit on anyone . The reality is that many users/businesses need this functionality; just because you don't need it, that doesn't mean that there aren't a thousand other use cases out there that require systemd. Please stop assuming that you are at the center of the universe and that everyone elses use cases are like yours . Distributions have always been designed to be "one-size-fits-all" in order to fit everyone's uses; obviously many distributions want systemd's functionality because they have users who demand it.

Once again, as I said in my first sentence; it's not ok for an enterprise product to have the problems you experienced, but your attitude isn't helping, really. It's also worth noting that if everyone just flipped tables when something broke, we'd never have any progress.

[Sep 27, 2017] Chkservice - An Easy Way to Manage Systemd Units in Terminal

Sep 27, 2017 | linoxide.com

Systemd is a system and service manager for Linux operating systems which introduces the concept of systemd units and provides a number of features such as parallel startup of system services at boot time, on-demand activation of daemons, etc. It helps to manage services on your Linux OS such as starting/stopping/reloading. But to operate on services with systemd, you need to know the different services launched and the name which exactly matches the service. There is a tool provided which can help Linux users to navigate through the different services available on your Linux as you do for the different process in progress on your system with top command.

What is chkservice?

chkservice is a new and handy tool for systemd units management in a terminal. It is a GitHub project developed by Svetlana Linuxenko. It has the particularity to list the differents services presents on your system. You have a view of each service available and you are able to manage it as you want.

Debian:

sudo add-apt-repository ppa:linuxenko/chkservice
sudo apt-get update
sudo apt-get install chkservice

Arch

git clone https://aur.archlinux.org/chkservice.git
cd chkservice
makepkg -si

Fedora

dnf copr enable srakitnican/default
dnf install chkservice

chkservice require super user privileges to make changes into unit states or sysv scripts. For user it works read-only.

Package dependencies:

Build dependencies:

Build and install debian package.

git clone https://github.com/linuxenko/chkservice.git
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr ../
cpack

dpkg -i chkservice-x.x.x.deb

Build release version.

git clone https://github.com/linuxenko/chkservice.git
mkdir build
cd build
cmake ../
make

[Sep 17, 2017] systemd-free.org Archlinux, systemd-free

Notable quotes:
"... Since the adoption of systemd by Arch Linux I've encountered many problems with my systems, ranging from lost temporary files which systemd deemed proper to delete without asking (changing default behaviour on a whim), to total, consistent boot lockups because systemd-210+ couldn't mount an empty /usr/local partition (whereas systemd-208 could; go figure). ..."
"... As each "upgrade" of systemd aggressively assimilated more and more key system components into itself, it became apparent that the only way to avoid this single most critical point of failure was to stay as far away from it as possible. ..."
"... How about defaulting KillUserProcesses to yes , which effectively kills all backgrounded user processes (tmux and screen included) on logout? ..."
Aug 02, 2017 | systemd-free.org

An init system must be an init system

Systemd problems

Since the adoption of systemd by Arch Linux I've encountered many problems with my systems, ranging from lost temporary files which systemd deemed proper to delete without asking (changing default behaviour on a whim), to total, consistent boot lockups because systemd-210+ couldn't mount an empty /usr/local partition (whereas systemd-208 could; go figure).

As each "upgrade" of systemd aggressively assimilated more and more key system components into itself, it became apparent that the only way to avoid this single most critical point of failure was to stay as far away from it as possible.

Reading the list of those system components is daunting: login, pam, getty, syslog, udev, cryptsetup, cron, at, dbus, acpi, cgroups, gnome-session, autofs, tcpwrappers, audit, chroot, mount ... How about defaulting KillUserProcesses to yes , which effectively kills all backgrounded user processes (tmux and screen included) on logout?

It would seem that the only thing still missing from systemd is a decent init system.

The solution: Remove systemd, install OpenRC

"Coincidentally", there were others before me who had had similar concerns and had prepared the way.

Their efforts and experience is summarised in these pages. Sincere, warm thanks go to artoo and Aaditya who have done most of the work in Archland and, of course, the Gentoo developers who have made this possible in the first place. I administer a handsome lot of linux boxes and I've performed the migration procedure (successfully and without exception) in all of them, even remote ones.

The procedure is explained in Installation ; however you might want to read about OpenRC in the links below:

The Archlinux OpenRC wiki page doesn't contain information on the migration process anymore; it breaks down things in several different articles and provides links to other resources not always Arch-specific, which unnecessarily obfuscates things, not to mention the omnipresent warning to not remove systemd. The migration procedure described here instead is reliable and as plain and simple as possible, explaining what is to be done and why in clearly defined steps, despite what a FUD-spreading Arch Wiki admin says against it in his every other post. This is proven time and again on many different boxes and setups.

For your convenience, an up-to-date OpenRC ISO image is also provided for clean installations. Go to Installation for additional information.

Other Linux distros: Escape from systemd

Here we focus on removing systemd from Arch Linux and derivatives: Manjaro, ArchBang, Antergos etc. For information about removing systemd from other Linux distributions (namely Debian and deb/apt-get based ones like Ubuntu and Mint) you can visit the Without systemd wiki .
Additionally, a list of Operating systems without systemd in the default installation might be of special interest as, ultimately, the future of the Linux init systems will be determined by the popularity (or lack thereof) of systemd-free distros like Gentoo , Slackware , PCLinuxOS , Void Linux and Devuan .

Non-Linux OSes are also a viable (if somewhat last-resort) option, especially if the situation for non-systemd setups significantly worsens; FreeBSD and DragonFlyBSD are totally worth taking a shot at.

Clean installations

Contact You may contact us at Freenode, channels #openrc, #manjaro-openrc and #arch-openrc.

[Aug 13, 2017] The Tar Pit - How and why systemd has won

Notable quotes:
"... However, despite this and despite the flame wars it has caused throughout the open source communities, and the endless attempts to boycott it, systemd has already won. Red Hat Enterprise Linux now uses it; Debian made it the default init system for their next version 6 and as a consequence, Ubuntu is replacing Upstart with systemd; openSUSE and Arch have it enabled for quite some time now. Basically every major GNU/Linux distribution is now using it 7 . ..."
"... systemd doesn't even know what the fuck it wants to be. It is variously referred to as a "system daemon" or a "basic userspace building block to make an OS from", both of which are highly ambiguous. [...] Ironically, despite aiming to standardize Linux distributions, it itself has no clear standard, and is perpetually rolling. ..."
Sep 27, 2014 | thetarpit.org

systemd is the work of Lennart Poettering, some guy from Germany who makes free and open source software, and who's been known to rub people the wrong way more than once. In case you haven't heard of him, he's also the author of PulseAudio, also known as that piece of software people often remove from their GNU/Linux systems in order to make their sound work. Like any software engineer, or rather like one who's gotten quite a few projects up and running, Poettering has an ego. Well, this should be about systemd, not about Poettering, but it very well is.

systemd started as a replacement for the System V init process. Like everything else, operating systems have a beginning and an end, and like every other operating system, Linux also has one: the Linux kernel passes control over to user space by executing a predefined process commonly called init , but which can be whatever process the user desires. Now, the problem with the old System V approach is that, well, I don't really know what the problem is with it, other than the fact that it's based on so-called "init scripts" 1 and that this, and maybe a few other design aspects impose some fundamental performance limitations. Of course, there are other aspects, such as the fact that no one ever expects or wants the init process to die, otherwise the whole system will crash.

The broader history is that systemd isn't the first attempt to stand out as a new, "better" init system. Canonical have already tried that with Upstart; Gentoo relies on OpenRC; Android uses a combination between Busybox and their own home-made flavour of initialization scripts, but then again, Android does a lot of things differently. However, contrary to the basic tenets 2 of the Unix philosophy , systemd also aims to do a lot of things differently.

For example, it aims to integrate as many other system-critical daemons as possible: from device management, IPC and logging to session management and time-based scheduling, systemd wants to do it all. This is indeed rather stupid from a software engineering point of view 3 , as it increases software complexity and bugs and the attack surface and whatnot 4 , but I can understand the rationale behind it: the maintainers want more control over everything, so they end up requesting that all other daemons are written as systemd plugins 5 .

However, despite this and despite the flame wars it has caused throughout the open source communities, and the endless attempts to boycott it, systemd has already won. Red Hat Enterprise Linux now uses it; Debian made it the default init system for their next version 6 and as a consequence, Ubuntu is replacing Upstart with systemd; openSUSE and Arch have it enabled for quite some time now. Basically every major GNU/Linux distribution is now using it 7 .

At the end of the day, systemd has won by being integrated into the democratic ecosystem that is GNU/Linux. As much as I hate PulseAudio and as much as I don't like Poettering, I see that distribution developers and maintainers seem to desperately need it, although I must confess I don't really know why. Either way, compare this :

systemd doesn't even know what the fuck it wants to be. It is variously referred to as a "system daemon" or a "basic userspace building block to make an OS from", both of which are highly ambiguous. [...] Ironically, despite aiming to standardize Linux distributions, it itself has no clear standard, and is perpetually rolling.

to this :

Verifiable Systems are closely related to stateless systems: if the underlying storage technology can cryptographically ensure that the vendor-supplied OS is trusted and in a consistent state, then it must be made sure that /etc or /var are either included in the OS image, or simply unnecessary for booting.

and this . Some of the stuff there might be downright weird or unrealistic or bullshit, but other than that, these guys (especially Poettering) have a damn good idea what they want to do and where they're going, unlike many other free software, open source projects.

And now's one of those times when such a clear vision makes all the difference.

  1. That is, it's "imperative" instead of "declarative". Does this matter to the average guy? I haven't the vaguest idea, to be honest. ↩
  2. Some people don't consider software engineering a science, that's why. But I guess it would be fairer to call them "principles", wouldn't it? ↩
  3. One does not simply integrate components for the sake of "integration". There are good reasons to have isolation and well-established communication protocols between software components: for example if I want to build my own udev or cron or you-name-it, systemd won't let me do that, because it "integrates". Well, fuck that. ↩
  4. And guess what; for system software, systemd has a shitload of bugs . This is just not acceptable for production. Not. Acceptable. Ever. ↩
  5. That's what "having systemd as a dependency" really means, no matter how they try to sugarcoat it. ↩
  6. Jessie, at the time of writing. ↩
  7. Well, except Slackware. ↩

[Aug 02, 2017] EWONTFIX - Systemd has 6 service startup notification types, and theyre all wrong

Notable quotes:
"... Socket activation is a misfeature, it doesnt matter if it can be done cross-platform, it's still just dumb. It leads to a system appearing to boot a tiny bit faster, but you can no longer guarantee that everything is actually *up* at that point. I dont care much about speeding up boot times but I would still call that a win - IF it wasnt achieved at the cost of making the entire boot process unreliable, but it's not worth anything like the price you pay here. see more ..."
"... Anyway, the feature creep of systemd is the scary part to many of us. Why does my init process need to be my automounter, my syslog, my inetd? ..."
"... Personally, I'm just horribly upset about them changing the ordering of the start/stop/restart arguments for no good reason. what advantage does systemctl start apache have over systemctl apache start? ..."
"... You know what makes a laptop really boot faster? Without breaking anything? Suspend to disk. ..."
"... Only idiots who spend all their time rebooting and doing nothing else value boot-up times above all else. REAL people, however, have other concerns, such as system security, system integrity, and system brittleness (systemd's mandate that all deamons become dependent upon systemd makes ALL deamons brittle), which destroys longterm system stability. see more ..."
Aug 02, 2017 | ewontfix.com

lucius-cornelius 3 years ago

I'm just a user...

OpenSource began as a philosophical response to a mindset that was regarded as unhealthy and incompatible with freedom. The software is an expression of that philosophical response. So any new software that disregards, or appears to disregard that philosophy, is immediately suspect. It's no surprise, given the corruption of OpenSource in recent years, that we now have a generation of users and developers who don't care about freedom, or security, or simplicity. But it is rather sad.

The KISS principle is fundamental. Adding a new and very complex gadget in order to replace an older, simpler but perfectly functioning gadget, breaks every principle of good design and engineering.
Take GRUB2 (please, it's hideous), GRUB1 was fine, LILO is awesome. Linux had 2 perfectly working boot loaders so what happens? Replace one of them with a far more complex system. It's files have different names, the lines of code are much more complex and long winded. Editing it is not as easy as it was. This is not progress.
This appears to be not about anything other than developer's egos.

I see Linux being dragged into the same muddied waters that Windows and OSX inhabit, in order to placate the same greedy amoral Corporations or the same mindless squawking "journalists", and all to please a mass of people who don't give a damn what OS they run as long as they can gain access to their stuff without having to think/learn/read.
Think of it this way, it's a bit like taking the Mona Lisa down and drawing breasts on it and putting an ipod in one hand so that the masses can "appreciate it", or taking a Mozart symphony and remixing it into a 4 minute drum and bass track but insisting that "it's still a Mozart symphony and classical music lovers can rest assured". It's a tragedy for art lovers and the masses don't care anyway. So you end up trashing your own treasure in the pursuit of the appreciation of those who don't understand what treasure is and would trample it in sheer ignorance if they came near it.

So for me, a mere user, I don't understand the technical arguments, but I understand philosophy and I see the philosophy behind Linux/OpenSource being strangled, slowly and deliberately, by people who either harbour hidden agendas or who don't care about philosophy.

akulkis lucius-cornelius 3 years ago
"This appears to be not about anything other than developer's egos."

Ding! Ding! Ding! We have a winner.

Sievers & Poettering (and i'll throw gregkh in for good measure) are behaving like vandals. This is an indicator of being a psychopath -- they don't care how many people are harmed, and to what extent, as long as they get what they want. I believe we have a pretty good idea from 20th Century European history of where that sort of "will to power (and screw anybody who doesn't have the means to stop me immediately)" mentality leads to. Do I think it will cause 50 million dead like the last incarnation of this that came out of Germany? No. Will it cause a lot of needless misery, and pointless wasting of resources: Yes.

Siosm 3 years ago
Everything you said here is "debunked" by the well written answers in the same thread:

The main method used by systemd to monitor processes is not by monitoring PIDs, it's by using cgroups. You need to put your hatred aside, and really start reading what's actually done by systemd to understand how it works, because those posts clearly show you don't. Yes it is significantly different that what was here before, and yes those changes are somewhat disruptive. This is what makes it interesting.

Stonoho Siosm 3 years ago
I do not want my software to be "interesting." I want it to be reliable. Part of reliability is that it does not depend on the specific operating system I run it on. Cgroups are linux-specific and not suitable for portable software.
greyfade Stonoho 3 years ago
I'm genuinely curious: What about init systems makes cross-platform portability desirable? Worded another way: Why would I want to use a Unix init system on Windows?

I sincerely cannot comprehend why using the native features of the kernel an init system is written for is a bad thing, especially when it enables the init system to (potentially) do a better job? (Let's ignore for the moment whether systemd is actually doing a good job. This is a general question that would apply even if we weren't talking about systemd specifically.)

akulkis greyfade 3 years ago

Uh, Dude, the problem is that systemd is going to make deamons non-portable between Linux and the rest of the Unix world. That's not a feature, it's a very, very, very, very, very, very serious bug.

greyfade akulkis 3 years ago ...

Why is that an issue? Almost every Linux distro and most of the BSDs have been shipping _their own_ init scripts for years, even when a given daemon includes its own. I don't see how this makes daemons non-portable.

akulkis greyfade 3 years ago
Because every deamon is now going to have to have TWO versions -- the Linux systemd compatible version, and the sane one used by BSD and the rest of the unix world.

Poettering summed up his attitude -- Linux isn't unix, so don't give a shit about breaking everything and anything, as long as it feeds his narcisstic craving to control every damned thing. Basically, he's not improving Linux, he's turning it into Windows. If he wants to work on creating a system that's compatible with the Windows philosphy (it's just fabulous write huge, unstable programs with murky boundaries that do lots and lots of things poorly and don't play well with others) then he should get out of Unix and write for the ReactOS people.

It's obvious that Sievers and Poettering want to be the big fish in the pond... so w should encourage them to go to ReactOS... ReactOS needs people like Sievert and Poettering -- the Linux world doesn't. All of this crap of moving tons of things out of /bin to /usr/bin, etc (and then putting in soft links from /bin to /usr/bin, rather than, oh, I don't know, doing something SANE like putting the soft link in /usr/bin pointing at /bin) is an example of the absolute CONTEMPT these two have for the entire Linux community. Things that have worked well for almost half a century should not be thrown out like a baby with the bathwater, for the (dubious) goal of shaving 5 seconds (and usually not even that) off of boot-up time --- because what, we don't use our computers to get actual work done, we just sit around all day rebooting !?!?!?!?!?!??! Who the hell cares if a computer takes 10 seconds or 2 minutes to reboot -- it's not something you do that often. And the only computers which ARE booted up frequently (laptops) aren't running dozens upon dozens of system services to make for a long boot-up anyways.

Even my laptop, I only reboot once every couple of weeks.

Frankly, I regard Sievers and Poettering as nothing less than vandals, because they are breaking far more than fixing. For a pair who profess to be systems programmers, they seem to be utterly clueless about issues and mechanisms directly linked to system stability vs. instability.

Overly complicated PID 1 is a perfect example.

digi_owl akulkis 3 years ago

Honestly i dont think Poettering and crew is gunning for Windows. They are trying to create OSX without the Apple hardware dongles. But then they also work for a company that is likely trying to supplant Sun Solaris. Just about everything that comes out of RH these days are gunning for some kind of "secure" workstation for government/corporate work. Maybe with a solid dose of cloud thrown in on top to spite Oracle (who owns Sun these days).

akulkis digi_owl 2 years ago
OS X is BSD underneath. They are certainly NOT trying to create BSD. BSD's init system is even more simplistic than SysV init
digi_owl akulkis 2 years ago
OSX use Launchd, and some want to see that transfered to the BSDs. But at this point Systemd is much more than Launchd, never mind SUN's SMF.

At this point it may be as relevant to talk about Systemd/Linux as it is to talk about GNU/Linux.

But look at the projects Poettering has initiated and they are all more or less inspired by OSX. He pretty much admitted as much in an interview some years back.

svartalf digi_owl 2 years ago
The problem is...everything that they're doing ensures that it won't BE secure. That's the most laughable thing about this cruelty joke Red Hat's inflicting on us. They used to be friends...but with friends like that, who needs enemis...
svartalf akulkis 2 years ago
I'd opine that neither are really systems programmers. This is evidenced by at least Pottering's partial failures over time, including PulseAudio which honestly breaks more than it fixes and is really solving problems you and most everyone else (99.9999...%) don't have, nor will they ever have.

This is something that is very much *MISSION CRITICAL*, meaning it really needs to be this largely armor-plated, can't really ever fail, piece of software. So far, Lennart has yet to write a piece of software like this. He's got...interesting...notions... But they should've never been given the time of day in most of the cases, mainly because if you'd done the mental exercises most actual systems developers do, you'd realize that they're all solutions looking for a problem to fix.. Remote network audio is, quite frankly, something already solved and his "solution" added issues including needless latency in things.

His logging solution in systemd is excreable- and this massive mission/function creep abortion they call systemd is, quite simply, too complex- it's attempting to build an OS abstraction on top of an...heh...OS abstraction already there. It's almost like the One Ring. That's not a systems programmer there. It's a wannabe.

akulkis svartalf 2 years ago

You have summed it up very well. These guys are applications programmers posing as systems programmers. see more

svartalf greyfade 2 years ago
It's an issue because it's more akin to the welded shut hood of your vehicle versus what you currently have. If a *BSD variant wants something resembling systemd, the best they can hope for is the winnowed down fork labeled uselessd that does NOTHING but handle the boot dependencies, etc.

With the old way, while it was clunky and "slow" (I'd opine that "fast" is only relevant in the *EMBEDDED* and *CONSUMER DEVICE* spaces, not the server spaces -- you shouldn't NEED fast boot times for a server...) you could "port" it in the large to your system or at least HACK your needed daemon start script into the system. With systemd, you don't get that luxury. It needs to be systemd-ed and you can just pretty much kiss anything other than Linux support goodbye- or support the "old" way and the "new" way at the same time.

It's stupid. It's a damned waste of valuable time. And better yet, this doesn't even get into the lack of actual mission-criticalness that is needed in the server and embedded spaces- that this damn thing DOES NOT AND CAN NOT HAVE because of it's poor design decisions. I keep questioning why in the hell Red Hat keeps the man on their payroll, this is that bad.

greyfade svartalf 2 years ago
Your argument is one that doesn't seem, to me, to support your case.

Why would BSD want systemd? That's the core of my main objection to the argument that systemd's lack of portability is bad: It's a Linux init system that uses Linux kernel features to do its more interesting jobs, so why would any other platform want it?

Why would you have to hack your daemon? Systemd supports launching daemons via init script, and with an extension, supports sysvinit-style scripts. The systemd-specific code that enables systemd optimization for a daemon amounts to an #ifdef for a few lines of code and a single C file that can be simply excluded from your build to support non-systemd systems. How does this mean that you have to "kiss anything other than Linux support goodbye"?

You are, to be blunt, merely regurgitating the same long-debunked arguments I've seen discussed a hundred times, and still not answering my question.

akulkis greyfade 2 years ago

The reason BSD doesn't want systemd is because systemd is a steaming pile of excrement. NO SANE PERSON wants systemd. see more

SomeoneWithAClue akulkis 3 years ago

systemd's socket activation support relies on features that have been available on every decent Unix-like system for ages. So does its readiness notification support (as outlined above). Therefore they can both be implemented on *every* Unix with a minimal amout of fuss. How exactly is this supposed to make a daemon unportable? see more

Arker SomeoneWithAClue 3 years ago

Socket activation is a misfeature, it doesnt matter if it can be done cross-platform, it's still just dumb. It leads to a system appearing to boot a tiny bit faster, but you can no longer guarantee that everything is actually *up* at that point. I dont care much about speeding up boot times but I would still call that a win - IF it wasnt achieved at the cost of making the entire boot process unreliable, but it's not worth anything like the price you pay here. see more

sarlalian greyfade 3 years ago

Thats the problem with Systemd, is it's not a Unix init system, its a linux init system. If it were a unix init system, it wouldn't depend on things like cgroups existing. cgroups aren't part of the posix spec, they don't exist on FreeBSD, OpenBSD, NetBSD, Solaris and really any others. There are numerous other problems with the nested dependencies of systemd, its not friendly with running inside containers. I'm sure most people who don't like systemd would have less issues with it, if the pid 1 portion of systemd were smaller and less complex. The problem is if pid 1 dies, or needs to be updated, this results in a crash or reboot.

Anyway, the feature creep of systemd is the scary part to many of us. Why does my init process need to be my automounter, my syslog, my inetd?

Personally, I'm just horribly upset about them changing the ordering of the start/stop/restart arguments for no good reason. what advantage does systemctl start apache have over systemctl apache start?

greyfade sarlalian 3 years ago

This does not answer my question. Why is it a bad thing for it to be a Linux init system? Why does conforming to the POSIX spec matter for a Linux init system?

We can talk about dependencies and argue about features, sure. But what I don't understand is this fetishistic obsession with POSIX when we're talking about a freaking init system. I'm not aware of POSIX imposing any requirements on the init system other than a small subset of interactions with it, so why is this such a big deal? Why do you even care?

I understand, and to some degree, agree with the concerns about feature creep. But the rest of your arguments are little more than bikeshedding, and don't really explain why systemd is objectively bad.

sarlalian greyfade 3 years ago

Technically your question was about running a "unix" init system on windows. My point which did answer that question was that it isn't a "unix" init system, it is a Linux init system. While POSIX isn't some sort of panacea it does imply some level of portability across unix and unix like systems, and for an init system that is important to a lot of people. Especially when systemd apparently provides non-portable (dbus and sd_notify) ways for daemons to implement some concept of service activation.

From a desktop perspective, systemd looks fantastic, it has a ton of neat features that will make a linux laptop boot up faster, and use less resources on startup these are good things, it is also substantially more usable than the usability nightmare that is launchd which is where the systemd authors got a lot of their ideas. I'm not really against sytemd on the desktop, on the server however, where security and stability matter it leaves some things to be desired.

Objective problems with systemd on the server:

1) PID 1 is arguably the most important process, if it halts your sever halts, ideally PID 1 should be the simplest, most tested program you have running so that it won't halt ever, and never needs to be upgraded.

2) It depends on too many libraries for such a critical program. I understand that many of those libraries are well tested, best of breed, but each library increases the attack surface of critical parts of a servers infrastructure. This increased attack surface makes it more likely that there will be root exploits available for it, and decreases the overall security and stability of a system.

3) AutoFS systems suck in general, and when the automounter doesn't work correctly, services and systems hang, and this is not a good thing.

4) Not that I've spent a lot of time trying to get it to work in a docker container, but evidently it is non-trivial to get systemd to work as PID 1 in a container due to dbus and cgroup dependencies, so I end up with an init process for my overall system, and a separate init process for my containers.

5) Because it is tied so directly to Linux, I end up with one init system for my workstations (Fedora based due to external vendor requirements), and my other servers FreeBSD based.

Subjective problems with systemd.

1) It violates the unix philosophy "This is 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."

2) Hubris, obviously we know better than the syslog/syslog-ng/rsyslog/inetd/xinetd/autofs/automounter/amd people... They are experts in their domain, who cares, we can do better, and include it in the init process.

3) The main developers of systemd appear to be jackasses.

- Lennart Poettering ( https://archive.fosdem.org/... "In fact, the way I see things the Linux API has been taking the role of the POSIX API and Linux is the focal point of all Free Software development. Due to that I can only recommend developers to try to hack with only Linux in mind and experience the freedom and the opportunities this offers you. So, get yourself a copy of The Linux Programming Interface, ignore everything it says about POSIX compatibility and hack away your amazing Linux software. It's quite relieving!" (Obviously Linux is the whole of the unix universe).

- Kay Sievers ( https://bugs.freedesktop.or... The whole kernel debug argument being parsed by systemd and screwing things up for the kernel blowup from a couple of months back.

4) The systemd dev's seem to have the worst case of NIH (Not invented here) Syndrome I've ever seen. We are creating an init system.. need to make sure it has AutoFS, xinetd, Syslog, DHCP, Device Detection

5) The whole boot speed at the cost of sanity attitude drives me nuts.

Anyway, to address your bikesheding accusation, an init system SHOULD more resemble a bike shed than a nuclear power plant, but systemd seems to be aiming for kernel level complexity vs. bike shed level simplicity.

Arker sarlalian 3 years ago

You know what makes a laptop really boot faster? Without breaking anything? Suspend to disk.
akulkis Arker 2 years ago
Only idiots who spend all their time rebooting and doing nothing else value boot-up times above all else. REAL people, however, have other concerns, such as system security, system integrity, and system brittleness (systemd's mandate that all deamons become dependent upon systemd makes ALL deamons brittle), which destroys longterm system stability. see more
greyfade sarlalian 3 years ago
Again, you have not addressed my question.

I pointed out myself that it's not a Unix init system, and that it has no reason to be one. My point about portability to Windows was to highlight that although it has some POSIX compatibility, there's no rationale for bringing a Unix init system to it. And that highlights my core question: Why does it matter that it be a POSIX init system? It's not meant to be portable, so there is no rationale I can find to justify making it portable. (Why would you even want to use systemd on BSD?) I wasn't asking if it should be portable to Windows, I was asking *WHY* it should ever be portable to anything other than Linux. You have dodged this question four times now.

I have already conceded twice that there are valid objective problems. Your points 1 and 4 (and to a lesser degree 2) are among them. 3 I will not address, because I have not encountered such problems, and have not seen them documented. Your "objective" point 5 is what I accuse of bikeshedding, as you have not presented a case as to why a least common denominator, featureless, aging, limited init system is preferable to having an init system which takes advantage of the features a platform has to offer. I would take the same position if we were talking about some new hypothetical FreeBSD init system: If it takes advantage of FreeBSD-specific features, why should it be portable to, say, OpenBSD?

To your subjective points:

1) I disagree with taking a dogmatic stance on the Unix philosophy. All philosophies have limits to their applicability (there is no universal philosophy, IMO), and there are numerous reasonable rationales for having a more complex communication protocol between subprocesses than a text stream. I do not find this a convincing argument.

2) This appeal to authority is much less convincing. It is hubris, I would claim, to think that someone else *can't* do it better than you.

3) I can make the same accusation of Linus (Why would you use Linux? Linus is an asshole!), Theo de Raadt (Why would you use OpenBSD or OpenSSH? Theo is an asshole!), Dan J. Bernstein (Why would you use djbdns or qmail or...) and on and on. For every amazing piece of software, there's a raging asshole behind it. This argument is unconvincing, and tells me that you're scrambling for justification.

4) On balance, there are problems with the most commonly-used variants of each of those tools. hid-dbus, xinetd, syslog-ng, dhcpcd, and several others have all sent me flying into a rage about some silly thing at one time or another, and I, for one, *welcome* more alternatives. If you think you can do better, by all means, *please do.* I think you're an asshole, but I'll at least give it a shot.

5) The whole POSIX-or-nothing attitude drives me nuts. What's your point?

sarlalian greyfade 3 years ago
Your original statement was "I'm genuinely curious: What about init systems makes cross-platform portability desirable? Worded another way: Why would I want to use a Unix init system on Windows?", maybe I'm reading that wrong, but it really does seem like you called it a UNIX init system there and asked why it should be portable to Windows. If your point about windows was that it has some POSIX compatibility then I failed at reading between the lines there, because what I read was 1) an assertion that it is a Unix init system which to me implies some degree of portability to other Unix / Unix like systems, and 2) a question about why you would want to use it on windows. Yes, in retrospect it probably should have been obvious that you were making an intentionally absurd statement about using a unix init system on windows, but I missed that point and for that apologize. My first response was more about correcting the assertion that it was a Unix init system, which is a factually incorrect statement. I don't think anyone really cares whether its POSIX or not, some people care about the byproduct of it being POSIX or not and that byproduct is some degree of portability, personally for me, whether its portable or not doesn't matter at all, I was wrong in including portability in my list of objective problems with systemd, as its definitely a subjective problem with it, and a subjective problem that I don't have with it, but some others do. I evidently got carried away with my second response ( https://xkcd.com/386/) , sorry. I really haven't been dodging the portability question, I just don't care whether its portable or not as far as problems with systemd go, portability is about as close to the bottom of the list as it gets for me.

That said, I've never asserted that SysV init is better or that I prefer it in any way shape or form, should it be replace, absolutely, is systemd the answer? I hope not, but evidently most people disagree with me on this one. And to be fair I'm not a developer of any init system, so everything I say should be taken with a grain of salt. Is my point 5 bikeshedding, probably because upon further reflection, I don't care if its portable or not.

For my subjective points, great, you disagree with me on my opinion and think I'm an asshole, good for you. Have a lovely day.

greyfade sarlalian 3 years ago
I'm sorry my original question caused confusion. I was trying to make the point that if portability of systemd to a *BSD is desirable, then logically that means that for the same reasons an init system for a genetic Unix should be in turn portable to Windows. I wasn't calling systemd a Unix init system, just pointing out the consequences of the logic, as it applies to init systems in general.

And please don't take my tone as confrontational. I'm just trying to get rational explanations for the animosity towards systemd, many of which seem to me to be completely baseless complaints. (Though, as I said, there are valid complaints and I try to acknowledge them when they're mentioned, but they're few and don't really support the case that systemd is somehow bad.)

sarlalian greyfade 3 years ago
Systemd's portability isn't really that important, the only place where it causes issues is when it makes other daemons depend on systemd specific functions like the sd_notify function. That said, thats really only a #ifdef away from not being an issue if you are on a system that doesn't support sd_notify which to me makes it a pretty trivial issue and relatively easy to port around.

As for taking your tone as confrontational, its really difficult to read identify tone in a string of text, that said, you did say you think I'm an asshole, and I'm not sure that being called an asshole can ever be interpreted as non-confrontational between strangers on the internet.

Any personal animosity (probably an overly strong word for a feeling about an init system) I have for it comes down to the simple statement that it trades stability, security and simplicity for features that I don't care much about in a server operating system. And the absolutely stupid annoying %$^#&^$^%%$# change of the location of start/stop/restart in the systemctl command as compared to the service command. (Yes I'm aware that service is still available but its less informative than systemctl).

greyfade sarlalian • 3 years ago
The "asshole" bit was an illustrative response. I'm sorry. You depicted these developers as unsavory people, and I was trying to point out that that is a ludicrous point to be making in matters of software - plenty of assholes (many of whom I like) write great software, so demeaning the software based on their personality is simply wrong.

On a lighter note, it may not be a bad idea to add a set of functions to your shell .rc scripts to wrap the functionality of service management in a way that's more sensible to you. I agree the differences are annoying, but short of proposing changes upstream, there's little you can do about it.

greyfade 3 years ago
"(Why would you even want to use systemd on BSD?)"

I would not want to run systemd on my system, regardless of kernel. But the pressure to do so, again regardless of kernel, is simply to get a program that depends on it to run. To the degree the systemd cabal gets more and more software to depend on this more and more people will be inconvenienced by it.

More generally, why would I not want to run a 'linux only' init system? The same reason I dont want to run 'linux only' anything. I have been using *nix for over 20 years, I have migrated distributions, I have migrated kernels, and having the freedom to do that again whenever necessary is important.

greyfade Arker 3 years ago
You're not the first to make this point, and I'm still frustrated by it, because it makes little sense, and still fails to answer my question.

Swapping out a kernel in an environment is not so trivial a matter. Switching between different versions of Linux is fine, since the ABI hasn't changed all that much over the years, and so there's little worry about a software distribution working across several kernel versions. But swapping out a Linux kernel for something entirely different is another matter. I understand that the BSD emulation of the Linux ABI is incomplete, and so swapping out Linux for a BSD kernel is going to cause a great number of headaches - the init system is the least of your concerns.

But I do not understand why you're so concerned about being able to do such a thing, especially when doing so necessarily means a substantial change in the operating environment, let alone binary loader behavior differences and ABI differences that will inevitably break a number of core features.

It's fine if you want to just use a software distribution where systemd is unsupported, but making such drastic changes to a running system is at best inadvisable, even ignoring the matter of the init system or the difficulties in changing libc.so or other critical infrastructure.

akulkis greyfade 2 years ago
your points have been addressed repeatedly.

If you don't want to listen, tha'ts your problem. Now, sit the hell down and shut the hell up, and LISTEN, Lennart.

akulkis sarlalian 2 years ago
And it doesn't even deliver the faster bootup time which is supposedly the justification for all of this BS.
akulkis greyfade 2 years ago
BS, Grayfade. We have answered your question repeatedly. Stop being a concern troll.
greyfade akulkis 2 years ago
No, you really haven't. I asked why portability and POSIX-compliance is so important for systemd. I have never gotten an answer. I asked why anyone would want systemd portable to systems like BSD. All I get is complaints that no one would because it sucks. That doesn't answer my questions. If you're going to say systemd sucks and then give me reasons it sucks, I'm going to expect your reasoning to make sense.

But you don't have reasoning that I can see. All you're doing is complaining that it sucks. Well, that's useless.

And then you keep bugging me several months after I've long forgotten about this post and call *me* a troll?

Please, just drop the subject. You're clearly not interested in conversation or reasonable discussion, so please don't reply to me again unless you have actual, reasoned answers to my questions.

pydsigner greyfade 2 years ago
It matters because a dev doesn't want to have to maintain separate daemon codebases to support both Linux and BSD. That might seem like an edge case, but if you write something to use all of the systemd interfaces because you aren't concerned about having to run it on other UNIX systems, the people who want to use your project on BSD will be left to reimplement daemonization themselves.
greyfade pydsigner 2 years ago
They don't have to maintain a separate daemon codebase. They can continue to use their old rc script and the systemd compatibility layer can run that script just fine. Or, a simple unit file can run the daemon directly.

It's only if the daemon needs to directly manage systemd services or take advantage of systemd-specific features that maintaining additional code becomes a concern.

Now, if a daemon uses systemd libraries, I have to question the motivation for porting that daemon to another OS. Clearly, if the daemon performs some task relevant to systemd, what reason is there for it to perform the same task on a system with no systemd?

Conversely, if a daemon does not rely on systemd, but just links the libraries, I have to question the motivation for linking to those libraries. If they're not needed, why link?

I still don't see the argument.

Sebastian Freundt SomeoneWithAClue 2 years ago

Interestingly, that's not true. See https://bugzilla.novell.com... see more

akulkis SomeoneWithAClue 2 years ago

And what if it crashes in the process?
What if there's a bug in the serialization?
What if there's a bug in the de-serialization in the upgraded version of systemd that just got exec()ed by the old version of systemd? see more

Sebastian Freundt akulkis 2 years ago

I can tell you what happens when (not if) it crashes: https://bugzilla.novell.com... see more

akulkis Sebastian Freundt 2 years ago

Yes, I know. It's that Someone With[OUT] a Clue doesn't seem to understand how systemd's pid 1 is overly complex, and by that, I mean, anything more complex than a process which spawns off the rest of the init system, and then sits around reaping orphans. see more

OrenWithAnE greyfade 3 years ago
It's fragile. If the cgroup implementation changes (aka, Linus feels like it) then we all feel the pain. Option #1 above relies only on the guaranteed behavior on compliant POSIX systems. It's anti-fragile.

greyfade OrenWithAnE 3 years ago

That's a completely ridiculous argument. One need only look at the last few months of LKML discussion to see that Linus is absolutely dogmatic about never, under any circumstances, breaking userland. He has gone on dozens of long rants at people for changing something that broke a userland program, shouting obscenities for days about it.

If you think the cgroups ABI changing is at all a problem, then you clearly haven't paid one whit of attention to kernel development. Kernel ABIs that are in use never change without massive cooperative efforts.

sarlalian greyfade 3 years ago

Considering that they were considering hiding some kernel arguments from systemd because it was screwing up their ability to debug the kernel, http://www.phoronix.com/sca... I think you may be overestimating Linus's feelings about breaking systemd. see more

OrenWithAnE greyfade 3 years ago

Is there a normative document spelling out the specifications and contract for cgroups, equivalent to the POSIX spec for socket writes?

greyfade OrenWithAnE 3 years ago

Yes. In the kernel docs, where it's supposed to be. And if the ABI for it changes at any time and breaks anything, Linus will bite everyones' heads off and revert the change after dressing everyone down. And if the ABI actually needs to be changed, there will be extended discussion, Linus will complain that everyone is violating his Rule #1, then all of the users of the API will agree on a migration plan to the new ABI, then it'll get changed. Remember Linux kernel development rule #1: DON'T BREAK USERSPACE.

Again, it's an absurd argument. Linux is not a Unix, and there is absolutely no reason for the init system to be portable beyond Linux. You haven't answered my question. You've only presented an ill-posed and illogical half-argument that seems to be predicated on the fact that it's not POSIX, which, as I've already pointed out, isn't relevant. Systemd is a Linux init system, not a POSIX init system. The question remains: What about init systems makes portability desirable?

[Aug 02, 2017] CentOS - RHEL 7 How to disable NetworkManager

Aug 02, 2017 | thegeekdiary.com
CentOS / RHEL 7 : How to disable NetworkManager

By Sandeep

Disabling NetworkManager

The following steps will disable NetworkManager service and allows the interface to be managed only by network service.

1. To check which are the interfaces managed by NetworkManager 

# nmcli device status

This displays a table that lists all network interfaces along with their STATE. If Network Manager is not controlling an interface, its STATE will be listed as unmanaged . Any other value indicates the interface is under Network Manager control.

2. Stop the NetworkManager service: 

# systemctl stop NetworkManager

3. Disable the service permanently: 

# systemctl disable NetworkManager

4. To confirm the NetworkManager service has been disabled 

# systemctl list-unit-files | grep NetworkManager

5. Add the below parameter in /etc/sysconfig/network-scripts/ifcfg-ethX of interfaces that are managed by NetworkManager to make it unmanaged. 

NM_CONTROLLED="no"
Note: Be sure to change the NM_CONTROLLED="yes" to " no " or the network service may complain about "Connection activation failed" when it cannot find an interface to start Switching to "network" service

When the NetworkManager is disabled, the interface can be configured for use with the network service. Follow the steps below to configure and interface using network services.

1. Set the IP address in the configuration file: /etc/sysconfig/network-scripts/ifcfg-eth0. Set the NM_CONTROLLED value to no and assign a static IP address in the file. 

NAME="eth0"
HWADDR=...
ONBOOT=yes
BOOTPROTO=none
IPADDR=...
NETMASK=...
GATEWAY=...
TYPE=Ethernet
NM_CONTROLLED=no

2. Set the DNS servers to be used by adding into the file: /etc/resolv.conf : 

nameserver [server 1]
nameserver [server 2]

3. Enable the network service 

# systemctl enable network

4. Restart the network service 

# systemctl restart network

Filed Under: CentOS/RHEL 7

Some more articles you might also be interested in
  1. CentOS / RHEL 7 : Never run the iptables service and FirewallD service at the same time!
  2. RHEL 7 – RHCSA Notes – Create and manage Access Control Lists (ACLs)
  3. CentOS / RHEL 7 : How to boot into Rescue Mode or Emergency Mode
  4. CentOS / RHEL 7 : Change default kernel (boot with old kernel)
  5. CentOS / RHEL 7 : How to start / Stop Firewalld
  6. CentOS / RHEL 7 : Unable to start/enable iptables
  7. CentOS / RHEL : Configure yum automatic updates with yum-cron service
  8. CentOS / RHEL 7 : How to Change Timezone
  9. CentOS / RHEL 7 : How to add a kernel parameter only to a specific kernel
  10. CentOS / RHEL 7 : Booting process

[Aug 02, 2017] EWONTFIX - Broken by design systemd

Notable quotes:
"... difficult not to use ..."
Aug 02, 2017 | ewontfix.com
Broken by design: systemd 09 Feb 2014 19:56:09 GMT

Recently the topic of systemd has come up quite a bit in various communities in which I'm involved, including the musl IRC channel and on the Busybox mailing list .

While the attitude towards systemd in these communities is largely negative, much of what I've seen has been either dismissable by folks in different circles as mere conservatism, or tempered by an idea that despite its flaws, "the design is sound". This latter view comes with the notion that systemd's flaws are fixable without scrapping it or otherwise incurring major costs, and therefore not a major obstacle to adopting systemd.

My view is that this idea is wrong: systemd is broken by design , and despite offering highly enticing improvements over legacy init systems, it also brings major regressions in terms of many of the areas Linux is expected to excel: security, stability, and not having to reboot to upgrade your system.

The first big problem: PID 1

On unix systems, PID 1 is special. Orphaned processes (including a special case: daemons which orphan themselves) get reparented to PID 1. There are also some special signal semantics with respect to PID 1, and perhaps most importantly, if PID 1 crashes or exits, the whole system goes down (kernel panic).

Among the reasons systemd wants/needs to run as PID 1 is getting parenthood of badly-behaved daemons that orphan themselves, preventing their immediate parent from knowing their PID to signal or wait on them.

Unfortunately, it also gets the other properties, including bringing down the whole system when it crashes. This matters because systemd is complex. A lot more complex than traditional init systems. When I say complex, I don't mean in a lines-of-code sense. I mean in terms of the possible inputs and code paths that may be activated at runtime. While legacy init systems basically deal with no inputs except SIGCHLD from orphaned processes exiting and manual runlevel changes performed by the administrator, systemd deals with all sorts of inputs, including device insertion and removal, changes to mount points and watched points in the filesystem, and even a public DBus-based API. These in turn entail resource allocation, file parsing, message parsing, string handling, and so on. This brings us to:

The second big problem: Attack Surface

On a hardened system without systemd, you have at most one root-privileged process with any exposed surface: sshd. Everything else is either running as unprivileged users or does not have any channel for providing it input except local input from root. Using systemd then more than doubles the attack surface.

This increased and unreasonable risk is not inherent to systemd's goal of fixing legacy init. However it is inherent to the systemd design philosophy of putting everything into the init process.

The third big problem: Reboot to Upgrade

Windows Update rebooting

Fundamentally, upgrading should never require rebooting unless the component being upgraded is the kernel. Even then, for security updates, it's ideal to have a "hot-patch" that can be applied as a loadable kernel module to mitigate the security issue until rebooting with the new kernel is appropriate.

Unfortunately, by moving large amounts of functionality that's likely to need to be upgraded into PID 1, systemd makes it impossible to upgrade without rebooting. This leads to "Linux" becoming the laughing stock of Windows fans , as happened with Ubuntu a long time ago.

Possible counter-arguments

With regards to security , one could ask why can't desktop systems use systemd, and leave server systems to find something else. But I think this line of reasoning is flawed in at least three ways:

  1. Many of the selling-point features of systemd are server-oriented. State-of-the-art transaction-style handling of daemon starting and stopping is not a feature that's useful on desktop systems. The intended audience for that sort of thing is clearly servers.
  2. The desktop is quickly becoming irrelevant. The future platform is going to be mobile and is going to be dealing with the reality of running untrusted applications. While the desktop made the unix distinction of local user accounts largely irrelevant, the coming of mobile app ecosystems full of potentially-malicious apps makes "local security" more important than ever.
  3. The crowd pushing systemd, possibly including its author, is not content to have systemd be one choice among many. By providing public APIs intended to be used by other applications, systemd has set itself up to be difficult not to use once it achieves a certain adoption threshold.

With regards to upgrades , systemd's systemctl has a daemon-reexec command to make systemd serialize its state, re-exec itself, and continue uninterrupted. This could perhaps be used to switch to a new version without rebooting. Various programs already use this technique, such as the IRC client irssi which lets you /upgrade without dropping any connections. Unfortunately, this brings us back to the issue of PID 1 being special. For normal applications, if re-execing fails, the worst that happens is the process dies and gets restarted (either manually or by some monitoring process) if necessary. However for PID 1, if re-execing itself fails, the whole system goes down (kernel panic).

For common reasons it might fail, the execve syscall returns failure in the original process image, allowing the program to handle the error. However, failure of execve is not entirely atomic:

In addition, systemd might fail to restore its serialized state due to resource allocation failures, or if the old and new versions have diverged sufficiently that the old state is not usable by the new version.

So if not systemd, what? Debian's discussion of whether to adopt systemd or not basically devolved into a false dichotomy between systemd and upstart. And except among grumpy old luddites, keeping legacy sysvinit is not an attractive option. So despite all its flaws, is systemd still the best option?

No.

None of the things systemd "does right" are at all revolutionary. They've been done many times before. DJB's daemontools , runit , and Supervisor , among others, have solved the "legacy init is broken" problem over and over again (though each with some of their own flaws). Their failure to displace legacy sysvinit in major distributions had nothing to do with whether they solved the problem, and everything to do with marketing. Said differently, there's nothing great and revolutionary about systemd. Its popularity is purely the result of an aggressive, dictatorial marketing strategy including elements such as:

So how should init be done right?

The Unix way: with simple self-contained programs that do one thing and do it well.

First, get everything out of PID 1:

The systemd way: Take advantage of special properties of pid 1 to the maximum extent possible. This leads to ever-expanding scope creep and exacerbates all of the problems described above (and probably many more yet to be discovered).

The right way: Do away with everything special about pid 1 by making pid 1 do nothing but start the real init script and then just reap zombies:

#define _XOPEN_SOURCE 700
#include <signal.h>
#include <unistd.h>

int main()
{
    sigset_t set;
    int status;

    if (getpid() != 1) return 1;

    sigfillset(&set);
    sigprocmask(SIG_BLOCK, &set, 0);

    if (fork()) for (;;) wait(&status);

    sigprocmask(SIG_UNBLOCK, &set, 0);

    setsid();
    setpgid(0, 0);
    return execve("/etc/rc", (char *[]){ "rc", 0 }, (char *[]){ 0 });
}

Yes, that's really all that belongs in PID 1. Then there's no way it can fail at runtime, and no need to upgrade it once it's successfully running.

Next, from the init script, run a process supervision system outside of PID 1 to manage daemons as immediate child processes (no backgrounding). As mentioned above are several existing choices here. It's not clear to me that any of them are sufficiently polished or robust to satisfy major distributions at this time. But neither is systemd ; its backers are just better at sweeping that under the rug.

What the existing choices do have, though, is better design , mainly in the way of having clean, well-defined scope rather than Katamari Damacy .

If none of them are ready for prime time, then the folks eager to replace legacy init in their favorite distributions need to step up and either polish one of the existing solutions or write a better implementation based on the same principles. Either of these options would be a lot less work than fixing what's wrong with systemd.

Whatever system is chosen, the most important criterion is that it be transparent to applications. For 30+ years, the choice of init system used has been completely irrelevant to everybody but system integrators and administrators. User applications have had no reason to know or care whether you use sysvinit with runlevels, upstart, my minimal init with a hard-coded rc script or a more elaborate process-supervision system, or even /bin/sh . Ironically, this sort of modularity and interchangibility is what made systemd possible; if we were starting from the kind of monolithic, API-lock-in-oriented product systemd aims to be, swapping out the init system for something new and innovative would not even be an option.

Update: license on code

Added December 21, 2014.

There has been some interest in having a proper free software license on the trivial init code included above. I originally considered it too trivial to even care about copyright or need a license on it, but I don't want this to keep anyone from using or reusing it, so I'm explicitly licensing it under the following terms (standard MIT license):

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

[Mar 21, 2017] systemd-redux - blog dot lusis

Mar 21, 2017 | blog.lusis.org

I encourage you STRONGLY to read the systemd-devel mailing list for the kinds of issues you'll possibly have to deal with.

Systemd-redux

Nov 20th, 2014 | Comments

I figured it was about time for a followup on my systemd post. I've been meaning to do it for a while but time hasn't allowed. The end of Linux

Some people wrongly characterized this as some sort of hyperbole. It was not. Systemd IS changing what we know as Linux today. It remains to be seen if this is a good or bad thing but Linux is becoming something different than it was.

Linux is in for a rough few years

I do honestly believe this will end up being the start of a rocky period for Linux.

Additionally, while not Systemd specific but legitimately all inter-related, kdbus is coming and its already got its fair share of issues in the first implementation including breaking userspace.

We also have distros like SLES adopting btrfs as the default filesystem.

All of these things combined mean that Linux is pushing the bleeding edge of a lot of unbaked technologies. Time will tell if this turns people off or not. I expect that enterprise shops will probably freeze systems at RHEL6 for a good while to come (and not just the standard "we're enterprise and we don't like to upgrade" time period).

Systemd isn't going away

Systemd is here to stay. The only way you will have a system without it is to roll your own. I don't expect many distros to chose to back out. My best hope is that they'll all freeze at the current version. Maybe a few things will get backported here and there for security fixes.

SystemD components are NOT optional

I know everyone likes to tout this but, no, the various systemd components while not pid 1 are realistically not optional. Kdbus, single parent hierarchy for namespaces (systemd is taking this one of course), udev changes - the kernel and distros are changing and coallescing around whatever systemd ships. Most distros will probably use systemd-networkd for instance. Look at what happened with Debian just today. The (albeit way late to the game) recommendation to support alternate init systems was rejected. I encourage you STRONGLY to read the systemd-devel mailing list for the kinds of issues you'll possibly have to deal with.

Options

To be clear if you're going to stick with Linux, you will have to deal with systemd. It's up to you to decide if that's something you're comfortable with. Systemd is bringing some good things but, like other discussions I've been involved with, you're going to be stuck with all the other stuff that comes along with it whether you like it or not.

It's worth noting that FreeBSD just got a nice donation from the WhatsApp folks. It also ships with ZFS as part of the kernel and has a jails which is a much more baked technology and implementation than LXC. While you can't use docker now with jails, my understanding is that there is work being done to support NON-LXC operating system level virtualization (such as jails and solaris zones).

Speaking of zones and Solaris, if that's an option for you it's probably the best of breed stack right now. Rich mature OS-level virtualization. SmartOS brings along KVM support for when you HAVE to run Linux but backed by Solaris tech under the hood. There's also OmniOS as a variant as well.

If you absolutely MUST run Linux, my recommendation is to minimize the interaction with the base distro as much as possible. CoreOS (when it's finally baked and production ready) can bring you an LXC based ecosystem. If they were to ever add actual virt support (i.e. KVM), then you could mix and match as needed. If you're working for a startup or a more flexible organization, you can go down this path. If you're working for a more traditional enterprise, your options are pretty limited. At least you'll have the RedHat support contract.

Posted by John E. Vincent Nov 20th, 2014

[Jan 26, 2017] Penguins force-fed root Cruel security flaw found in systemd v228

theregister.co.uk
Some Linux distros will need to be updated following the discovery of an easily exploitable flaw in a core system management component.

The CVE-2016-10156 security hole in systemd v228 opens the door to privilege escalation attacks, creating a means for hackers to root systems locally if not across the internet. The vulnerability is fixed in systemd v229.

Essentially, it is possible to create world-readable, world-writeable setuid executable files that are root owned by setting all the mode bits in a call to touch(). The systemd changelog for the fix reads:

basic: fix touch() creating files with 07777 mode

mode_t is unsigned, so MODE_INVALID < 0 can never be true.

This fixes a possible [denial of service] where any user could fill /run by writing to a world-writable /run/systemd/show-status.

However, as pointed out by security researcher Sebastian Krahmer, the flaw is worse than a denial-of-service vulnerability – it can be exploited by a malicious program or logged-in user to gain administrator access: "Mode 07777 also contains the suid bit, so files created by touch() are world writable suids, root owned."

The security bug was quietly fixed in January 2016 back when it was thought to pose only a system-crashing risk. Now the programming blunder has been upgraded this week following a reevaluation of its severity. The bug now weighs in at a CVSS score of 7.2, towards the top end of the 1-10 scale.

It's a local root exploit, so it requires access to the system in question to exploit, but it pretty much boils down to "create a powerful file in a certain way, and gain root on the server." It's trivial to pull off.

"Newer" versions of systemd deployed by Fedora or Ubuntu have been secured, but Debian systems are still running an older version and therefore need updating.

systemd is a suite for building blocks for Linux systems that provides system and service management technology. Security specialists view it with suspicion and complaints about function creep are not uncommon. ®

Continued

Recommended Links

Google matched content

Softpanorama Recommended

Top articles

Oldies But Goodies

[Oct 15, 2018] Systemd as doord interface for cars ;-) by Nico Schottelius

[Oct 14, 2018] In essence, Red Hat is attempting to out-MS MS by polluting and warping Linux needlessly but surely

[Oct 12, 2018] To change the systemd log level change the ' LogLevel ' parameter in /etc/systemd/system.conf

[Jan 29, 2019] RHEL7 is a fine OS, the only thing it s missing is a really good init system.

Sites

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

 You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March, 05, 2020