Systemd needs to be destroyed

systemd needs to be destroyed.
Assemble the neckbeards.
It is time to begin.

Other urls found in this thread:


They're trying to work its tentacles into BSD. Nothing is safe.

Werks on my masheen

Say it ain't so!

go and stay go

What Holla Forums meme? That's a transformative work, not a derivative work.

systemd is where it is due to politics, not merit. Still, neckbeards could make it easier to have a systemd-free system. I've tried a few times after I got tired of systemd breaking things and only managed to get rid of it in one computer (which was the one systemd was sabotaging the most, like breaking boot, the others only get the usual shit like it hijacking DNS to send it to CIAniggers), but still have to keep systemd installed since plenty of programs link to it.

said nothing related to Holla Forums, even if the original comic was. Limit your whining about Holla Forums to your board please.

systemd is chemo for the Linux cancer.



Yes, an event-based init was something badly needed as hardware advanced beyond the '90s.
Yes, it provided an opportunity to address a bunch of left-over poorly-implemented low-level stuff from the '80s.
Yes, doing all of the above provided an impetus to improve other inits such as OpenRC, runit, and Upstart.
It's still completely inexcusable that it is monolithic, buggy, backdoored, poorly documented (de facto not free, as looking over 687K lines of interdependent code isn't feasible), and swallowing up the rest of GNU/Linux.
not the user who you quoted

Are you retarded?
Are you not free to use, modify and distribute systemd? Software freedom is a de iure condition, and de fact systemd isn't impeding any of those freedoms of you. Just because it has a shitton of source code doesn't mean you can't modify it. Imagine if you said Linux wasn't free because it's well into the tens of millions LoC.

The Linux kernel has tons of authors while being monolithic, and as a result has developed very good documentation over the years. Its own developmental arc is tied to the free software ethic, now as ever.
As for systemd, 90% of the code has been written by the top 10 contributors, and poorly documented to boot.
Linux keeps to its own. If I need to deal with kernel stuff, I deal with kernel stuff. If I really wanted to, I could port over most of my OS to BSD because it's mostly POSIX-compliant.
systemd means that, if I want to install GNOME (not that I would in [current year]), I need to entirely replace the init system and install corresponding programs and daemons.
Linux doesn't shit the bed and get fucked over by backdoors from every angle. You've seen how insecure systemd is, and that's just the backdoors not made by the US government (remember: largest client of Redhat is the military). I have no means of controlling this opaque software's actions, even though I know C. Sometimes, you have to seriously wonder if that's intended - that or they're piss-poor programmers who should be fired immediately.
It's not at all the same as the Linux kernel in practice.

Moreover, who the fuck cares about whether software is "de jure" free if it doesn't meet, in your interaction with it, the standard accessibility engendered by the concept of free software? Tivoization is a similar example of why de jure freedom doesn't matter.
One of the two main goals of the US Constitution is to "secure the blessings of liberty". Does that matter one iota if it says so but allows the NSA to search all of my data and remove my privacy when I've done nothing wrong? No. It doesn't serve its purpose. Freedom is always based on de facto conditions, what one experiences in their daily life. A document is a document and nothing more. systemd may adhere to the GPL license's terms* nominally, but it entirely violates the spirit.
*assuming they don't go proprietary in the future once they've consolidated all major distros and made more core software dependent on it

Nice tripfag opinion

Or you know, you can start by writing software.

The merit of systemd is that it made it easier for the distro writers to configure their init system. Prove me wrong.

Just gonna leave this here.

But at what cost ?
Nothing is never worth freedom.

Systemd is gplv3. The source code is right there. You have all the freedom you need.


GPLv3 protects against copyright/legal aggression on freedom and not software design which is normal because it would be a breach on the developers freedom.
Because you have a lot of choice for browsing ? You can surely code a browser the size of an OS yourself.
The UNIX design was there for reasons if you don't follow it or something similar you get something that can't be managed by one person.
Yes I do I use runit.
But you already know this ? do ya smartass ?

The only freedom are the four freedoms of free software. Systemd gives all four freedoms of free software.

What does this have to do with anything?

I don't care. What I care about is the four freedoms, this is the most essential. Everything else is less essential after that.

How is it monolithic? Explain in your big boy words what you're required to have besides the init.
You're not required to use:
multi-user (logind)
You're not even required to use journald, you can simply have it write to memory and be non-persistent, while having syslog be the persistent log store.
You are required to use dbus though, which will be irrelevant once it's mainlined in the kernel and isn't usespace anymore.

ITT: angry autistic manchildren who never used linux in a productive environment complain about things


Does it really? I don't mess with systemd much but I do configure services with Runit a lot and it's super simple and straightforward.

t. Pottering

I had my fair share of systemd troubles, that didn't exist before systemd. Problems included: wifi not working after wake up from suspend, DNS reslover randomly stopped working (resolved, I didn't change any configuration files and did no updates), waiting 5 minutes for PC to shut down because systemd waiting for job to finish, waiting for DHCP on boot (sometimes instant sometimes took a long time). Not to mention pulseaudio (not systemd but still Pottering) crackling issues, which I don't know what exactly causes them, but my audio sounds like someone applied reverb with bitcrusher effect to main output stream (It wasn't hardware issue as it happened on two different AMD processors and an Intel one on completely different motherboards and audio interfaces).

I'm now less confident in my system stability. Honestly, why did we need a new init system in the first place? I'm completely convinced that new software gets released just so that developers have something to do. Look at systemd issue graph from official website. More issues are generated than closed. And why is there a new systemd release every three months? Right now systemd codebase is already substantially larger than that of Quake 3.

(not him) SystemD is monolithic because all of its parts were made to work with other SystemD parts only, they're tightly coupled. They even go as far, as you mentioned, as replacing standard networking tools with their own poorly implemented shit (e.g. see the DNS fiasco). Replacing SystemD is nowhere as simple as replacing any other init.

I don't think Patrick has any plans to switch Slackware to systemd, but if that tragedy occurs where do I go? Gentoo? I've mostly avoided the drama by staying with Slackware since v1.0 (for me it just feels more natural switching between Slackware and UNIX at work).

gentoo or openbsd

What about LFS? I honestly think that they will some day drive us to make our own distributions or switch to some other OS. My ideal system is:
small enough that I can understand what's going on and fix issues by myself, without waiting for updates from maintainers,
updates only critical security problems - I don't want updating just to have latest versions and break or change everything else in the process,
stable - I expect my computer to be very reliable. If I want to do my work, I don't want to be messing with my init system to get DNS working.

How viable would it be to use LFS as daily driver? Gentoo or Slackware would be a step in the right direction, but custom LFS also looks like a nice project.

Runit. /thread

I shitposted too fast and it didn't make sense, let's try again.

resolved is a stub, many system administrators want such a stub instead of a fully blown server on their systems, and it's totally optional.
timesyncd is a SNTP client, it's a stub, and many system administrators want it instead of a full blown NTP server on their shit. it's optional.
networkd, totally optional.
everything, optional. don't have to use it. don't have to use journald. you don't know what you're talking about it.


Wow you are retarded

Only once you find out it's there. I only noticed my system was infected with resolved when I was testing everything was still ok and, surprise, Poettering was making my DNS queries leak.
No, but RH sure makes it hard to switch to a free alternative.

There are so many good reasons to commit suicide. Why don't you look into it?

This tack has been tried in every anti-systemd thread I've seen.

Funtoo doesn't use systemd

LFS is a fun project but honestly you're just making more work for yourself rather than using or modifying an existing distro. If you have the free time though try it out, the manual is essentially copy and paste.

The service is literally disabled by default in upstream, you shitter. Either your distro enabled it and used it or you're just incompetent. Fuck off.

Who said that they have to do the work that you don't want to do, which is only necessary because you have a mental illness? There's certainly no technical reason to do so.

Also, what you said
Makes absolutely no sense in the context of the OPTIONAL, DISABLED BY DEFAULT DAEMONS.
Want full blown NTP server? Install NTP server. Want an actual resolver instead of stub? Install DNS resolver. Want syslog? Install syslog, configure journald to be non-persistent. Don't want to use networkd? Don't use it, use something else.
None of what you retards are saying makes sense.
And even if you were talking about switching away from systemd, no one is stopping you. There's consolekit fork for logind replacement. There's many more alternatives. Do the work yourself, no one has to do it for you.

Yes, arch is shit. I'm switching to gentoo on the next hardware upgrade.

Read what I wrote you dumb nigger.

I have a DNS resolver installed, one not written by retards, that's what it broke. It's true it's partly the distro's fault, nevertheless it's also systemberg's fault. And, yes, also my fault for not moving on yet.
And not resolved related but holy shit:

Are there any distros that use nosh, and if not, is there any particular reason? It does use a cuck license though. Has anyone tried it?

What a retarded post.

When will we get Microsoft iSystem32d. Please Brian, meme it happen.

Yes, systemd really did make it easier to configure. You didn't see what kind of init scripts they used in the past with sysvinit. I haven't used runit or systemd directly so I can't compare systemd to runit.

We needed a new init system in the first place because it made init configuration a lot easier than sysvinit.

This sysvinit "crisis" was manufactured in order to make people receptive to what was going to be presented as the solution to their perceived huge problem. The discussion was framed as a false dichotomy between the ostensibly obsolete sysvinit and the *modern* systemd. Nevermind that there are other init systems such as runit and openrc that address the shortcomings of sysvinit or that none of the argumenta made in favor of deprecation of sysvinit justify the cancerous growth of systemd beyond a mere init system let alone its current scope.

Embedded C unicorn here. sysvinit was a total disaster. systemd is less of a disaster and in different ways.

Of all people, you should be using MINIX. At least Intel got that part right. MINIX3 was designed from the very start for failsafe, hands-off operation, something Linux isn't (no matter what init system you use).
Either that or QNX.

Your confusion is in believing that systemd should only be an init system. Systemd is intended to be the system manager.

But now they have to debug systemd, so it probably wasn't on the whole easier.

>forgetting that it's Current Year + 2
Otherwise correct.

No, systemd is lgplv2.1+. See

Wish .png related was true.

Distro writers don't debug systemd. The systemd developers debug systemd.

Minix is a joke. It's a teaching OS. The only reason Intel is using it is it's 100% controlled by Jews so when they tighten the noose there won't be a risk of someone sabotaging it. It's the same reason SV companies kick out anyone who isn't anti-white even if they're really good.

No, distro maintainers and embedded guys get stuck debugging it and it's painful. You have to strace attach to pid 1 before triggering anything as it's all done via messaging. And starting a service is like 1k lines (literally) of esoteric syscalls before the actual service takes control. I have to remove all hardening before any debugging as well as it breaks everything I'd use to debug it. There's no global switch for that, sadly.

Fuck you, tripfag. I hope you don't actually use void on the principal that I don't want someone like you in my community.

What are embedded software developers doing that they require the use of systemd?

Tbh yeah. Systemd is one of the few things that makes Linux usable.

Old minix was a teaching OS before Minix 3. Sage for multiposting.

See? A bunch of things that don't matter in a production environment. Why would you suspend a server ever?

And I'm saying that you are a moron who doesn't know what you're talking about. The services in question are disabled by default by upstream. So either your distro maintainer was responsible for breaking your shit, or you were.

I'm not talking about that. I'm talking about the fact that there's no technical reason to use anything besides systemd on something like RHEL or CentOS, maybe Debian if you're working on embedded hardware.
And once again, you retards are screaming at the sky. These services are DISABLED BY DEFAULT by upstream. They are optional, and you have no idea what you are talking about.
Once again, I will repeat: you have no idea what you are talking about. You're kicking and screaming because you are unbelievably autistic, but none of what you're doing is making any difference to anything besides trying to craft an autistic echo chamber with other retards who are just as retarded as you.

How many times do I have to repeat that the services in question are disabled by default by upstream before you get it through your thick as fuck skull, and no one is forcing you to use them?

Why are you still here? You know what to expect yet you still come. Don't you know of anywhere else?

There's nowhere else but I enjoy making retards feel like the subhumans that they are in the mean time.

You're one of them.

As are you, in that case. Prove me wrong. Protip: you can't.
But, you do seem to be a bit upset, friend. Is it because you can't prove me wrong, in the posts I made, above?

Embedded is a lot less thin today. You'd actually be horrified by some of the things you don't know are on your devices. But for a basic system it's generally going to be a trimmed Debian.

It's still basic. It just now has marketing.

I don't make outlandish insinuations or treat a site without individual posting history as one that does. I proved you wrong, and found you a new place to hang out: reddit.

That's fine, but the question still remains. What is it about systemd that embedded system developers require it? I would have thought that something like Runit would be adequate for such a purpose.

I make embedded network devices and until recently we had some seriously hacked up sysvinit stuff mixed with python. I just (mostly) finished with a transition to systemd.
First off, let's get the obvious out of the way: embedded wants systemd because many other people they aren't paying help maintain it. Blazing your own trail is very expensive. Debian makes sure that shit works and that's then one less thing we have to do.
The technical problem with other inits is that embedded needs reliability. It might be fine if sometimes your laptop has some fuckup related to init but when you have 50k devices in the field and support is expensive they better work 100%. As an example, race conditions. I have a service that needs to start, be able to start queuing requests, confirm it is now in a started state, then start delivering event callbacks to whatever (shellscript glue, etc.) (dhcpcd also has this issue, if you want to look at something you have access to). If I naively start this via like start-stop-daemon or an init that only handles starting, I have no good way to prevent callbacks firing while it's starting. That could lead to all sorts of fuckups, like logic wanting to stop it while it's starting, or trying to queue an event back before it can accept one. I previously solved this with a wrapper between start-stop-daemon and the callbacks where it'd handle locking, but this was also complicated as I needed some shim to stay running to guarantee the process was still alive and to allow reliably managing it (pid files are completely unacceptable as they are fundamentally unreliable). It was a complicated and dangerous thing to get right, and it's messy. systemd replaces this.
systemd handles a lot of these reliability issues that everyone else gave no fucks about. It's why industry wanted it.

That makes sense. Systemd will take care of service dependency tracking. Systemd will also take care of parallel service booting.

My question now is this: do you embedded guys debug systemd itself as claimed by ?

Nothing in this thread provides any evidence that systemd is necessary for a stable linux setup.
All the rhetoric appeals to emotion and lacks argument.
Provide an exact example of sysvinit, openrc, runit, and other init systems where they fail. Don't just claim that they are "shit" or "confusing". Those are appeals-to-emotion, not facts. Where and why do they fail.
After you've done that. Provide an example of where systemd fixes that exact problem.
If that isn't done, then this thread is a shill fuck fest of disinformation.

Yeah, that post's me, too. I personally debug it. When you start trying to cut it down (size is an issue with it) you run into all sorts of tangled issues with it where it fails silently because something's missing and debugging is a pain in the ass as there's no good way to catch it in the handoff as the state's pretty weird due to all the magic. E.g., you can't just break out to gdb so it's usually gdbing daemons rigged to run standalone and straceing the system as a whole and hoping you never run into anything that requires stepping through the transition. For example, systemd-networkd will silently fail to bring up the network without dbus (but dbus is totally optional :^)), ACPI events like case buttons will silently not fire if you cut out systemd-logind, issues with socket activation require straceing the exec as it can silently pass dead fds to exec when you have non-trivial sockets, etc..

Go look how every distribution deals with DHCP option 42, setting NTP servers. This is where the shit hits the fan rubber hits the road for init system design. It involves callbacks, race conditions, and reloads between multiple services where the DHCP server and NTP server can be anything provided by the system.
It is a hopelessly fragile/broken pile of hacks in everything but systemd (you'll find swearing in one distro's sysvinit files for this). It's also broken in Debian with systemd.. This is something that embedded devs have been patching in their releases for decades, but has become significantly easier to get right with systemd.

Don't just say it. Prove it. What distro? Link?
That is somewhat helpful, but even doing a web search for "DHCP ntp sysvinit" doesn't provide any actual script. Can you show something instead of just saying words and fettering belief?

How about go fuck yourself you lazy nigger. I spoonfed you enough.

Your already using an init system that is practically the same as BSD's.

Nothing is outlandish about my "insinuations." They're what the poster was doing.
I don't have to reference "history", he's doing it in this very thread.
You are very upset.

No one said you need anything to get a "stable setup" moron. People are saying that systemd is the only thing that does it right, but with a few rough edges.
Then you morons bring up totally optional daemons that don't even have to be compiled for systemd to work, as if it means anything.
Even your "based Torvalds" agrees that it does it right. Meanwhile you retards just appeal to Sievers being a jackass as if anyone really cares or is surprised by that.

Eat shit and die you pogue. You fucking gave one dumb ass phrase thinking it was enough. I already informed your fucked ass that I did a web search and that no results linked to any scripts. You won't help with that, then gape your ass faggot. Further, you are the one that gave an anecdote without evidence. I requested evidence because why believe a single shitty word coming out of your ass-for-a-mouth.

What is someone as lazy as you going to do with that information anyway? You obviously aren't a programmer.

I've found contrary evidence.
This is all some Poettering circle jerk fuck fest and everyone is pushing their way to the front to suck him off.

Are you still spewing shit? Why don't you sit yourself down in the stool of shitty words that you keep dropping.
If you provide no evidence, you have no argument. If you have no argument, go fuck yourself on a rusty pole.

Yeah and I have a counterpoint with the existence of launchd. Those are some hot opinions from HAKKAR NEWS but they don't matter.

You are appealing to my emotions for your opinion to be correct, but I found another person appealing to my emotions for their opinion to be correct. Which do I choose? Why don't you put up or shut up? Find specific evidence where init systems fail and systemd fixes that specific failure.

No I'm appealing to the fact that launchd exists as evidence that BSD init/rc is not the final answer, even in that ecosystem. If it were, launchd would simply not exist.
Also, that's a dumbass opinion.
1) You don't have to, simply edit the unit file that you fucked up on which led to a total failure in boot for some reason and 2) the journal and systemd-analyze still fucking work in an emergency mode, so obviously that poster is retarded, but that depends on the mode of failure. If it fails before shit's even mounted, obviously you didn't fuck up an early unit file. I can't even comprehend how badly one has to fuck up to make systemd shit out to emergency shell with a unit file that's not relied on early early.

Or to better explain why the poster is retarded, if systemd-analyze or journal is not working, it's most definitely not a systemd problem. More like a "hurr I fucked up fstab" problem, or hardware problem (in the case of root or /var/ or whatever partitions/hardware failing, you have bigger problems than systemd). If it's past that point, then the journal and systemd-analyze will work, so there's no need to "traverse magic symlinks" or whatever bullshit. It will tell you what fucked up, and how.
Classic example of PEBCAK and blaming a tool. Sounds like a retard who would say that systemd "hangs" when fstab is incorrectly configured or hardware has failed, when in reality it just times out, and that timeout is configurable.

top kek
sounds liek systemd is a worthless addon to linux
fuck you

I'd say that with systemd-analyze and the journal, certain boot failures that drop to emergency shell are much, much easier to debug. But you're just a shitposter that fundamentally can't operate his tools correctly or just wants to bitch about "simplicity" and there's really no point to having this thread tbh. It's filled with the same retards, like you, as usual.

Heh, no. Most boot failures systemd will fuck up and it takes a while to work around all the different errors that will leave it in a failed state. For example, it often prevents ssh from starting if a drive failed during boot even on headless VPSes.
This is why everyone got really interested in paravirt watchdogs and serial over the last couple years.


WOW! We've got Linus Torvalds posting here! Because how else would another person know unless it was really him!?!1

It was 90 seconds at best and haven't seen that bug since they stopped using sighup (inducing tmux autism).
Pulseaudio was a mistake (not for the devs, but the users), but my best guess after Canonical retreat from many areas, RH will stop their NIH syndrome and start consolidate their codebase. I know all of this supposed to make easier to develop sw for linux with the monoculture and some autists got triggered by it, but if one wants larger marketshare, than he have to accept standardisation.

How retarded are you?

Not as retarded as you appear to be.

ebin, shouldn't you be in school?

I am a fucking grandpa, dumb ass.

I bet that new samsung botnet TV goes to sleep (suspend) instead of turning off when user presses "off" button. There are more embedded devices running linux than there are servers. So yes, suspend feature functioning correctly is important.

lmao just use devuan fags

Nothing is more fun than troubleshooting failed boot while reading binary logs. Oh wait, you can't read it ;--DDDDD

That's not a systemd bug, moron. SysVInit in "rescue" did not start SSH either.
Learn to validate fstab before rebooting your fucking server. Defer mounting network filesystems until before the unit that needs it, later in the boot process, where it will not fuck your system. None of that shit is actually a problem, it's only people blaming tools.

Yeah, you can. systemd-analyze and journal are available during failed boot.
Unless your root failed to mount. In which case you have a hardware problem or you're just retarded and can't validate your fstab before rebooting like the moron that you are.

b-but user, there are times that chemo worsens cancer...

what distro doesn't have the autism to compile literally everything but doesn't have systemd and is a rolling release?

Debian Unstable, if you replace it by OpenRC.
"systemd-sysvinit" is the package that provides /sbin/init. Get rid of that to use a different init system.
"systemd" is the core systemd package. Remove that to get rid of all traces of systemd. Take care to install a replacement for NetworkManager (if you need one), like wicd, before removing it.
Debian supports three kernels, two of which are not Linux, so I don't expect systemd to become mandatory any time soon.

last i checked gentoo isn't pozzed

Monoliths gonna monolith.


So honest question. I jumped onto linux because my windows 8 computer finally shit the bed and the laptop was already being held together by electrical tape and dreams so I repurposed an older laptop with Linux mint 18.2.

I've been using it now for a month and outside of having to fuss with some setting early on and reinstalling the OS 2 weeks in because I broke some stuff. I've been perfectly happy with my computer.

I'm not the most tech savvy despite my CS degree and I don't really get more than the surface level of the various arguements for and against systemd.

But I don't like feeling like I'm getting screwed or setting myself up for getting screwed in the future. I wasn't aware that my system had even had SystemD pre-installed until an emulation thread a week ago where someone pointed out that Mint 17 runs off a different init. Until then I had just held off applying the update that was in the update manager for weeks thinking that would have installed it.

This might be a question more about OS preference but I like Mint and is there any problem just downgrading to 17.3? All of the stuff I use should still work right? And is there a WINE repository that doesn't pull in SystemD? I would appreciate any help or advice because while I don't have any negative personal experiences with SystemD, I also don't see a lot of convincing praise for it with the limited understanding of software architecture I possess.



stop lying and samefagging your lies

Realistically your init doesn't matter, user. If you let the autists tell you what you should use, realistically you're going to be on OpenBSD with only a framebuffer in no time.
I dunno what you're even talking about with systemd as a dependency for WINE. Someone fucked up a dependency chain somewhere. Or you don't know what you're talking about. It's probably the latter, and this is why it's fucking hilarious when autists espouse their opinions, because people who don't know any better take them seriously.

Use whatever you want. systemd works, and on a desktop you're not going to touch it. The retards are appealing to "simplicity" but the simplicity is a hinderance to complex things like desktops or complex dependency chains.

To really understand why systemd is necessary, take a look at Macfags jerking off to launchd.
systemd is basically launchd without the XML, and done right.

There's also many rebuttals to the retarded "simplicity" cargo cultists.
In fact, the simplicity morons arguments have degenerated so much that I haven't even had a need to reference any of these blog posts. They're a great start as to why they're wrong:
Like the "splitting of PID1" argument, and many more. They're not meant to be taken seriously. They're just zealots.

So use whatever you want. But clearly you don't know what you should even use, so why bother having an opinion about it? Why concern yourself with it?

Oh, so that's why RedHat assigned it to the systemd guys who said it was an issue with systemd and took 2 years to do anything about it I guess.
Oh, I guess I was mistaken when I relied on this for my VPSes failing to mount an EBS volume.
Oh, I guess no one needs writable storage on instance store images during boot.
Thank you for correcting me, wise user.

Pick one.

I would like to LFS a functional thingy ma jig like NixOS or GuixSD, then maybe i'd know what the fuck is going on in my own OS


That's actually what I was referring too


I don't know where you thought I did. I was pretty clear that I have no real grasp of the topic outside of a surface level knowledge multiple times. But I also state that I'm the type that doesn't like feeling like I'm getting screwed and at the very least I am aware that some major Distros are foregoing their usual inits for Systemd and it's not a universally praised move so I am believably concerned.

I don't. I'm very clearly someone who isn't as deep into computing and Operating systems as others, I picked an easy beginners distro because I just needed something that works out the box. But I also got fucked by Microsoft for years with updates that removed control from me in certain areas or broke my drivers when they went through so I'm more than interested in undertanding what this thing is and how it can affect my computers. Sure I can just choose not to update stuff with Linux much easier than it was to deny microsoft updates but I also would like to keep my systems up to date since I feel more comfortable doing it that way.

I honestly came here to ask questions because I know I'm ignorant of this topic.

Was your CS degree very math/theory heavy?

Oh, start here: , if you just want to roll your own Linux distro.

oh the surprise

I thought you just said that systemd did nothing about your bug? You can't have it both ways.
Yeah, you were. Because you weren't in emergency shell mode.
That depends entirely on the dependency chain. If you explicitly tell it to not fail, it's going to shit itself. You should defer loading it until the service that requires it, and then only the service would fail, not the very early boot process.
Again, you're blaming a tool that apparently got a bug fixed but you're angry about it, and there's not one bug in that report, it encompasses a bunch of edge cases. Give me specifics, and I'll tell you where you are terrible at operations. Because it's clear that this is the case.

There was a heavy math emphasis yes.


If you're a frequent TOR user, I would suggest you to remove systemd from your computer. Who knows how many vulnerability are there just because you're using that stupid (((defected by design))) init.

BSD is solid. and you know, actually documented unlike most of the systemd infestation.

systemd is a mostly successful attempt to co-opt the linux ecosystem. nothing good lasts forever I suppose.

its not real?

You don't seem to understand. Most 'enterprise' VPS deployments boot read-only images. They learn their role and assemble the read-write components very early in the boot process as they fucking have to you moron.


Yeah, that's shitty architecture. You're orchestrating a deployment, with a fstab mount set explicitly not to fail, and then it fails for some reason, probably because of your shitty infrastructure, and then you blame the tool for not letting you pick up the pieces of your shitty failed deployment manually for some reason.
You're orchestration is fucking retarded, and whatever company you're at is obviously terrible at operations.

Further, how would you do it right?
You would read the role/configuration from a reliable source of truth (remote URL, network metadata service, hypervisor bridge) and your deployment simply doesn't fail at all, let alone so often that you're remoting into it to pick up the pieces.
How shitty are your operations that you regularly SSH into a fucking machine deployed from a read-only image (probably all with the same read-only SSH host keys lmao)?
Terrible. Git gud, my friend.

Although, honestly, you don't seem to understand much about configuration management or infrastructure automation so I can see why you're working at a shithole. Don't be so hard on yourself user. It's okay to blame a tool for your inadequacies or deficiencies of those who built your operation, but don't be angry if someone calls you on the fact that your deployments have to be rescued manually via SSH when they fail to mount a EBS volume, lel.

No, we needed a process supervisor. The sysvinit was fine and continued to be fine, we just needed something to manage our daemons. systemd was first introduced with "all-in-one init and process supervisor" (wow! that hasn't been done before!) and was promptly shilled everywhere by RedHat and was tangled into their other products so replacing sysvinit with systemd was mandatory if you wanted to use a lot of things. Then they consumed all system managing daemons like udev, dbus, syslog etc. The rest is history.
I propose sysvinit + a process supervisor as a better alternative. It works like magic, the configuration files don't get out of hand (syntax sugar/special config files just like systemd), and the services do not have to daemonize; they can run as foreground processes with stdin set up for signals or data input and stdout/err set up for logging. It's all the benefits of systemd without systemd.

Yeah, except process supervision isn't the only thing that systemd "solves." Also, are you retarded? Red Hat switched to upstart at first and didn't even want Poettering to develop systemd any further.
Then Upstart turned out to be a broken piece of dogshit, worse than sysvinit.

Maybe one day you'll get to play with the big kids, user.

Yeah, nah, prove me wrong. Also, I was spot on about the duplicate SSH host keys, wasn't I? Nice "enterprise" operation you got running there, retard.
How big boys do it is that they use sane configuration management or infrastructure automation tools, read-only images or not, but you're not going to experience anything like shitting out to because you'd use your brain cells to defer mounting of an EBS volume until the service that needs it for R/W it starts running. And definitely not set to nofail in fstab.
Presumably in your "enterprise quality" infrastructure you'd also have centralized logs. Oh wait, I guess not, since you're manually SSHing into your failed deployments to fix them.

Since you insist that you want to be berated like this, I'll continue to make you look like the retarded pajeet that you are. Duplicate host keys tbh. SSHing into it at all, tbh. Good stuff.

Learn to use proper IA and CM tools, dipshit.

Or rather, setting nofail. But realistically, you're not going to mount EBS in a way that will shit out to That's because you don't want remote-fs or to depend on the mount, only the service that needs it for R/W.
Quick example that I found in five seconds using google, maybe this will get your noggin joggin about how to properly unfuck your pajeet infrastructure and use systemd properly:

You are truly the master of the nine nines.

Best programming language to learn for cross-platform (Linux, windows, Linux, maybe android too) standalone executables in the coming decade? New to programming but that would be my ideal language.

Linux, Windows, Mac*

Fuck, wrong thread. Polite sage

This sounds really bizarre.
You made a list of a few systemd advantages you could think of, and then you propose alternative software that has those advantages by doing the exact same things as systemd does.
Don't you see the logical end result of that approach?

>thinks (((they're))) telling the truth so the anti-semetic userbase won't collapse

The "error" doesn't happen on anything but XFS. Arguably, the kernel driver is correct, but that's contrary to their use case. If they used any other filesystem, the failure would be properly monitored.
Futher, they could have a daemon that checks for this and properly unmounts, thus being totally self-healing, if I skimmed the article correctly.
Just because has docker in their headline doesn't mean it's a web dev topic.
You got shit on user, just stop. You know you were wrong at this point to argue that it was systemd's fault that you have a terrible operation.

That's a minority. Probably a small one.

so he doesnt have opinions on systemd, but he does on shit programmers

It doesn't matter who's at fault. You do not design your systems to continue after an error, ever, if you want reliability. You're mentally stuck in webdev territory, and worse, are listening to webdevs on reliability when webdevs do not really care about reliability.


if (! toilet_flush()) {
crash(this->plane, NO & SURVIVORS);
} else {
log("Systemd ejected");

Avionics are a good example actually as at least back in the '90s when last I knew anything about their design the critical systems were built in a similar way to what I described. Triple redundant systems where if one failed to agree it was immediately reset (as random output is far more unsafe than no output) and the output was the value from the other two.
If you want real reliability, that's how you engineer away all the random failures. And like I said, this is a similar mindset to what the big boys do with servers.

Most people hate the Jews, they just pretend otherwise out of fear of retribution.

It doesn't. It literally crashes the plane with no survivors in that context. The container should be killed if a volume is forcefully unmounted. Only the error is "ignored" by systemd because the XFS driver does not unmount it. It's not really ignored, it can only have the information the kernel gives it, and the kernel does not unmount it, thus the mount is still "active" even though any attempt to read or write will I/O error.
You're grasping at straws on a one-off example that was only illustrative of using mount units and depending on those mount units for the service that requires R/W. Not putting the mount in fstab in early boot like a retard where it will shit out to if it fails.
It's clear that you don't understand any of this because you don't actually orchestrate anything sane. You blamed a tool for getting a job done even though your fucked up infrastructure was at fault.

Also, it's totally configurable if systemd continues after an error. BindTo in this context ensures that the system explicitly requires the mount and will be killed when it unmounts.
How you continue to try and save face is amusing, but anyone that's not a retard will realize that you're just incompetent.