Slashdot Mirror
Does Systemd Make Linux Complex, Error-Prone, and Unstable? (ungleich.ch)
"Systemd developers split the community over a tiny detail that decreases stability significantly and increases complexity for not much real value." So argues Nico Schottelius, talking about his experiences as the CEO of a Swiss company providing VM hosting, datacenters, and high-speed fiber internet. Long-time Slashdot reader walterbyrd quotes Nico's essay:
While I am writing here in flowery words, the reason to use Devuan is hard calculated costs. We are a small team at ungleich and we simply don't have the time to fix problems caused by systemd on a daily basis. This is even without calculating the security risks that come with systemd. Our objective is to create a great, easy-to-use platform for VM hosting, not to walk a tightrope...
[W]hat the Devuan developers are doing is creating stability. Think about it not in a few repeating systemd bugs or about the insecurity caused by a huge, monolithic piece of software running with root privileges. Why do people favor Linux on servers over Windows? It is very easy: people don't use Windows, because it is too complex, too error prone and not suitable as a stable basis. Read it again. This is exactly what systemd introduces into Linux: error prone complexity and instability. With systemd the main advantage to using Linux is obsolete.
The essay argues that while Devuan foisted another choice into the community, "it is not their fault. Creating Devuan is simply a counteraction to ensure Linux stays stable. which is of high importance for a lot of people."
[W]hat the Devuan developers are doing is creating stability. Think about it not in a few repeating systemd bugs or about the insecurity caused by a huge, monolithic piece of software running with root privileges. Why do people favor Linux on servers over Windows? It is very easy: people don't use Windows, because it is too complex, too error prone and not suitable as a stable basis. Read it again. This is exactly what systemd introduces into Linux: error prone complexity and instability. With systemd the main advantage to using Linux is obsolete.
The essay argues that while Devuan foisted another choice into the community, "it is not their fault. Creating Devuan is simply a counteraction to ensure Linux stays stable. which is of high importance for a lot of people."
Oh my! I'm going to hang back, make some popcorn, step into some Tyvek coveralls, grab a hard-hat and safety goggles and enjoy the show!
If you want news from today, you have to come back tomorrow.
The BSDâ(TM)s and Illumos. There is no reason to use the tire fire that is Linux. You have options!
Here's a list of actual problems that should have been solved instead of introducing the nightmare of systemd upon the Linux (Debian specifically) world:
- Forceful, unconditional kernel operations. When I say "unmount this filesystem," I'm not asking a question. When I say "terminate this process," I expect the process to be removed from memory and the runqueue, regardless of consequences.
- When I say "reboot" I mean "reboot." Hangs are not okay, ever.
- Actual, real soft NFS failures. Do not hang during boot for any reason unless that share is marked hard,nointr. Do not hang during shutdown/reboot, either.
- Enforce GPL-standard syntax on new incoming utilities. If you want into the package tree, use a GNU parsing library and use it correctly. Perhaps a standardized syntax wrapper available for package maintainers.
- Bolt simple parallelization, triggers and flow control onto init/rc.
- Drop this selinux shit. It's too complicated and causes more problems than it solves. Vulnerabilities come from bad code, not a lack of complex call ACLs. Security is a process, not a feature.
- Standardize and fix bluetooth support ffs.
My $0.02, as a 25-year Linux admin.
A government is a body of people notably ungoverned - AC
A big ol ball? My init.d was about 13 scripts big which were readable and editable. Ever tried to edit systemd files? Depending on systemd version you have to create overrides, modify symlinks or edit systemd files straight up which can be in about 5 different locations and on top of that, systemd can have overrides on any changes either with an update or just inherited.
Systemd makes every system into a dependency mess.
Remove/fail a hard drive and your system will boot into single user mode, not even remote access will be available so you better be near the machine just because it was in fstab and apparently everything in fstab is a hard dependency on systemd.
Custom electronics and digital signage for your business: www.evcircuits.com
How are they going to get in and stay in if admins have real logs and can detect persistence?
Domestic spying is now "Benign Information Gathering"
So the short answer is: Yes, systemd makes things unnecessarily complex with little benefit.
That matches my experience - losing a lot of time trying to figure out why things don't work. The improved boot time is lost several times over.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
1. You've moved having a basic understanding of the boot process, and the ability to fix things, from having a decent knowledge of bash to being a C wizard.
2. You've broken decades of understanding the boot process.
3. It breaks KISS, as it doesn't simply do startup. Hell, it does ntpd.
It breaks a lot of the *concept* of unix. Maybe to something preferred by a lot of people - but it also turns it into an alien mess to a lot of other people.
yet another rant with zero details.... "all the problems caused by systemd" and yet not a single one listed.
Use "journalctl" to see the details log.
It must have been something you assimilated. . . .
and AWS / other lack 2 way console.
it turns out that, on arm embedded systems at the very least, where context-switching is a little slower and booting off of microsd cards results in amplification of any performance-related issues associated with drive reads/writes when compared to an SSD or HDD, sysvinit easily outperforms systemd for boot times.
Do one thing, and do it well. Systemd has eaten init, udev, inetd, syslog and soon dhcpd. Yes, that is getting ridiculous.
Systemd creates a dependency mess which means it cannot be replaced by simpler things, which wasn't the case before systemd.
I don't think there's a problem with the idea of systemd. Having a standard way to handle process start-up, dependencies, failures, recovery, "contracts", etc... isn't a bad, or unique, thing -- Solaris has Service Manager, for example. I think there's just too many things unnecessarily built into systemd rather than it utilizing external, usually, already existing utilities. Does systemd really need, for example, NFS, DNS, NTP services built-in? Why can't it run as PID 2 and leave PID1 for init to simply reap orphaned processes? Would make it easier to restart or handle a failed systemd w/o rebooting the entire system (or so I've read).
In short, systemd has too many things stuffed into its kitchen sink -- if you want that, use Emacs :-)
[ Note, I'm a fan and long-time user of Emacs, so the joke's in good fun. ]
It must have been something you assimilated. . . .
This is Slashdot, any ill you can imagine can be traced back to systemd.
“Common sense is not so common.” — Voltaire
Betteridge's Law says no.
- Drop this selinux shit. It's too complicated and causes more problems than it solves. Vulnerabilities come from bad code, not a lack of complex call ACLs. Security is a process, not a feature.
If you want to disable SELinux then disable SELinux, but not writing "bad code" isn't an option when even OpenSSL get major holes.
As long as people want new features there will either be new security vulnerabilities or software you can't afford and never gets completed. If SELinux adds enough security to be worth your bother then go for it, if not then disable it.
I stole this Sig
code contribution: /code/systemd
rm -rf
So the short answer is: Yes, systemd makes things unnecessarily complex with little benefit.
That matches my experience - losing a lot of time trying to figure out why things don't work. The improved boot time is lost several times over.
I completely agree. Troubleshooting is really a bitch with systemd, much more time-consuming. For instance, often systemctl reports a daemon as failed while it's not, or suddenly decides that it didn't start because of some mysterious arbitrary timeout while the daemon just needs some time to run a maintenance tasks at startup time. And getting anything of value out of the log is a pain in the ass.
Quite often I end up writing control shell scripts specifically to be called by systemd, because this junkware is too fragile and capricious to work with actual daemons. That says a lot about the overal usefulness of systemd.
Nothing has been gained with systemd, at least not on servers.
lucm, indeed.
Now that you converted all your start scripts etc... to systemd, to you really want to go back to init?
Slashdot, fix the reply notifications... You won't get away with it...
Troubleshooting is really a bitch with systemd, much more time-consuming. For instance, often systemctl reports a daemon as failed while it's not, or suddenly decides that it didn't start because of some mysterious arbitrary timeout while the daemon just needs some time to run a maintenance tasks at startup time.
Not to mention that the damn logs are not plain text, which in itself complicates things before you even have the chance to start troubleshooting.
#DeleteChrome
Drop this selinux shit. It's too complicated and causes more problems than it solves.
I think the utility called audit2allow summarizes well the immense "value" of selinux.
generate SELinux policy allow/dontaudit rules from logs of denied operations
https://manpages.debian.org/un...
The first time I heard about it I thought it was a prank.
lucm, indeed.
I'm still yet to have someone give me a legitimately non hysterical reason why "systemd bad" other than "its different"
This indicates a problem with understanding technology and technological explanations on your side, nothing else. "Safety in numbers" does not work for software.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I tried your patch and it's amazing. Please submit a pull request upstream as soon a possible.
Indeed. If you want, you can cut down SYSV init to a single script, no C coding needed. You can also easily control boot order, disable and enable components, etc.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
it's a fine OS, the only thing it's missing is a really good init system.
I disagree on SELinux, not because its interface is well-designed (it is not), but because it is needed for some things.
On the rest, I fully agree. And instead, systemd solves things that were already solved and does it badly. The amount of stupidity in that decision is staggering.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
The "improved" boot time is lost to me on every reboot, as it takes up to several minutes, once at a login: prompt, to, you know, login. Like it just sits there waiting a random amount of time before completing and giving me a shell prompt.
"The urge to save humanity is almost always a false front for the urge to rule." --H.L. Mencken
Oh right, crap code from the audiophile that couldn't code straight.
Never used any of his work. Linux has been seriously stable in my system ever since I started blocking that audio whatever it was called.
In my experience managing systemd unit files is GREAT!
What are you using them for? Are you a sysadmin? A debian init script writer? An embedded systems builder?
I wish half the effort that went into b!tching and moaning would go into a decent alternative but compatible alternative/fork to systemd (ie. works with same unit files etc).
The reason there isn't a compatible alternative is because the code is too complex.
"First they came for the slanderers and i said nothing."
Drop this selinux shit. It's too complicated and causes more problems than it solves. Vulnerabilities come from bad code, not a lack of complex call ACLs. Security is a process, not a feature.
It would be really nice to be able to run software without worrying about the amount of damage it could do. Android apps are fairly limited in what they can do, and in the absence of a root exploit, they can't go beyond their stated permissions, and can do nothing whatsoever after they've been uninstalled. I assume we're a long way off from having the right permission granularity and the good UIs for managing them, but this is a model we should at least explore further.
A cat can't teach a dog to bark.
I've been Unix admin in various environments for 20+ years. My first Linux install was in the early 90's with a pile of 3 1/2" floppy disks that I downloaded from Usenet. I think the first kernel I ever got compiled and working from scratch was 0.87. I've learned, and forgotten, more than I care to remember about Solaris, AIX, HPUX, IRUX & Linux.
I no longer care to admin anything but my own few systems as I've developed other interests and career paths.
I just got done, this very evening, installing Devuan on the laptop I'm using to make this post. The installation process was trivial. I've had Devuan running on other laptops and virtual machines for about a year now. I couldn't be happier, and I'll never go back to a systemd corrupted distro. I just want my stuff to work, and keep working, and not require hours to fix when something does go wrong.
systemd: may you rot in hell.
"Every time I see an adult on a bicycle, I no longer despair for the future of the human race." - H. G. Wells
Yeah, yeah I know the history of its development and how log files are binary and the whole debug kernel flag fiasco. And I don't care. By the time I used systemd, that had already long passed.
I switched from Squeeze to Jessie a couple years ago, had some growing pains as I learned how to use systemd... but that was it. No stability issues, no bugs. Can't say whether things run better, but they definitely don't run worse.
I had only really been using Linux for a few years before the onset of systemd, and honestly I think that's part of the problem. People who complain about systemd the most seem to have been using Linux for a very long time and just "don't want to change". Whether its nostalgia or sunk-cost fallacy, I can't say, but beyond that it seems much more like a philosophical difference than a practical one. It just reminds me of people's refusal to use the metric system, for no better reason than they are unfamiliar with it.
If systemd is so terrible, then why did a lot of the major distros switch over? If they didn't, it would just be a footnote in the history of open source: "Hey remember when they tried to replace sysV and init with that stupid thing with the binary log files? What was it called? SystemP?" The fact that Devaun has not overtaken Debian in any real way (at least from what I've seen, feel free to correct me if I'm wrong) indicates that my experience with systemd is the norm, not the exception. The market has spoken.
I read TFA, there is not one single specific bug or instability mentioned about systemd. What is the "tiny detail" that split the community? I have no idea, because TFA doesn't say what it is. I know that part of the philosophy behind Linux is "figuring it out yourself", but if you don't explain to me these low level kernel details (if that's even what they are; again, I have no idea), then don't expect people like me to be on your side. Linux is just a tool to me, I don't have any emotional attachment to it, so if things are working OK I am not going to start poking around under the hood just because someone posts an article claiming there are problems, but never specifying what those problems are and how they affect me as a user.
Honestly TFA reads like "We are having development problems, therefore systemd sucks." I get that when major changes to the platform happens there are going to be issues and annoyances, but that's the way software development has always been and will always be. Even if systemd was perfect there would still be all kinds of compatibility issues and new conventions that developers would have to adapt to. That's what I would expect to happen whenever any major change is made to a widely used and versatile platform like Linux.
Even Linus doesn't really care:
"I don't actually have any particularly strong opinions on systemd itself. I've had issues with some of the core developers that I think are much too cavalier about bugs and compatibility, and I think some of the design details are insane (I dislike the binary logs, for example), but those are details, not big issues."
I'm not saying systemd is "better" or "the right answer". If you want to stick to distros that don't use it, that's up to you. But what I am saying is, get over it.
Only crack the nuts that crack. You don't put the ones that don't crack in the sack.
Yep, Redhat must have gotten millions in support sales, thanks to systemd. What else would be better way to increase support sales than a constantly changing and spreading ameba, which nobody else than few developers know?
> Troubleshooting is really a bitch with systemd
And also because of dropped log messages. Not everything ends-up in the journal.
I agree. TFA reads like "We are having development issues, therefore systemd sucks."
Welcome to development. I have yet to find a platform, library, language, etc. that doesn't have annoyances and issues, including huge ones. And switching to an updated version of something can be a huge pain in the ass. But that's what we get paid for.
There are tons of examples where being too strongly married to backwards compatibility has been a major issue. Sometimes you just gotta cut the umbilical cord.
Only crack the nuts that crack. You don't put the ones that don't crack in the sack.
- Fix the logging.
Seriously. It's nearly impossible to troubleshoot issues if messages are just swallowed and not either output to the screen (which systemd has broken completely) or to the journal.
hates it!
Rather than keep having holy wars over it, foster both systemd and non-systemd distros, and let time decide which is better.
Table-ized A.I.
This indicates a problem with understanding technology and technological explanations on your side, nothing else. "Safety in numbers" does not work for software.
Technology has its share of doomsday prophets, it doesn't necessarily mean the end is nigh. I've casually used Ubuntu post-systemd though not as a server, haven't seen the problem. Maybe it's there, maybe I just haven't run into it yet but... WORKS4ME. If a lot of people say that, you have to wonder if it's really the problem it's made out to be or it's just people bitching that those fancy new automobiles can't run on grass, needs tires instead of horseshoes and doesn't run well in the terrain. Or the people who says EVs are stupid and don't work for anyone because they need to drive 500 miles non-stop, refuel in 5 minutes and drive 500 miles back. Maybe it's just you and the one thing you care so extremely about isn't actually a big deal to most people.
Live today, because you never know what tomorrow brings
Really, this sounded like those modest 9-star IMDB user reviews for a really shitty movies (worth of 3/10 max) starring the megastars of times gone by long time ago.
I started out using Slackware over twenty years ago. Biggest reason I left it was the libc5/glibc2 debacle. It became nonviable for me to remain on Slackware at that time. Bounced around through several package-managed distros and eventually ended up on Debian. I've now watched Debian become increasingly complex, sometimes needlessly, and sometimes because different major components have features that other major components lack. This means even if one is running something like xfce for the windowmanager one has to have a lot of Gnome or KDE stuff installed for basic stuff to work.
It's gotten worse since Systemd entered the picture. Honestly pulseaudio is still not mature, not sure how the person who didn't get that working right was entrusted to replace init.
Do not look into laser with remaining eye.
Thank you! Finally someone actually outlines specific issues instead of just complaining.
Well most of the issues he complained about weren't actually related to Systemd.
But I have to say, I'm using Jessie and I have not experienced any of the problems you have cited... When I kill a process, it gets killed. When I reboot or shutdown, it reboots or shuts down. When I mount/unmount something, it gets mounted/unmounted. The other stuff I can't speak to.
Usually no, but it happens
Can I ask, why don't you and other admins/devs like you start to contribute to systemd? Obviously there are huge philosophical differences between the systemd devs and parts of the Linux community, but if people like you never get involved in systemd development because of those issues, can you really expect them to change?
For one thing contributing to a project like that is a massive commitment, but more to the point the poster is fundamentally opposed to the underlying philosophy of Systemd. They can get what they want by simply using init.
I didn't even know systemd existed until I updated from Squeeze to Jessie and found that "service apache2 restart" didn't work. Once I got around the growing pains of learning a few new commands, that was it. It's not like I was like "ZOMG gotta get me some systemd!"
I'm not having any problems with systemd, so why would I switch to a smaller, less supported distro to avoid it? That just opens me up to a huge swath of potential issues that I don't even want to think about. And what's the reason, because people on forums are complaining? Because binary log files break the UNIX philosophy? I don't think you should be that surprised when I say that I really don't care.
For the average user, or person running their own server, it doesn't really change anything. The people affected by Systemd are the hardcore sysadmins running huge networks or mission critical servers.
If you're to believe the people running the major distros the hardcore sysadmins love Systemd since it's given them a bunch of new capabilities and fixed a lot of issues. But there's a lot of people, at least on message boards, who are extremely skeptical of the change.
I stole this Sig
"but servers that don't boot, that don't reboot or systemd-resolved that constantly interferes with our core network configuration made it too expensive to run Debian or Ubuntu."
PRO TIP: Run Slackware. Slackware is cleaner and does everything Debian does and has never been tainted with systemd.
Your thin skin doesn't make me a troll
This is exactly what systemd introduces into Linux: error prone complexity and instability. With systemd the main advantage to using Linux is obsolete.
I keep saying it: Poettering is being paid by Microsoft. The best way to destroy an enemy is from within.
On the other hand I suspect it works the other way round for headlines where the author implies the opposite of the question.
Linux (and before that: UNIX) has always had a "look how clever I am, writing all this obscure code" mentality. Since not too long after its inception, complexity - as a way of displaying the developers' prowess - has always been favoured over simplicity and elegance.
Whether you look at systemd, or the print subsystem or emacs or sendmail. They are all over-complex and if not intended to freeze-out users without the time, inclination or ability to grok them, then to achieve this through bad design which leads to complicated implementations.
Good design is difficult. Too hard for most coders. And it does seem that with kernel development and the systems that surround it, most of the design decisions are simply left up to the people writing the code to make, themselves. While this is standard procedure for a teenager sitting in a darkened bedroom, knocking out .... code, it is strictly amateur-hour stuff. You would have hoped that the linux community would have moved past that in these last 30 years.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
I have a PC with a Bios that tries to do everything, launching a bootloader that tries to do everything, to start a DesktopManager that treis to do everything, so I can run a browser that tries to do everything to see a website that tries to do everything.
And to think I started with Linux, because each thing had its own program and I could select what program did it.
Don't fight for your country, if your country does not fight for you.
For one thing contributing to a project like that is a massive commitment
Sure, that's totally understandable. But there are people who have enough time to fork entire distros, like Devaun... So while you could make that argument on an individual basis, you can't honestly say that "only the people who like systemd's philosophy have time to contribute to systemd".
but more to the point the poster is fundamentally opposed to the underlying philosophy of Systemd.
That's fair too, but that's life. Sometimes you have to deal with things you are fundamentally opposed to. As long as that's the position someone is going to take, they shouldn't really expect things to change. Again, self-fulfilling prophecy.
But there's a lot of people, at least on message boards, who are extremely skeptical of the change.
Great. But how is someone like me supposed to weigh these posts on message boards against the fact that the major distro I use switched? Skeptics demand to see the evidence. To me, the fact that the major distros have adopted systemd is strong evidence that it is probably better. Is it definitive? Of course not, but when compared to "posts on message boards"... I mean, seriously? There are message boards where people think the world is flat, I'm not throwing out my globe any time soon.
I know it's "argument from authority", but I don't have anything else to work with except my own experience which supports the same conclusion.
Only crack the nuts that crack. You don't put the ones that don't crack in the sack.
Absolute brilliant answer.
Yeah, here too. I never use journalctl because of its noisy output, when something failed i mostly tail the logfile of the application itself, with the added bonus of not having to deal with a binary log (gawd what a bad idea!)
apt purge systemd
Slashdot, fix the reply notifications... You won't get away with it...
... assume we're a long way off from having the right permission granularity and the good UIs
The problem is much deeper than that, unfortunately. Android apps are nothing at all like whatever passes for 'apps' in the general world of Linux. Running apt-get can play total havok with your system, due to Linux's obsession with complex dependencies and shared libraries. Android apps, iOS app and Mac OSX apps dispense with this nonsense completely, and imagine apps instead as completely self-contained repositories of code. Apt-get can modify your system's startup process in a way that you can't just "undo". Android app installs cannot.
Betteridge's law of headlines meets slashdot's anti-systemd bias. Could be interesting
It's always amusing reading comments like this. I remember hearing this kind of thing when it came to software distribution.
"Installing Microsoft Office is so easy. I install it all the time with no issues. People are just so whiny. Why don't they just grow up and get used to it?"
Now try installing it across a few thousand, or maybe 50,000, PCs on a staggered schedule across a business where the OS installation is supposedly standardized. There's a world out there that you don't understand, and it has issues that you can't even comprehend. Their concerns are not your concerns.
If anything, it shows that the linux base is so big that major distros are now unable or unwilling to cater to the needs of professional system administrators.
Most consumers couldn't care less how stuff works under the hood. It's bizarre that that may be a reality in the Linux world, but here we are.
Selinux sucks. It's either all in or turn it off... /etc/selinux/rules file, not some crappy command that adds them to a binary database...
A complex system will have some tools that are selinux ready and others that are not. How about having enforcing levels? Like this user is enforcing free and this one is not? In a simple
Turning off a bad program is not the solution in Linux has it often becomes so big that ppl will not develop alternatives.
If the kernel starts being buggy and crappy, is the alternative to uninstall it?
That stuff is all interface, not core to the execution of a Linux application. Dependencies aren't an issue because permissions are based on the process or user, not the file. (This is still an issue when a daemon is a dependency, or when a file has effective permissions of another user/group, but those are separate cases.) I don't have a complete solution, but modifying /etc (aside from /etc/$APP_NAME) could be considered a master-level permission, and the package manager would run with rights that don't allow that change unless the user approved the master-level permission for the application being installed. (Note that installation permissions wouldn't be the same as runtime permissions. Neither permission set should allow excessive read/write access.)
Compilers and interpreters aren't hard, either. They're just normal executables. If a rogue application launches "bash -c 'rm -rf /'", it should fail if the parent application doesn't have permission to touch files in /.
Do you have any other examples of why this isn't possible in principle?
A cat can't teach a dog to bark.
Windows is a very complex system. Not necessarily because it needs to be complex, but rather because of "wouldn't it be great if we could also..." thinking. Take the registry. Good idea in its core, a centralized repository for all configuration files. Great. But wouldn't it be nice if we could also store some states in there? And we could put the device database in there, too. And how about the security settings? And ...
And eventually you had the mess you have now, where we're again putting configuration files into the %appdata% directory. But when we have configuration in there already anyway, couldn't we... and we could sync this for roaming, ya know...
Which is the second MS disease. How many users actually need roaming? 2, maybe 3 out of 10? The rest is working on a stationary desktop, never moving, never roaming. But they have to have this feature, needed or not. And if you take a look through the services, you'll notice that a lot of services that you simply know you don't need MUST run because the OS needs them for some freakish reason. Because of "wouldn't it be great if this service did also...".
systemd now brought this to the Linux world. Yes, it can do a lot. But unfortunately it does so, whether you need it or not. And it requires you to take these "features" into account when configuring it, even if you have exactly zero use for them and wouldn't potentially not even know just wtf they're supposed to do.
systemd is as overengineered as many Windows components. And thus of course as error prone. And while it can make things more manageable for huge systems, everything becomes more convoluted and complicated for anyone that has no use for these "wouldn't it be great if it also..." features.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
fwiw Slackware has improved their package management quite a bit, might be worth checking it out again.
"First they came for the slanderers and i said nothing."
SELinux doesn't give you any real extra security, that's the problem. Once people have the ability to run code on your OS, they can also find a privilege escalation exploit (this is true on all OSes, even OpenBSD).
In modern use cases, it's better and simpler to partition with containers instead of SELinux, but even then, once you give them the ability to run code, they can escape from the jail.
"First they came for the slanderers and i said nothing."
Now that runit is being actively maintained, I would definitely choose that.
Can I ask, why don't you and other admins/devs like you start to contribute to systemd?
Lennart Poettering has specifically said that he will not accept many important kinds of patches, for example he refuses to merge any patch that improves cross-platform compatibility.
And what's the reason, because people on forums are complaining? Because binary log files break the UNIX philosophy?
Here is my analysis of systemd, spread across multiple posts (links towards the bottom). It's poorly written software (the interfaces are bad, you can read through my links for more explanation), and that will only get worse over time if an effort isn't made to isolate it over time. This is basic system architecture.
"First they came for the slanderers and i said nothing."
Journald makes logging simple and convenient, right?
journald has been known to run out of memory and stop responding.
Due to the design of "oh just connect stdout of the process to journald" if you restart journald it closes all of those file descriptors and you silently lose all further logging from already running processes.
Journald, by design, will only log so much per process, meaning that if it's logged too much since startup/an error you're interested in, you've now lost it.
Why 'they' had to go for demonstrably broken binary logging using a new interface I don't know. They could have just extended the syslog format to make it mandatory to pass along program name and process ID in the message. Then they could have made it "easier" to find the logs by having a per program/facility directory under /var/log and then stuck to simple, plain text logging that the existing *nix tools can search with ease. But, nope, they had to go with this shitfest instead.
And that's only one component of the whole systemd shitfest. On a very simple Debian install I've had it exhibit issues with shutdown, hanging on something that is simple or ignorable.
Sadly I had to abandon using Devuan after a while. The only really supported version is the jessie (Debian old-stable) version, and I'm not sure even that gets timely security updates. Their equivalent of Debian stable (Stretch) is 'ascii' and got next to no updates during the few months I used it. Boot up was both nice and fast (a major systemd selling point) and reliable (unlike systemd). I guess they just need more in the way of human resources so that they can nail down which Debian packages have problematic systemd tentacles involved, then they could pass through other Debian updates as soon as they're available.
>do not tinker under the hood, don't use Linux professionally, and don't run servers.
I do all of these things, I still don't whine hysterically about systemd.
Can I ask, why don't you and other admins/devs like you start to contribute to systemd?
Adding more code to something already hugely overweight isn't going to make things better.
I can only think of one kind of contribution that'd be worthwhile: rip out a lot of code. I'm not convinced this sort of contribution would be accepted.
And generally I've much better plans to do with my time instead of joining a project I hate. For instance, my ceiling has this funny dot pattern and I still haven't gotten around to counting all the dots.
CLI paste? paste.pr0.tips!
>To me, the fact that the major distros have adopted systemd is strong evidence that it is probably better
"Better" is a subjective term. Software (and any product really) does not have some absolute measurable utility. It's utility is specific to an audience. The fact that the major distros switch is probably strong evidence that systemd is "better" for distro developers. But the utility it brings them may not apply to all users, or even any particular user.
A big part of the reason people were upset was exactly that - the key reasons distros had for switching was benefits to people building distros which subsequent users would never experience. These should not have trumped the user experience.
All that would still have been fine - we could easily have ended up with a world that had systemd for those who wanted it, and didn't have it for those who didn't want it. Linux systems are supposed to be flexible enough that you can set them up to whatever purpose you desire.
So where the real anger came in was the systemd's obsessive feature-creep made it go into a lots and lots of areas that have nothing to do with it's supposed purpose (boot process management), in that area it's biggest advantages are only useful to people building distributions (who have to maintain thousands of packages and ensure they reliable handle their bootup requirements regardless of what combination of them is actually installed- systemd genuinely did make that easier on them - but no user or admin ever experiences that scenario). But that feature creep itself wasn't even the issue, the issue was that - as it entered into all these unrelated areas (login was the first of many) - it broke compatibility with the existing software to do those jobs. This meant that, if you built a system to support systemd, that same system could not use any alternatives. So now, you had to create hard dependencies on systemd to support it at all - for distros to gain those benefits, they had to remove the capacity for anybody to forgo them, or alternatively provide two versions of every package - even ones that never touch the boot process and get no benefit from systemd's changes there.
And the trouble is - in none of those other areas has it offered anything of significant value to anybody. Logind doesn't actually do anything that good old login didn't do anyway, but it's incompatible so a distro that compiles it's packages around logind can't work with anything else. Replacing the process handler... and not only did it not add any new functionality it broke some existing functionality (granted, in rarer edge cases -but there was no reason for any breakage at all because these were long-solved problems).
Many years ago, I worked as a unix admin for a company that developed for lots of different target unix systems. As such I had to maintain test environments running all the targets. I had several linux systems running about 5 different distros, I had solaris boxes with every version from 8 onwards (yep, actual Sparcs), I had IBM's running AIX, I even had two original (by then 30 year old) DEC Alphas running Tru64... and I had several HPUX boxes.
At the time, while adminning all these disparate unix environments on a day-to-day basis and learning all their various issues and problems - I came to announce routinely that Solaris pre-Version-10 had the worst init system in the word to admin, but the worst Unix in the world was definitely HPUX because HPUX was the only Unix where I could not, with absolute certainty, know that if I kill -9 a process - that process would definitely be gone. WIped out of memory and the process table with absolutely no regard for anything else - it's a nuclear option, and it's supposed to work that way - because sometimes that what you need to keep things running.
SystemD brought to Linux an init system that replicated everything I used to hate about the Solaris 8/9 init system - but what's worse than that, it brought the one breakage that got me to declare HPUX the absolute worst unix system
Unicode killed the ASCII-art *
To me, the fact that the major distros have adopted systemd is strong evidence that it is probably better.
Raises the question, better for whom? Systemd seems to make some things easier for distro maintainers, at the cost of fucking shit up for users and admins.
That said, Debian's vote on the matter was essentially 50:50, and they're going to keep supporting SysV init. Most distros are descendants of Debian, so there's that. Redhat switched for obvious reasons (having the main systemd developer on their payroll and massively profiting from increased support demands).
With Debian and Redhat removed, what remains on the list of major distros?
Yeah.. strong evidence...
CLI paste? paste.pr0.tips!
There is a reason we do not have have packaged it in #t2sde: https://t2sde.org/, our various init script and systems work since 1998 or so. No need to hijack the boot process with another emacs like complex operating system that is systemd. One days it replaces the whole Linux kernel ;-)
This overcomplicated hidden layer of bullshit is exactly what we did not want to maintain and analyse in Windows systems, and there is no good reason why one would such crap on Linux.
Oh come on, just hexdump(1) your logs. How hard can it be.
Kids these days.
CLI paste? paste.pr0.tips!
Your argument is 'this problem exists, therefore this must be the solution'. It is no different from arguing 'I am not paid enough, therefore I should work with my feet in a bucket of cold water'. Why a bucket of cold water? I don't know, as with systemd it has very little to do with a real solution to the problem.
I think most of us can agree that traditional SysV service management has a lot of problems, most notably in more dynamic situations (i.e. when you don't have a fixed static set of services that you only ever start and stop on boot). I think both Launchd on XNU and SMF on Solaris improved this situation hugely, though in quite different ways (and ignoring the truly horrible Java tool that Solaris provides for managing the SMF configuration). Unfortunately, as with most Poetteringware, systemd identifies a real problem and then completely fails to solve it, while arguing that the existence of the problem is proof that it must be a solution.
I am TheRaven on Soylent News
Because it's totally their own address and not one of someone they hate and want to see subscribed to penis enlargement mailing lists.
CLI paste? paste.pr0.tips!
Uh, Redhat? You know, the company whose business model is commercial support for their Linux distribution.
CLI paste? paste.pr0.tips!
A big ol ball? My init.d was about 13 scripts big which were readable and editable. Ever tried to edit systemd files? Depending on systemd version you have to create overrides, modify symlinks or edit systemd files straight up which can be in about 5 different locations and on top of that, systemd can have overrides on any changes either with an update or just inherited.
Systemd makes every system into a dependency mess.
Remove/fail a hard drive and your system will boot into single user mode, not even remote access will be available so you better be near the machine just because it was in fstab and apparently everything in fstab is a hard dependency on systemd.
This. I'm not sure whether systemd's complexity will pay off in the long run, but my God, it did complicate things.
This is more painful when, like me, we work in COTS/turn-key solutions that must work on several platforms. Some of our code base that worked flawlessly in most versions of Linux needed significant alterations to make it install and operate on Linux versions with systemd on it.
This effort was not trivial. It took an herculean effort to get everything to work without regressions (though absence of evidence is not evidence of absence, time will tell.)
Maybe his point is that it's better if you can choose any of 1000+ text editors and tools that suit you best instead of being forced to use on buggy tool? Makes perfect sense to me.
No it doesn't. As evidenced by the all distributions successfully using it and conspicuously not dropping like flies.
next
SystemD is like R6RS scheme...
not writing "bad code" isn't an option when even OpenSSL get major holes.
... and that's the reason why you shouldn't replace a bunch of editable and working scripts with some new, large and overly complex program written in C!
In the UNIX server world, hardware usually doesn't change during runtime (init 3 or init 5). Thus a boot process that starts new processes in a pre-determined, finely tuned sequence until all services are running, makes sense. All dependencies are already solved before the system boots up (and if not, you change your boot sequence until they are). And in this case, shell scripts as glue between the processes make thoroughly sense, as they provide a deterministic, linear approach. For the few cases when hardware changes during runtime (USB drives etc.pp.), you have a wrapper that handles it, but it's not something init is concerned with.
But if you have a system where the hardware changes all the time during runtime, because mice get plugged in and graphic tablets removed, monitors are sometimes on, sometimes not, you have to support projectors for some time, you have to support several different "power down" states (S1, S2, S3...), computers get put into docking stations and removed etc.pp., init is just clumsy. There are so many drivers to be loaded and unloaded, services to be started, to be stopped, to be removed from memory, you have so many dependencies to be solved on the fly, that your shell scripts take ages to tune, and the boot sequence is depending on the hardware currently plugged in. You would need dozens of init states to make sense of it all, each one with the correct set of started and stopped services, and the changes between states happen often.
This is not the usual server environment (yet), but it is the daily life of Linux running on other devices.
The reason there isn't a compatible alternative is because the code is too complex.
That makes no sense at all. How could the complexity of systemd's code have any effect on the difficulty of writing a compatible system?
Watch this Heartland Institute video
Most of the flames about systemd are just irrational and / or trolling.
if I have a problem with e.g. my dovecot instance on a server, with rsyslogd (as default installed on Debian) I get the fun of guessing which of mail.log, mail.info, or mail.err contains the messages I might like to see (with the mild suspicion that I ought to also glance at debug.log as well, just in case), then if I like to see things in chronological order I have the added amusment of running a command line like this:
zcat $(ls -tr /var/log/mail.log.*.gz) | cat /var/log/mail.log - | grep dovecot | grep $whatever_I_really_wanted_to_see
and I'll get most of what I'm looking for, along with anything else that contains the word dovecot.
[BTW hands up anyone that thinks a gzip file is a text file]
whereas with systemd it's just so bloody tedious:
journalctl -u dovecot | grep $whatever_I_really_wanted_to_see
Where's the fun in that?
Debian: GNU/Linux done the Linux way
Debian doesn't enable systemd-resolved by default, so they didn't even need to look at a manual to avoid that one.
Debian: GNU/Linux done the Linux way
Uh, if you do that it's not sysvinit, it's just init.
sysvinit = init(1) + all the crap under /etc/rc?.d
Watch this Heartland Institute video
I didn't even know systemd existed until I updated from Squeeze to Jessie and found that "service apache2 restart" didn't work.
Huh? "service apache2 restart" works just fine with systemd. Hell, on Debian you can even do "invoke-rc.d apache2 restart" and it'll notice you're using systemd and do a "systemctl restart apache2" for you.
Watch this Heartland Institute video
I'm not having any problems with systemd, so why would I switch to a smaller, less supported distro to avoid it?
The whole joke about Devuan is that you don't have to switch to Devuan to get rid of systemd -- Debian, unlike Devuan, lets you choose the init system you want. Don't like systemd? Just apt-get install sysvinit.
Watch this Heartland Institute video
So tell us, why didn't you simply install whatever log system you prefer? You are the classic example of the person with no clue what they are doing blaming systemd.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Just because you can submit a patch to something doesn't mean it will be accepted.
True.
What patches to systemd have been rejected? For what reasons?
Watch this Heartland Institute video
... is he's an arrogant fool with an overrated sense of his own abilities who will not listen to advice from people who know a lot more and have a lot more experience of using linux/unix in a critical enviroment than he does.
Why red hat and other distros are in thrall to his buffoon and his 2nd rate software is a mystery that I suspect even Mulder and Scully would find a challenge to solve.
As usual lack of knowledge is your real problem. ntp is an *optional* component of systemd. If you don't like theirs use your own. You don't have to know *any* C to use systemd. I don't even believe that you think you do. If you spent even a minimal time reading the documentation your problems would all magically disappear, but you don't want that. Complaining in ridiculous ways about non-issues is much more fun, and you can get lots of +1 mods from everyone else who learns everything they know about it from Slashdot and never invested any time learning about it.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Oh, there was one detail, and it exposes the author as a moron:
We tried to build Data Center Light on Debian and Ubuntu, but servers that don't boot, that don't reboot or systemd-resolved that constantly interferes with our core network configuration made it too expensive to run Debian or Ubuntu.
systemd-resolved is an optional package that only a clown would think of installing in a datacenter.
But this idiot actually installed it, then bitches that it is doing exactly what it says it will do.
Watch this Heartland Institute video
If you want you can write a ~130 line perl program to read systemd journals. I know because i did it when some systemd allergic whiner complained for the 1000th time that you couldn't read systemd logs because they were "binary".
It's a fucking computer. Everything on computers is binary!
Watch this Heartland Institute video
I really struggle to reconcile the Slashdot view that systemd is total crap and the fact that every major Linux distro has switched to it.
It seems like Lennart is an asshole with no clue about security, but despite that it does seem to offer enough for people who sell Linux, people who offer commercial support for it, seem to think it's better.
Red Hat said it hadn't affected sales when they did an interview here.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Granted, I have never needed any kind of tampering or corruption mitigation in my log files over the last 20 years of Linux administration. So the value for at least my usage of journalctl has been sum negative because I don't see the value in a command that by default truncates log output.
So the answer for systemd is to workaround it by using a "legacy" service to restore decades of functionality.
SMF was the death knell for Solaris (along with the Oracle purchase), and it feels like systemd is going to be the anchor which drags Linux into the abyss.
--WooooHoooo--
Yes extra complexity for no real benefit... Debugging becomes more difficult, other things become impractical (in emergencies i've mounted a complete system drive on another host, gone into it with chroot and started services to recover data or run as a temporary measure etc).
Boot time isn't important on a server, servers are typically stable and with reliable power sources so they don't reboot except at scheduled maintenance times, and there are even ways to live patch servers to avoid reboots while keeping them updated.
Also any benefit from a faster boot time is lost if the boot fails and you have to spend a long time trying to debug and fix it.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
If you want you can write a ~130 line perl program
I'm shocked it takes 130 lines of perl to decode the logs. Seriously how complex can the format be?
It's a fucking computer. Everything on computers is binary!
Sure, and there' sone particular set of binaries that are immediately accessible to humans; it's called text files.
IOW you're missing the point. I don't want to have to depend on whatever tiny ass rescue system I boot for disaster recovery to ship a perl interpreter (not to mention the native infrastructure to decode the logs)!
I wonder how the universality and thus the usefulness of text files is such a difficult concept to grasp.
CLI paste? paste.pr0.tips!
I agree. TFA reads like "We are having development issues, therefore systemd sucks."
Welcome to development.
Except they're trying to host VMs, not develop software.
Nice job pretending to read TFA.
CLI paste? paste.pr0.tips!
systemd-resolved is an optional package that only a clown would think of installing in a datacenter.
Yeah, much like the rest of systemd.
CLI paste? paste.pr0.tips!
So would you be okay with it if it still broke compatibility but that was necessary to add some really important/useful features?
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
And while in Linux land we are discussing if systemd is bloated or not, in unix land they throw a fit over 'cat' getting to bloated.
http://harmful.cat-v.org/cat-v...
On a long enough timeline, the survival rate for everyone drops to zero.
Remove/fail a hard drive and your system will boot into single user mode,
This just shows that people don't really understand fstab. Look up the 'nofail' option. If you want, you can specify this for every entry part from the ones that are absolutely necessary for the system to boot at all.
The 'problem' with systemd is that it's enforcing correct behaviour. If you *don't* specify 'nofail' you are in effect saying: 'this filesystem *must* be present and the boot should *fail* if it is not.
Pre-systemd the behaviour would probably have been variable/undefined.
In this respect, systemd is an improvement - but only if you know what you are doing.
Ok, you say, how am I supposed to know this? In my case I didn't know about nofail. But I assumed that such an option logically *must* exist, looked at the fstab options, and there it was.
Summary: predictable, controllable behaviour is better than undefined or variable behaviour.
The problem is that systemd is full of bugs. When the boot process hangs, automounts fail, or shutdown gets stuck waiting on nfs (saying it will time out but the time out target keeps moving), troubleshooting requires knowing C. Those problems can't be fixed by config files and documentation. They are bugs in the C code which is far more complex than a boot system should be.
My init.d was about 13 scripts big which were readable and editable.
So you weren't running any modern Linux distro then. Thanks for pointing out how irrelevant your opinion is so early on.
'm shocked it takes 130 lines of perl to decode the logs.
~25 lines of that is the BSD license. :-)
IOW you're missing the point. I don't want to have to depend on whatever tiny ass rescue system I boot for disaster recovery to ship a perl interpreter
You don't? My fucking telephone has a perl interpreter! (And systemd :-)).
Watch this Heartland Institute video
For instance, often systemctl reports a daemon as failed while it's not, or suddenly decides that it didn't start because of some mysterious arbitrary timeout while the daemon just needs some time to run a maintenance tasks at startup time.
So you didn't RTFM or your distro maintainer didn't set the option in the unit file correctly?
Other examples are equally pathetic: "systemd-resolved that constantly interferes with our core network" - I guess they stopped reading manual before getting to "systemctl disable" part?
You've got to wonder why the even installed systemd-resolved. It's not there by default. Do they install the whole Debian distro or something?
Watch this Heartland Institute video
...Do people have a problem with systemd or something?
[ducks]
Strat
Progressivism (aka US 'Liberalism'): Ideas so good they need a police/surveillance-state to enforce.
... their only arguments are hyperbolic personal attacks. (Look, I can do that too!)
Hint: Your side is just as stupid as your opposing site. There is no sane or reasonable, let alone sensible side. Because that is how Americans are. At least it is beyond their *tiny* mental box.
Regarding systemd, I state *both* A and B:
A) Monolithic "frameworks" have always been a stupid idea. Because they disable you from plugging them into *your* system, and force you to plug into *theirs*. Because they want to dominate you! And they are mutually exclusive as a result of that.
B) Traditional init systems are very limited and badly limiting nowadays. Like still using DOS as the underpinnings of your actual system. A more generic event/trigger system is much more sensible.
THE PROBLEM IS: That systemd throws away what's good about traditional init systems (like "everything is a file"; modularity; being able to do things with a simple file manager, text editor and maybe a script.).
It could have done the event/trigger thing *without* sacrificing modularity (tools that do *one* thing, and do it right!).
It could have acted less like a dominatrix on a power trip, swallowing everything.
The base ideas were good. The personality of the way it was implemented, was that of a complete egocentric psychopathic asshole with a god complex.
Give me a sane eventd, and I will ditch the old init system before you can blink.
PROTIP: Stating others misinform and lie, while using zero arguments to back that up, only makes you look like somebody who misinforms and lies (or is a religious fanatic), and therefore assumes, others do too.
YES!
Yes it does!
Chas - The one, the only.
THANK GOD!!!
I am an old fart. My first Unix machine was a VME 68xx running Unix Version 7 around 1986. I am mostly a developper, but I've been doing sysadmin work as an aside (unavoidable in small companies) more or less continuously for the last 30 years.
Recently, on upgrading my Debian home server (can't remember if it was Wheezy->Jessie or Jessie->Stretch), the server did not come back on the network after the upgrade. Go down to the garage where it lives: single user mode. No explanation nothing. After wasting 2 hours trying to guess what was happening, the explanation was that there was a stray entry in fstab. Nothing related to the real important stuff (/ or /usr), something like /proc/bus/usb or such. Systemd just decided that single user was the right thing to do. No ssh, no nothing. If the server had been remote, this would have been a major issue, instead of a couple of uncomfortable hours (restarting from backups would have been possible but would have changed a quasi-routine thing into one or more days of work).
I can't remember a machine being so nasty to me since the 90s (Unixware maybe :) )
Is this actually a problem? Outside of embedded systems, I can't think of a single set of circumstances in which I'd want to replace the system start up subsystem. And you're not really going to be loading GNOME or some other independent package that requires systemd on an embedded system.
You are not alone. This is not normal. None of this is normal.
Most of these I agree with, but I fail to see why you'd want to fix this, but not fix sysvinit, which has always been a horrible kludge and has been "obsolete" (unable to deal with a world where networking, hot pluggable hardware, CPUs requiring complex thermal management, etc, are ubiquitous.)
Despite the complaints that systemd is somehow the "wrong" way to do this because it's a large collection of integrated tools which is totally unlike Unix (LOLWUT?), the only other place you could put all this crap would be in the kernel itself.
sysvinit needed to be deprecated. And it was, most distributions were moving away from it because it no longer worked, but none of the replacements were particularly great either.
The worst I can say about systemd is that it's the best init replacement ever created. That's not a complement, it's just a very low bar. The lack of recognition that it's a low bar is why we have these stupid "systemd is why we have Trump" discussions here.
You are not alone. This is not normal. None of this is normal.
I'm curious if Redhat are regretting their decision on the early hard switch to systemd in RHEL7. I know for a fact their support system was flooded with issues from early adopters. I have friends in the industry still on RHEL6 as the upgrade to version 7 is a logistical nightmare and one who works at a reasonably large enterprise considering ditching Redhat entirely to go to a systemd-less alternative.
That faster boot time sure helps with servers that are only restarted once a year ...
I did, in fact, configure things to continue using rsyslog alongside journald (keeping the latter so I actually had experience of it). The system in question is my home desktop and is the only one I've allowed systemd to have full rein on, precisely in order to educate myself about it in practice.
My post above was to highlight just some of the issues with just one of the parts of the systemd ecosystem.
I had not had a SystemD for an Year now. Not a single one.
I wonder if there's something to do about not using nothing with it since in the last 12 months?
Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org
Oh, so now you are the guy who knew the problem doesn't exist but decided to try and make it look like it does. That is *much* better.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Tough question. Depends what that functionality is. Compatibility is valuable but sometimes it must be sacrificed to deal with technical debt or make genuine progress. Even Microsoft had a huge compatibility break with Vista which was needed at the time (even if Vista itself was atrocious). /etc is a major deal - it utterly breaks with a standard around which disk space allocation is done professionally. /use ought to not even need backups because everything there is supposed to be installed and never hand edited. It means modifying backup strategy which is a big, very risky, cange. Logs aren't where I expect them. Boot errors flash on screen and disappear before you can read them so you have to remember to go look in the binary log to figure out if it was something serious.
It would depend what those features were, what benefits it gave me. It would be a trade off and should be evaluated as such. A major sacrifice requires an even more major advantage to be worthwhile. I've yet to see any such advantage from anything systemd has added. I'm not saying advantages don't exist, I'm saying whatever they may be they do not benefit me, personally, in any measurable way. The disadvantages however do, and compatibility is the least of them.
Config outside
I was never a fan of system V. It was a complicated, slow, mess if code duplication. It needed a replacement. I was championing Richard Gooch's make-init circa 2001 (and his devfs, the forerunner to udev, was in my kernels - I built a powerful hardware autoconfig system on it in 2005 when I built the first installable live CD distribution, the way they all work now: I invented it [I later discovered that pclinuxos had invented the same thing independently at the same time but Ubuntu for example still came on two disks, a live CD and separate text based installation disk and more than once I had machines where the live cd ran great but the installed system broke due to disparate hardware setup systems]). Later I praised upstart - it was a fantastic unit system that solved the issues with system V, retained compatibility but was easy to admin, standards and philosophy compliant and fast. It was even parallel.
That is the system that should have won the unit wars. I'm not a huge fan of Ubuntu's eclectic side, unity has always been a fugly unusable mess of a desktop to me - but upstart was great, that and PPAs are Ubuntu two most amazing accomplishments. Sadly one got lost instead of being the world changing tech it deserved to be and it lost to a wholly inferior technology for no sane reason.
It's the Amiga of the Linux world.
Unicode killed the ASCII-art *
I should not comment from my phone. Man autocorrect rapes my text...
Unicode killed the ASCII-art *
I'm inclined to agree, BUT... I actually quite like system unit (files). It's a great way to daemonise a very simple program (perhaps one you got handed by your devs who know nothing about sysadmin, or perhaps some crap downloaded from the Internet because someone thought it would be useful). Getting simple stuff to work with systemd is actually super-easy. All those symlinks are really just enable/disable, although I'd love to see the actual files in some obvious directory - I'm not sure how much of that is systemd or distro vendor, but what the hell is multi-user-wants or whatever it's called? Either way, stopping every last daemon having to have its own watchdog process and letting "the system" take care of all that sort of thing seems like a really sensible move to me.
I have had horrendous trouble trying to get some esoteric daemons to work with systemd though. Trying to make an old init.d script work in systemd is a world of pain. Trying to have half a dozen 'linked' systemd units to fire up a half dozen daemons in the right order is really really horrible. It becomes easier to rewrite the launcher script to work on STDOUT and then run that with systemd. That's a problem because now you're not really using systemd, and so all of systemd is really just an overhead to what you're doing. Resolving this is partly the job of daemon writers, but partly the job of systemd itself (and could be solved there by allowing one system unit start multiple processes, conditionally run programs before startup, etc). Daemon writers aren't going to get onboard with systemd until it's easier for them to use it than to ignore it, so something's got to happen here (IMHO).
IMHO also, binary logs are crap - that's probably the single worst design item of it. We've all got along with plain text for years, we've got our log-shipping infrastructure and whatever else, and we've got a handful of aliases or scripts to do the sorts of cut-and-splice jobs we want. Having to use a different toolset for one or two log files is just a pain in the neck, and I have to go read the manpage or google every time I want to look at the bloomin' log because I've forgotten the command line options because I don't use them often enough.
If I had my way, I'd separate the binary logging stuff from systemd, and make it an optional system 'enhancement' for things that want to use it. In 5+ years of making cool tools for it (perhaps even implementing a log-shipping/aggregating solution), then start pushing that as the "next big thing" - until then, make it optional. Making binary logs a mandatory requirement for systemd just makes the "dislike surface" of systemd that much bigger and isn't a necessary dependency.
Whatever form of logging there is, systemd makes debugging really hard. It doesn't seem to suck up STDOUT/STDERR when you really need it to, it doesn't seem to tell you the command it ran that it thought had failed when you want it to, it doesn't give you the response code, it doesn't tell you why it considered it failed, etc etc. I can't even begin to think of incremental ways to change what it currently does because if I'm honest, I don't really understand it well enough. Bottom line: this is the worse experience of it, and probably the reason daemon writers will continue to resist systemd as much as they can. If systemd doesn't get this sort of thing fixed, then it's a huge barrier to entry, and means the likes of slashdot comments will continue to be negative.
In short: I think it came from a place of good sense, but then got too embroiled in things it shouldn't have. If it's really the "perfect awesome" that we all need, then we should have been given incremental steps to get there, rather than getting thrown in a the deep end with some software which has a few kinks in the pipes still.
Yes, but SYSV init provides a sane starting point and an experimentation environment to get there and I can just use the same init binary.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I'd say it is worse having to type something different for one log on the system, when the other 100+ are plain text and so accessible with the old tools we've all learned backwards. It means you don't have the necessary switches or key presses to hand because you don't do it often enough.
"journalctl" might be the best thing since sliced bread, but making it a hard requirement of systemd makes adoption of systemd that much harder. IMHO, systemd should "pick it's battles" and concentrate on managing system processes and worry about log formats another time.
Actually, Debian with SYSV init still works pretty well, you may just have to do without Gnome (no great loss..). Not quite "pure", some systemd cruft will still be around but mostly be inert.
It will be interesting to see what happens when/if Debian removes that possibility. My take is that quite a few people run this way at the moment.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Or in other words, a simple, reliable and clear solution was replaced with a gigantic KISS violation. No engineer worth the name will ever do that. And if it needs doing, any good engineer will make damned sure there is an easy and clean way back. The systemd people seem to be hell-bent on making it as hard as possible to not use their monster. That alone is a good reason to stay away from it.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I thought binary logging was a mandatory requirement of systemd. Am I wrong about that? Can I turn off binary logging and just go back to /var/log/messages on a systemd system? Got any Centos 7 instructions anywhere?
Indeed. And on top of that they try to make it as hard as possible to do without systemd. This really seems to be a case of "if you cannot compete on merit, force users into it", which is completely unacceptable.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Most of the flames about systemd are just irrational and / or trolling.
The typical complaint of a small mind about things it does not understand. Seriously, this is the only thing left to respond to the likes of you, and I apologize for the arrogance.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
That is not true, unfortunately. In some environments you need two effective lines of defense and sometimes SELinux is the only thing that can provide the second one.
Also, any proper engineer knows that mistakes do happen and that the proper way to deal with that is redundancy, in software usually called "dense in depth".
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
And then you could look at why people use Linux and not Windows. And you would not be surprised at the masses willing to run trash and the smaller group that finds it unacceptable.
Seriously, have you thought even one minute about what you just posted?
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
There is a long history of Poettering and Sivers marking even clear security problems as "will not fix". Look for them yourself, they are not hard to find.
However your stance implies that you are just trying to sabotage the discussion. Your blue-eyed innocence is an obvious lie. Despicable.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
The point being that text format is more universally readable, and also should it get corrupted, it has a better shot of still being readable.
On the other hand, pure binary logging was not necessary to achieve what they wanted. In fact, strictly speaking a split format of fixed-size, well aligned binary metadata alongside a text record of the variable length data would have been even *better* performance and still be readable.
XML is like violence. If it doesn't solve the problem, use more.
You can use any logging tool you want including syslogd. Just install it. It will not replace sysytemd logging, which logs early boot events they don't. You get the best of both worlds. Seriously, stop getting your "knowlegde" of systemd from Slashdot. Read the docs. You will quickly realize that incompetent people blame systemd for their incompetence.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
This is one of the things that frustrates me, they didn't need to make it a binary format to acheive those ends. It's not like text records cannot accommodate such feats. It's also not as if you must embed the binary and text data in the same file to acheive performance gains (I maintain that segregating the data would have made for even faster indexing).
XML is like violence. If it doesn't solve the problem, use more.
That does work. For now. And it comes with some problems, but nothing large at this time. The problem is that this is not fully supported anymore, otherwise I would not care about systemd at all and simply ignore it.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I don't agree. Systemd is the most visible part of a clear trend within Red Hat, consisting in an attempt to make their particular version of Linux THE canonical Linux, to the point that, if you are not using Red Hat, or some derived distribution, things will not work. In essence, Red Hat is attempting to out-MS MS by polluting and warping Linux needlessly but surely. The latest: they have come up with the 'timedatectl' command, which does exactly the same as 'date'. The latter is to be deprecated. Red Hat, the MS wannabee. They will not pull it off, but they are inflicting a lot of damage on Linux in the process.
Indeed. Qui bono. It could not be more obvious.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Using text processing skills to process a generic text file isn't any harder than using journalctl. The difference is that the former is generically applicable to just about any other software on the planet, and the latter is for journald. It's not that complex to confer the journalctl benefits without ditching *native* text log capability, but they refuse to do so.
Using ForwardToSyslog just means there's an unnecessary middle-man, meaning both services must be functional to complete logging. The problem is the time when you actually want logs is the time when there's something going wrong. A few weeks ago was trying to support someone who did something pretty catastrophic to his system. One of the side effects was that it broke the syslog forwarding (syslog would still work, but nothing from journald would get to it). The other thing that happened would be for the system to lock out all access. I thought 'ok, I'll reboot and use jornalctl', but wait, on CentOS 7, journald defaults to not persisting journald across boot, because you have syslog to do that.
Of course the other problem (not entirely systemd project fault) was the quest to 'simplify' console output so he just saw 'fail' instead of the much more useful error messages that would formerly spam the console on experiencing the sort of problem he hit (because it would be terrible to have an 'ugly' console...). This hints about another source of the systemd controversy, that it's also symbolic of a lot of other design choices that have come out of the distros.
XML is like violence. If it doesn't solve the problem, use more.
Yes, this is what I do on the various servers I run. As I said in another post, systemd is only given free rein on my home desktop, precisely so that I gain experience of it, know the gotchas, and the workarounds.
If the state of Debian changes so that this is no longer possible then either I'll switch to Devuan (assuming they're on the ball with security updates by then), or just jump ship to either Free or OpenBSD (assuming a few things work well enough on them).
I really struggle to reconcile the Slashdot view that systemd is total crap and the fact that every major Linux distro has switched to it.
The Linux ecosystem is not sane. Redhat wanted more control of Linux so they pushed systemd. GNOME developers are easily distracted by shiny things (as proof I submit GNOME 3) so they went ahead and made GNOME dependent on it. And then Debian (which most Linux distributions are based upon) adopted systemd because GNOME depended on it. There were some other excuses, but that's the biggest reason. You can blame Redhat and Debian for this clusterfuck, and really, only a small handful of people in the Debian community are actually responsible for Debian's involvement. Debian's leaders were split almost down the middle on whether they should go to systemd. This is why major changes should require a 2/3 vote (or more!)
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Its not the Slashdot point of view, its a vocal minority. Personally I trust the developers at Red Hat more than random posters.
Yes, yes and yes.
SELinux doesn't give you any real extra security, that's the problem. Once people have the ability to run code on your OS, they can also find a privilege escalation exploit (this is true on all OSes, even OpenBSD).
Wait, what? The specific thing that capabilities-based security does for you is mitigate privilege escalation exploits! If you use capabilities correctly, then even if someone can execute code, that code can't do bad things because it doesn't have the rights to do so.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Despite the complaints that systemd is somehow the "wrong" way to do this because it's a large collection of integrated tools which is totally unlike Unix (LOLWUT?), the only other place you could put all this crap would be in the kernel itself.
That is not the argument, and if that's all you've taken away from it, then you are a disingenuous douchebag who refuses to listen to other people's arguments at best. The argument is that it's a large collection of tools which are designed to replace existing tools without actually being compatible with them, and built in such a way that you have to take many of them on. Its modularity is mythical at best.
sysvinit needed to be deprecated. And it was, most distributions were moving away from it because it no longer worked, but none of the replacements were particularly great either.
That is a lie, and you are a liar. sysvinit still works fine, and there were several drop-in replacements which retained sysvinit compatibility while adding things that people claim you need systemd for, like parallel init.
The worst I can say about systemd is that it's the best init replacement ever created.
It's a security nightmare, it's very low-quality code put in a position of managing the entire system, and it was rammed up our asses without any notion of the existence of politics. Lots of other init systems don't have those problems.
That's not a complement, it's just a very low bar.
It is a "complement". It's a side of shit tacked on to a main course of shit. The init system is meant to be simple and reliable, two things which do not describe systemd. It should never have even been considered for inclusion in anything on that basis.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
For instance, often systemctl reports a daemon as failed while it's not, or suddenly decides that it didn't start because of some mysterious arbitrary timeout while the daemon just needs some time to run a maintenance tasks at startup time.
If you don't write your systemd unit files correctly, you can't blame systemd.
Um, you know, this sounds an awful lot like OpenBSD...
Coming from someone who uses several flavors of Linux, OpenBSD, and FreeBSD on a regular basis.
My init.d was about 13 scripts big which were readable and editable.
What distro was that? With what services.
My boring old Debian Squeeze has 79 scripts in init.d
Hell, my Debian Squeeze (with systemd) has 42!
Also, what's the big deal with "editable"? systemd unit files are editable. More "binary" fud?
Remove/fail a hard drive and your system will boot into single user mode, not even remote access will be available so you better be near the machine just because it was in fstab and apparently everything in fstab is a hard dependency on systemd.
"apparently everything in fstab is a hard dependency on systemd." -- no, only things marked as a hard dependency will force that.
It's pretty easy to arrange that "near" be "anywhere closer than LEO" on any recent system or anything in any decent hosting facility.
Watch this Heartland Institute video
Ever tried to edit systemd files?
Yes. But I did have to read some documentation.
Depending on systemd version you have to create overrides, modify symlinks or edit systemd files straight up which can be in about 5 different locations and on top of that, systemd can have overrides on any changes either with an update or just inherited.
Nope. First, you should never modify symlinks. Second, if you are looking for/creating a unit file, you only need to look in two locations: /lib/systemd/system -- for unit files that belong to packages. /etc/systemd/system -- for unit files that are customized for the local system, these can override unit files found in the above.
Pretty simple and straightforward, actually.
Remove/fail a hard drive and your system will boot into single user mode
If you have a non-essential hard disk in fstab, you should specify "nofail" in the options field. It's right there in the second paragraph under FSTAB of the FM,
https://manpages.debian.org/st...
Both of the original authors of SystemD are German, Germany is pushing for a law to backdoor all internet enabled hardware. Coincidence?
- Forceful, unconditional kernel operations. When I say "unmount this filesystem," I'm not asking a question. When I say "terminate this process," I expect the process to be removed from memory and the runqueue, regardless of consequences.
- When I say "reboot" I mean "reboot." Hangs are not okay, ever.
What about the Magic SysRq key?
- Actual, real soft NFS failures. Do not hang during boot for any reason unless that share is marked hard,nointr. Do not hang during shutdown/reboot, either.
Yep, that's annoying, but I don't know enough to say more.
- Enforce GPL-standard syntax on new incoming utilities. If you want into the package tree, use a GNU parsing library and use it correctly.
Perhaps a standardized syntax wrapper available for package maintainers.
That's a downside of decentralized development. The issue here is that different platforms have different standards, and a lot of linux tools are multiplatform. So you have the choice of making the syntax different for each platform or being consistent between platforms. Furthermore, for licensing reasons, using a GNU parsing library may not be an option. Keep in mind that developers may not want to go out of their ways just to be included in the package tree of a certain distro.
- Bolt simple parallelization, triggers and flow control onto init/rc.
You mean, without breaking anyone's workflow? Impossible. After many unsatisfactory attempts and discussions, it turned out that that systemd was deemed the least unsatisfactory.
- Drop this selinux shit. It's too complicated and causes more problems than it solves. Vulnerabilities come from bad code, not a lack of complex call ACLs. Security is a process, not a feature.
Feel free not to use it, we don't. Yes, it is compllcated, but when you want NSA-level security (at the time it was a thing), you can't rely on every developer and every administrator to be flawless. It's called defense in depth. Yes security is a process, and SELinux is one way of enforcing processes. And BTW, vulnerabilities tend to come from users (including admins) more than bad code.
- Standardize and fix bluetooth support ffs.
Not a linux-specific issue but please, yes. To be fair, Bluetooth is an extremely complex spec and it is at least partly justified. The issue is that no one seem to implement it correctly.
no, not "everything is a file" but systemd considers everything to be "configured in a file", the thing that does stuff is still systemd and you can't plug in a binary or a network stream or something and have it work. That's the big difference here.
Whatever form of logging there is, systemd makes debugging really hard. It doesn't seem to suck up STDOUT/STDERR when you really need it to, it doesn't seem to tell you the command it ran that it thought had failed when you want it to, it doesn't give you the response code, it doesn't tell you why it considered it failed,
Crap.
Every single one of these assertions is purest bollocks.
Watch this Heartland Institute video
"We tried to build Data Center Light on Debian and Ubuntu, but servers that don't boot, that don't reboot or systemd-resolved that constantly interferes with our core network configuration made it too expensive to run Debian or Ubuntu."
The author states that this is a Linux problem, but only reports using systemd on Debian and Ubuntu, and complains about optional features that are not enabled on "Enterprise" or stable distros.
I have used systemd on a number of distros on a variety of hardware (production bare-metal servers, production VMs, desktops, laptops) and have never experienced the problems the Debian and Ubuntu users complain about here.
All of the "examples" I have seen were obviously due to the user having spent mote time trying to manufacture a bug than reading the very good documentation.
.
I am now actively looking for a distribution that does not use systemd.
Sometimes I have to wonder if the wrong feature goal (faster start-up times) was over-emphasized in the whiplash switch to systemd by the distributions. For me, the faster start up is just not that big of a deal anymore, now that I've moved to SSD.
Plug a network stream into init(1)? What?
Watch this Heartland Institute video
people who offer commercial support for it, seem to think it's better.
There's your reason.
"Freedom in the USA is not the ability to do what you want. It is the ability to stop others from doing what THEY want"
although I'd love to see the actual files in some obvious directory
> man systemd.unit
In the section titled "Unit File Load Path": /etc/systemd/system Local configuration /run/systemd/system Runtime units /usr/lib/systemd/system Units of installed packages
Table 1. Load path when running in system mode (--system).
Path Description
Trying to have half a dozen 'linked' systemd units to fire up a half dozen daemons in the right order is really really horrible.
This is because you are applying SysVInit thinking to systemd and expecting them to work equivalently. With systemd, you don't specify an "order" to start services. You declare dependencies and let systemd handle the ordering.
Trying to make an old init.d script work in systemd is a world of pain.
That really depends on what it is. If you have a bunch of logic embedded in your init script, then you have to take the time to pull all of that out and hook into the appropriate systemd mechanisms. But if you are just creating a socket and a PID file, this is very easy.
I want to look at the bloomin' log because I've forgotten the command line options because I don't use them often enough.
Well, if you just use journalctl all the time, instead of some of the time, maybe you would be more familiar and comfortable with it. If you have scripts that parse the log, you are definitely better off using the journalctl interface rather than grep/sed/awk. You can actually get real-time reporting, rather than just polling the log for changes.
It doesn't seem to suck up STDOUT/STDERR when you really need it to, it doesn't seem to tell you the command it ran that it thought had failed when you want it to, it doesn't give you the response code, it doesn't tell you why it considered it failed, etc etc.
It does all of those things. You just need to learn how to use the tools. For starters try,
> journalctl -b -u -o verbose
Remind me again how useful journalctl and binary logs are when you can't remember the exact name of the unit? "tail -f /var/log/messages | grep dhcp" is a lot easier to remember than "journactl -f -u isc-dhcp-server" - and hopefully you ARE running isc-dhcp-server, because if it's a different server you're SOL.
Remind me again how useful journalctl and binary logs are when the only things that run on a system are "echo" and maybe "/bin/cat" if you're lucky?
And yes, I've had that happen. Problems with the init system usually result in systems that have minimal functionality available. SystemD has far too many dependencies to reliably reconstruct a system that has failed init.
A user can reasonably select a desktop environment and the package maintainers can have their output consumed or ignored in that case.
Things like the kernel, init, user session management, low level graphics frameworks, and so on are not so easily swapped around by the users.
So the only choice people have is to select an entirely different distribution, which can suck if the 'only' thing you dislike is the init system, but you *really* prefer that distros packaging or release and support strategy otherwise..
XML is like violence. If it doesn't solve the problem, use more.
Second, if you think running easily-understood scripts in a well-defined, obvious order
Bwhahahahahaha!
There are 9492 lines of scripts in /etc/init.d on one very simple system I sysadmin. Those scripts source an extra 920 lines of library scripts. The "obvious order" comes from the LSB headers at the top of the scripts (Hey, boogie on like it's 2005, fixed order boot is so dead).
Even that is ignoring the fact that the scripts are full of calls to such clear and simple things as "start-stop-daemon".
Watch this Heartland Institute video
for example he refuses to merge any patch that improves cross-platform compatibility.
As a BSD user, I'm incredibly happy about this decision.
CLI paste? paste.pr0.tips!
Config outside /etc is a major deal
It's also a major misunderstanding of systemd.
systemd has no site dependent configuration outside of /etc.
The files installed in /usr/lib/systemd by packages are not supposed to be modified by the sysadmin -- that's what /etc/systemd is for, putting things that override the distro defaults.
Watch this Heartland Institute video
I've had numerous instance of "service xyz restart" not restarting the service yet not producing an error message AND giving exit code 0. It might be due to debian's unit files being a mess, but that doesn't really change anything.
Disclaimer before someone calls me out on the BSD message above: I have to fiddle with Linux at work.
CLI paste? paste.pr0.tips!
If someone decided to build a house out of cardboard
...
https://www.sciencealert.com/t...
Watch this Heartland Institute video
LOL, extremely difficult to migrate. If that's your big concern then don't migrate. Stay put. Use RHEL 6 or whatnot and stay there for as long as you like. And if you do migrate then tweaking a script to be launched by systemd instead of upstart or sysvinit is most likely the least of your concerns. In the real world, it is far more likely you're worried about preserving your database, your users, your network mount points and so on.
Right... /etc/default is good enough for every other package but not for systemd.
And
You know, if you don't follow the standards and "misconceptions" arise - it's the fault of bad development.
Unicode killed the ASCII-art *
"A complex system"
Here is your problem, if you want a system to be secure then keep it simple...
And as for the kernel being big and buggy, the vast majority of kernel features are optional - you can compile a minimal kernel to suit your needs and get a more stable, more secure and better performing system.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Keep it simple: compile a custom kernel!
If "service xyzzy restart" doesn't work then "systemctl restart xyzzy" wouldn't work either -- they're literally the same thing.
(/usr/sbin/service is, on Debian, a big shell script that ends up calling systemctl if pid 1 is systemd).
Watch this Heartland Institute video
Great groaning sound as the goalposts are shifted.
You're changing "Config outside /etc is a major deal" to "Config outside /etc/default is a major deal" now?
Are you unable to admit that one of your complaints about systemd, which you described as "a major deal" was simply wrong?
Watch this Heartland Institute video
My init.d was about 13 scripts big which were readable and editable.
What distro was that? With what services.
My boring old Debian Squeeze has 79 scripts in init.d
Hell, my Debian Squeeze (with systemd) has 42!
On a bog-standard web server I manage, systemd lists over 300 services with many more config files than that associated with it. It's way too complex for its own good. My big problem with systemd is that it fails to do simple jobs that init did just fine, like mounting NFS shares on boot. Never had a problem with it in the past, but as soon as I started using distros with systemd my shares no longer get mounted and the log file is silent regarding the reason. Hours of searching led to a lot of suggestions for things to "try" ("Oh, you need x-systemd-automount in your fstab options" or "You didn't set x-systemd.device_timeout correctly!") but nothing fixes the problem. It's a really easy task (read fstab, mount anything you see in there) but for some reason systemd just can't handle it. The shares mount just fine after boot with a mount -a, but then systemd will randomly unmount them (again, with no logged reason why). I ran into similar problems with other simple tasks. If you are going to replace an existing system with something that has an "everything including the kitchen sink" philosophy, you should at least make the new tool accomplish the same simple tasks as the tool you are replacing.
Enigma
Clearly you have spent time thinking about systemd, and so some questions:
1) Any chance systemd will improve? I think about how gnome3 seems to be slowly gaining more acceptance, perhaps this will be similar?
2) One of the challenges, even for a general-purpose computer distro, is to run on a wide variety of hardware with different needs. Example: Portable computer needs to be able to sleep, use graphics switching (start quicker??) while on a server these might be less important. It seems that systemd is screwing up more on the server side, which is a bit surprising. Any ideas on why? Theoretically these systems would be admined by more seasoned humans, but they seem to be having the biggest issues.
Anyway, just some thoughts. In my personal experience running a single server running Debian Jesse all seems OK with systemd, but I am not doing anything too fancy there. I also run mint on some desktop systems, and systemd seems OK there too..
No. I didn't change anything. No configs, editable or otherwise, should exist outside /etc. Configs installed by packages which should be overridden rather than edited (what you described the ones under /usr as being) belong under /etc/default. They no more belong under /usr than the similar files installed by a thousand other packages do.
Unicode killed the ASCII-art *
I'm happily running rsyslog on my systemd-containing distribution.
For debugging, though, the journal actually contains far more verbose logging than syslog ever did. And redirecting both standard error and standard out is a good thing, as before systemd a messages that you talk about being swallowed just scrolled off the console, eventually to disappear forever if you didn't happen to catch them at the time.
I'm amused that people would actually prefer the thousands and thousands of lines of buggy bash script code of the init system, where many init scripts were ad-hoc, duplicated functionality (often poorly) of tracking instances, recording PIDs, etc. To say nothing of buggy daemonizing code in the deaemons themselves. Systemd is very modular, and auditable. If you can make the systemd daemonizing code correct, and fix bugs there, you've now fixed bugs for all daemons.
There are occasional bugs that crop up that get people worked up (and justifiably so perhaps). But "daily problems," as some suggest, with systemd doesn't seem to be true. In fact, systemd seems to be working rather well for a major commercial distribution like RHEL 7. I've run systemd on my desktop distribution for quite a few years now and I have had no problems and don't even know it's there, except that when I need to make a custom daemon, it's a heck of lot easier to make a short ini file than it ever was using init scripts, or even the XML-based services I used on OS X or Solaris.
sysvinit needed to be deprecated. And it was, most distributions were moving away from it because it no longer worked, but none of the replacements were particularly great either.
That is a lie, and you are a liar. sysvinit still works fine,
What is a lie? That RedHat and Ubuntu had already moved away from sysvinit? That Arch Linux moved to systemd in 2012? That Debian was weighing up the possible alternatives with their usual glacial pace?
As for "sysvinit still works fine" -- sysvinit has been a piece of shit since the first time I saw it, back in 1990.
Watch this Heartland Institute video
Noisy? "journalctl -u service" will show you the output for a specific service. Add -f and it will follow it. It's not noisy at all.
I mean a sizeable company that has it's own Linux distro, and makes money supporting that distro.
Red Hat seems to be the enterprise Linux company.
I suppose IBM, and Oracle, somewhat support Linux. But for those companies, Linux is just a sideline.
I bet if there were a company like Red Hat, that had a non-systemd alternative, the Red Hat competitor would win.
My big problem with systemd is that it fails to do simple jobs that init did just fine, like mounting NFS shares on boot. Never had a problem with it in the past
Lucky you, I've spend days trying to debug NFS mount on boot dependency problems with sysvinit.
Watch this Heartland Institute video
No. I didn't change anything.
Oh yes you did. You said:
/use ought to not even need backups because everything there is supposed to be installed and never hand edited
I pointed out that that was exactly the case with systemd and now you've changed the claim to:
No configs, editable or otherwise, should exist outside /etc.
with exactly zero justification.
Watch this Heartland Institute video
As for "sysvinit still works fine" -- sysvinit has been a piece of shit since the first time I saw it, back in 1990.
How many times have you actually had a problem due to sysvinit itself failing?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
BSD has it's own problems.
Also, I think FreeBSD could be killed by systemd.
FreeBSD - especially on the desktop - depends on Linux applications. When those Linux applications start depending on systemd, I am not sure what FreeBSD users can do.
Two things can be equally true. Systemd rocks and sucks major balls at the same time. Systemd is a great init system when it comes to laptops and desktops that need to dynamically change based upon external events. Like closing the the lid on a laptop or plugging a device into a USB port. In that regards, it's a lot like launchd on a MacOS. Where systemd sucks is in server applications where you want simplified, stable, secure, maintainable specialized use systems that should change and reboot infrequently. It is for this reason, I have stayed with older Linux Distros and returned to *BSD for many of my server installations. All the while, I hope the distros learn the philosophy of UNIX and come to their senses.
Agreed on all except, I'll take another's comment on seLinux as something to consider. It may have it's uses.
:-)
Additionally, I'd add this;
- Reduce the number of security holes, bugs, quirks and whatnot, (but not at loss of reliability), over new features.
We don't need stinking new features! (I am looking squarely at you, Gnome 3! It should have been Gnome-NG, or something else, not 3.x.)
Everytime a new feature is added, it's possible that it added new security holes, bugs, quirks and reduced reliability. Let's end the madness
and decline new features until the software is secure, stable and suitable for it's intended task. (Copyright pending for SSS=Secure, Stable
and Suitable
Lady Galadriel
The real problem is the combination of both hotplug hardware and dynamic responses. For example, when I plug in a USB network or sound interface, I probably want to configure it once and have the same event trigger the same action every time. In contrast, when I plug in a USB mass storage device or insert a DVD into an optical device then the action that I want to run depends on the user that's logged in and the software that's currently running. FreeBSD's devd is not a great fit for that, because it doesn't provide a convenient mechanism for registering events dynamically. Well, it kind-of does: it forwards all of the events to a socket so that another process can add the missing functionality, and this is typically something that then forwards the events to DBUS and let's the running DE handle them. That's generally a better solution, because the events with statically configured actions tend to be ones that want to run with high privilege and the rest do not, so it's fine to have something as untrustworthy as DBUS[1] in the path for delivery (though it would be nice for devd to have some integrated support for adding and removing events beyond adding a file in devd.d and sending SIGHUP to the process).
[1] DBUS uses XML and so inherits vulnerabilities from expat (the XML library that they use) as well as providing its own in addition.
I am TheRaven on Soylent News
Your example is off base.
1. I seldom search my gzipped backlogs, because if something went wrong, it was recent. That is why they are gzipped.
2. If I am searching for a specific error message, like "$whatever_I_really_wanted_to_see", then generally no other program will spew that and the extra "grep dovecot" is unnecessary.
Generally this is all you need:
grep $whatever_I_really_wanted_to_see mail*
Which is even simpler than the journalctl bullshit.
Second, the example that you give above is not that difficult for an admin because zcat, cat, grep ARE ALL STANDARD TOOLS that I use for the output of virtually every program and service that I use. I do not want to have to use a different command (journalctl) to look at the output of every different program (systemd) that I run.
I've casually used Ubuntu post-systemd though not as a server, haven't seen the problem. Maybe it's there, maybe I just haven't run into it yet but...
Well there you go. It's not that it doesn't work, it's that it's overly complex and difficult to troubleshoot when you do have a problem, which is especially critical on a production server.
You're only using it for a workstation. I have OpenSuSE Leap for my workstation, which is also Systemd, and it works for me as well, but I've kept all our servers at SLES11 and not SLES12 because 11 is still sysinit based and that's much more stable for our organization. I can almost guarantee my supervisors reasonably short troubleshooting outages; not just because I know it better, but also because it's structure is more simple to navigate.
I'm holding out as long as I can, until Novell drops support for it. (In the meantime, I suppose I'll have to stand up a nonproduction SLES12 server just to start tinkering with systemd, for when that day inevitably comes).
Look back up at my post, now look back down, you're on the Internet. Now look back up. I'm a signature.
So your solution is that rather than using libraries in a project, that each project should rewrite support for that feature from scratch? And you think this is going to increase security? Dozens of implementations of feature X that are only tested as much as the single project that uses that code. Reimplementation after reimplementation, no one in one project looking at the code in a different project because they don't share any - it's all uniquely written.
Great idea. Dist that out now!
Despite the complaints that systemd is somehow the "wrong" way to do this because it's a large collection of integrated tools which is totally unlike Unix (LOLWUT?), the only other place you could put all this crap would be in the kernel itself.
That is not the argument, and if that's all you've taken away from it, then you are a disingenuous douchebag who refuses to listen to other people's arguments at best. The argument is that it's a large collection of tools which are designed to replace existing tools without actually being compatible with them, and built in such a way that you have to take many of them on. Its modularity is mythical at best.
It's also worth noting that a large collection of integrated tools is totally unlike UNIX. The UNIX philosophy is about providing a large set of loosely-coupled tools. The UNIX tools are not designed to be tightly coupled (which shows at times, for example try doing ls -h and then use other tools to sort the result by size), they are designed to be composeable in ways that the authors didn't anticipate and to be replaceable by others. This is very different from systemd, which has a bunch of tightly coupled components that happen to be in different processes. This may be good for fault isolation (though most of them run as root, and I don't know to the degree that they each gracefully handle failure of the others), but it's not great software engineering.
Note: I have some issues with this aspect of the UNIX philosophy, which is largely a work around for the fact that UNIX didn't support dynamic shared libraries and so the only options for code reuse were statically linking all of the useful things (infeasible for space reasons) or have a bunch of utilities that you chained together. Lisp machines and the Alto running Smalltalk had much more elegant ways of composing useful bits of functionality.
I am TheRaven on Soylent News
I'm charmed to read such vitriol against systemd. I thought people were losing it. My pet hates in Linux atm are: Systemd; Grub2; PulseAudio; RHEL NetworkManager (More properly named GuessworkManager); Bloatware Window Managers KDE & Gnome.
Yeah, Sysvinit is slow, Yeah, Systemd is a POS. Init has stood the test of time, is no slower than windows, and surely can be paralleled more than it is. Systemd has FAILED the test of time. Slackware also offers init and systemd - you don't need Devuan. I have yet to be convinced Devuan is not going to go the way of so many other forks for lack of developers.
+1 Happened here with removable usb drives.
How many times have you actually had a problem due to sysvinit itself failing?
What do you mean by "sysvinit itself"? If you mean init(1) and the core scripts (/etc/rc1 and so on), never. init scripts from packages, quite a few times, sometimes leading to unbootable systems, sometimes to booted but useless systems (no network, missing services).
The most recent sysvinit problem was poor dependency handling, leading to failure to mount NFS volumes on boot. That was a pain to fix.
Watch this Heartland Institute video
The real question is this: Does systemd make fitting the tool to the purpose at hand imposing, error-prone, frustrating, and counterproductive?
I've always regarded systemd "making Linux complex, error-prone, and unstable" as a short-term complaint, which was mainly advanced to argue that systemd's misguided mission was fueled by arrogant, deaf, sociopathic egocentrism.
Of course, those ad hominem characteristics are not a fatal flaw. For OpenBSD, that personality cluster is a match made in heaven.
Do biker bars hire bouncers on charisma and charm?
On the other hand, this is perhaps not the ideal personality cluster to introduce (almost by fiat) a highly integrated, monolithic subsystem that helps the user erect and automate their custom xmas light display.
Let's not become distracted by the reality that even a design turd, sufficiently polished, eventually achieves design maturity.
Has it ever occurred to you that if so very many people are, in your words, "incompetent", that perhaps it might be that the problem is with the tool, and not the people?
-- sigs cause cancer.
No. It did not. "There are lots of idiots so they must not be idiots" is an idiots argument. Idiot.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Sure, just like the tiny group of Slackware users who always argued that it was better because of its "more pure UNIX approach", talking about how package managers are essentially garbage (Slackware's package manager essentially unpacks a tarball and says good luck; removal wasn't a feature last time I saw this argument surface).
Support my political activism on Patreon.
It isn't a reasonable complaint, and if you read further down in the thread you will see the author admit he already knew that.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Yes, when you focus on what you intend to happen, issues seem so clear, don't they? But all this lack of responsiveness to your demands arises from attempts to contain potential unintended consequences.
I have a pet peeve, which is people who rank "crash" or "hang" bugs at the apex of the failure scale, above data corruption and faulty outputs. Think of an automated trading system that enters an abnormal state and starts generating random buy and sell orders for example. Or a system which is supposed to authorize access sensitive data. This is why operating systems are designed to crash when unexpected states are encountered. It's also why they're designed to restrict or alter powerful operations like unmounting a drive.
Now I'm with you -- a system should be responsive to what the operator demands, even if it is a potentially bad idea. I think computers (smartphones especially) should have genuine power buttons that cut off the power supply from the system. But just because getting the computer to do what I *intend* is simpler doesn't mean that the operation itself is simple; the operator has to be prepared for the complex consequences of his action.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Not to mention how to use non-unicode apostrophes. "â(TM)" indeed,
Watch this Heartland Institute video
Look at the flags you just used with journalctl and tell me if you think the authors care.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Apple gave launchd to the world as Open Source, and has been using it in macOS pretty much flawlessly since OS X 10.4 (Tiger) (and more recently, probably iOS, WatchOS and TVOS, too).
If that STUPID FUCK, Pottering, and his ilk had simply taken the ALREADY-DEVELOPED-AND-TESTED GIFT that was offered by Apple, instead of going "Apple is teh Evilz!"; we'll show THEM we don't need no Steenking gift Daemons!" Most of this hand-wringing could have been avoided.
I have several machines which run Ubuntu 14.04LTS. They work 100% perfectly under Ubuntu 14.04LTS, and shuts down IMMEDIATELY when I tell it to. Since I'm curious and have time on my hands, being retired and all, I decided I'd give a try to Ubuntu 16.04LTS. I slapped a fresh drive into my laptop and proceeded to install 16.04.. The install went fine, as Ubuntu installs always have for me since I started using it, around 8.04LTS. After the install completed, the reboot after removal of the USB install media took forever. My use of the system with 16.04LTS for nearly a week showed me that EVERY time I told the system to SHUTDOWN, it took minutes to do so, and pressing ESC to watch the system shutting down showed me a bunch of VERY suspicious systemd-related items that were NOT shutting down in a timely manner. After a week of use of this, I removed the 16.04LTS drive and replaced it with the original 14.04 drive and magically, I was back to shutting down IMMEDIATELY when I told the system to... My only conclusion is this is caused by systemd, so I'm planning on staying with 14.04 till near its EOL, and then evaluating other distros that have NOT drank the "systemd-koolaide", such as Slackware/Devuan... FUCK SYSTEMD
THANK YOU, Edward Snowden!! Americans owe you a debt of gratitude (whether they know it or not..)
On your last point, that's REALLY BAD! When there is a catastrophic failure of some part of one of my systems, I want lights and sirens and a flashing sign pointing at the problem, not just "fail" printed out on a screen I might not even be looking at!
But, of course, we're handing the world over to a generation that believe that only the things they want to matter actually matter and, if they can minimize their interaction with things they don't like, those things cease to exist. By that logic, hiding the issue fixes the issue, so I can see why they did it.
But no, really, if something breaks on my system, spam the message over top of whatever ncurses-based application I might have open in a terminal, pop up a persistent notification in whatever notification manager I've got running in my GUI (if I'm running a GUI) or pull me to a console if no notification manager is present or running, fill my terminal with details about the issue, alert me in every way possible so I can fix the issue. The right thing to do is to NOT make it easy to ignore!
Oh, but that might interrupt your YouTube video or the game you're paying?
SO WILL THE ENTIRE FUCKING SYSTEM GOING DOWN IN FLAMES BECAUSE YOU'VE BEEN IGNORING PROBLEMS AND LETTING THEM PILE UP UNTIL THEY REACH A TIPPING POINT AND THE COMPUTER SAYS "FUCK IT, i CAN'T GO ON LIKE THIS ANYMORE!"
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
And let's not forget that M$ bought 20% of RedHat about the time that Putteringaround was implementing systemd.
Why hide the configuration files for services? Why nest them?
And who *cares* about how fast it boots, if you're not running a laptop, or a ton of VMs? I have servers that take *minutes* before they finish posting. Hell, I've got an older HP DL580 G5 that takes seventy seconds before it even lights the screen and shows a logo, to let you know it' started posting.
And it's linux. Most folks just leave them running... so, again, who cares how fast? And, with the emphasis on parallel booting, when there's a problem, it's just made debugging that a *lot* harder. And come *on*, give me one justification for a binary journal file. And that's not even that great, given that not long ago, I was unable to boot a system, except to an older kernel, until I found, by chance, an error in /etc/fstab. For all the attempted boots, there was NOTHING in journald.
I do not see benefits.
No, really, it happens. Especially when there are a lot of events being logged; some condition exists within journald's code that causes it to just drop messages if it can't keep up. It's like they've never heard of buffers or, at least, just learned of them and aren't quite sure how to properly implement them.
I'd fix it, but then I'd have my name on systemd and that would be worse than dealing with spotty logs.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
That makes no sense at all.
Then you must not have written much software. That's ok.
How could the complexity of systemd's code have any effect on the difficulty of writing a compatible system?
It's not the code itself specifically that matters, but the complexity of the interface. A complex interface needs to be reproduced with all its obscure corner cases, and complex code tends to cause corner cases to grow abundantly.
"First they came for the slanderers and i said nothing."
List of problems I have personally encountered with systemd.
Upgrade never completing due to infinite loop bugs in systemd log maintenance.
Inability to read out log files without using slow as shit systemd commands.
Every time I run top there is ALWAYS systemd shit at the top of the list doing god knows what consuming resources for god knows why. The logging overhead of background noise from Internet SSH probes uses more CPU time than any other process in the entire system. It's almost as if systemd was designed to be a DOS attack helper service.
Kernel message ring buffer full of nothing but systemd related log bullshit.. because that's really what I wanted to see.
Here are a list of benefits I have personally encountered with systemd:
Intentionally left blank. I have no idea.. honestly I just don't know what systemd does that is at all helpful to me.
Ubuntu or one of the other Debian-based systems, I'm guessing? Same boat, buddy...
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
the modules are "tightly coupled" vs. old school loosely coupled
Tightly coupled means module A depends on module B and module B depends on module A, so you must always use both together. That is, they're not really separate modules but, rather, separate parts of the same module. It means you cannot easily use just one component, or easily change out just one component in favor of another that better suits your needs or use case. Being tightly coupled is exactly the opposite of being modular.
Tight coupling makes a system less adaptable and more difficult to maintain. When you hear someone speak of "spaghetti code", they're talking about tight coupling.
Loosely coupled systems aren't old school, either; they're what replaced the tightly coupled messes that came before them.
Learn a little bit of computing history and comp sci before you spout off, please.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
+1 Happened here with removable usb drives.
Also... Screwing around on Ubuntu at single user often results at the system being kicked to multi user with admin i/o to the shell split between multiple processes. Looks fixed in 17.10... But the 16.04 still has the problem.
Makes fixing the fstab for usb disks and changed uuids into multiple reboots...
The problem is that systemd is full of bugs. When the boot process hangs, automounts fail, or shutdown gets stuck waiting on nfs (saying it will time out but the time out target keeps moving), troubleshooting requires knowing C. Those problems can't be fixed by config files and documentation. They are bugs in the C code which is far more complex than a boot system should be.
Exactly! This is the MASSIVE point that pro-systemd-ers completely fail to address.
If any portion of my sysvinit system fails to process... at the console I can ctrl-c, carry on, and figure the issue out normally.
Perfect example, case in point: I recently upgraded a box to Debian Jessie and forgot to remove systemd before rebooting. I lost remote access to the box because for whatever reason, systemd was waiting for dhcp on an interface that was supposed to be set up as static, and was frozen in the process.... Inconveniently despite having console access, I couldn't ctrl-c, ctrl-d, or anything. Completely unresponsive while waiting for dhcp. This is unforgivable of an init system. Yes, I am a C coder, so I can very well find the bit that is waiting for dhcp and add a SIGINT handler, but why would I? SystemD is a steaming pile that no one wanted, and that solves problems that no one had, and is the solution that no one wants. It's been pushed as the 'next-best-thing' and clueless people have went with it.
The arbitrary file locations, random symlink requirements, and overall complexity is NOT what is needed in an init system. This throws away DECADES of acquired knowledge and startup knowhow that WORKS (99% of the time).. and when it doesn't... it's SIMPLE to debug. in sysv (or just about any other init system under the sun) I don't have to read a tome of documentation or fire up a C development studio to figure out why my dependencies aren't coming up.
The goal of computer science is to build something that will last at least until we've finished building it.
You should have transitioned from Slackware to NetBSD (or FreeBSD) twenty years ago. The transition from Slackware to the BSD init system is very smooth.
Well, then. That confirms my assumption that you're just an arrogant jackass that I can safely ignore. Happy holidays!
-- sigs cause cancer.
audit2allow is an automated rule writer to make usage easier. You're still supposed to use your brain and look at the policy it generates and make sure it's actually sane.
And this attitude is why things don't get fixed with systemd. I've seen multiple good reproduction steps that demonstrate this problem over the past few years, and it's still broken. It sucks when you can start something at the command line and see a few lines of output that show the exact problem, but when using "systemctl start [service-name]" nothing is saved in the journal.
And as a Linux user, I'm very happy about that too.
systemd is completely unapologetically Linux targeted, and made to expose all the cool stuff Linux has but that was getting little use. If it was written in a cross-platform compatible way, there would be no way to guarantee all the functionality would be there always.
Yes, systemd is/was new, and different from the classical /etc/inittab and /etc/inetd.conf. These features justify the changes:
Systemd acceptance will increase when they push some of this into the POSIX standards. The first three above should not be difficult.
Generally, the improvement is in if it lowers labor required downstream. That's the absolute measure of "better".
Support my political activism on Patreon.
I think about how gnome3 seems to be slowly gaining more acceptance
Gnome 3 has always had a superior workflow, aside from its alt-tab behavior (which can take you to a different desktop, then back to a different window from the same application, then tab you between those two--no rapid swapping between the last 2 windows you touched). With the Activities view, it became possible to just press Meta and swap up/down through desktops, or press Meta and type an application name or keyword ("DVD burner" etc.), and press enter to take the first result. You can tap the corner and move windows to any desktop, or create new desktops between desktops, and so forth.
The desktop environment's job is to get out of your way and let you use applications. When you have to go searching around for windows, or use a lot of manipulation to reorganize your windows across desktops, or go hunting through menus, it's broken. I eventually did look at the menus in Gnome 3--kind of annoying to traverse--only by curiosity; I've never actually used them to find or launch an application. It hadn't occurred to me until someone complained about it.
People dislike change. Learning a new system takes some effort. I happen to identify new interfaces as new systems and not reach for old muscle memory, so switching to a different DE doesn't bother me unless that DE is objectively-worse. That gains me exemption from that particular growing pain.
Support my political activism on Patreon.
SELinux is focused on preventing privilege escalation between users. However, most modern systems are all run as single-user (to the point that most AWS instances have no root password). SELinux does nothing to prevent privilege escalation when the flaw is in the kernel (so, gaining kernel-level access). Unfortunately almost all privilege escalation exploits you see these days are kernel level exploits, so SELinux does not do anything to stop the (by far) most common use case. Access controls on a file level are almost useless these days, but the container aspects of SELinux (chroot jails, etc) can still be useful. But then you might as well use containers and get more useful capabilities. To say it again differently, I'll quote Wikipedia:
the security of a "modified" system (based on an SELinux kernel) depends primarily on the correctness of the kernel and its security-policy configuration.
The weakest link by far is not the security-policy configuration.
"First they came for the slanderers and i said nothing."
Now if this isn't a textbook win-win situation I'm not sure what is. :)
CLI paste? paste.pr0.tips!
It breaks a lot of the *concept* of unix.
And therein lies the problem. After all, Linux is based on Minix and Minix is "a POSIX-compliant (since version 2.0), Unix-like computer operating system".
POSIX, of course, is a standard derived from the various versions of Unix that existed when the standard was first thought of; and Unix systems are characterized by a modular design that is sometimes called the "Unix philosophy".
The original draft of the Unix philosophy stated:
Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.
Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.
It was later revised to:
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.
And, of course, systemd isn't compatible with either specification, which means it would (and should) be rejected by the Unix world and, thus, by Minix, which follows the Unix philosophy; as such, it should be rejected by Linux, which is based on Minix and also strives to follow the Unix philosophy.
Why is that so hard for systemd proponents to understand? Just make a fork of Linux that doesn't purport to be Unix-like and limit systemd's reach to that fork and everyone will be happy. We chose Linux because we wanted a Unix-like environment and your systemd violates that choice.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.
Most of us chose Linux because we wanted a Unix-like environment; systemd violates that choice.
If systemd were a collection of loosely coupled modules we could pick and choose from (e.g. a collection of programs that do one thing) and they could manage to each do the one thing they do well, we'd have less of a problem with it. If that collection of programs worked together (we'd presume that to be the case, of course), we'd have even less of a problem. If it handled text streams (rather than a forced binary logging interface) as well, we'd have no problem with it.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
> If you don't write your systemd unit files correctly, you can't blame systemd.
Sure you can.
systemd makes it much more likely that nearly everyone will do it wrong.
That's an artifact of piss poor system design.
A Pirate and a Puritan look the same on a balance sheet.
SystemD generates Windows style "faster booting". You get to a boot prompt faster but the system is still sorting itself out. So it's all an illusion. They system isn't really ready yet. It's not useful. It's basically a sham.
You are also very likely to get things out of order so things will be broken with fairly trivial setups.
Again, if your system is more likely to get broken either by the vendors or the end users then your design failed.
A Pirate and a Puritan look the same on a balance sheet.
I've seen multiple good reproduction steps that demonstrate this problem over the past few years, and it's still broken.
I've seen them too. And in every case they are fixed by fixing the broken scripts or configuration files that cause them. I've never seen one that was caused by a bug in systemd.
Watch this Heartland Institute video
I don't find faster boot time to be terribly useful for a media appliance. Although SystemD seems to make automatically starting a Linux machine as an appliance a much less reliable thing.
A Pirate and a Puritan look the same on a balance sheet.
Especially when there are a lot of events being logged;
So what do you have your journald throttling options set at?
Watch this Heartland Institute video
A workaround doesn't fix the problem; the problem still exists, he's just able to deal with it for the time being. Having two logging systems running in parallel isn't exactly ideal and is, in fact, yet another problem.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
> Lucky you, I've spend days trying to debug NFS mount on boot dependency problems with sysvinit.
I've never had problems like that in 20 some odd years of using NFS with the old boot systems.
A Pirate and a Puritan look the same on a balance sheet.
Does the pope shit in the woods?
They can take my LifeAlert pendant when they pry it from my cold dead fingers.
Why does it throttle in the first place? I can see an argument for collapsing (e.g. "Some-logged-message [100]" to denote that "Some-logged-message" was logged 100 times), but if I have 100 unique messages, they need to all be in the log. Period.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
It's not a workaround. systemd is specifically designed to coexist with other logging systems. Anyone who read the docs would know that, which is proof these idiots haven't put even a basic effort into understanding it and are talking out their paper assholes.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
FYI, Gentoo and (I think) Slackware are among the distros that have not adopted systemd. I use Gentoo.
Nonaggression works!
Have you logged a bug for that?
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
"that seems to be the founding principle behind systemd. " - that just shows you know nothing about systemd
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
its what the anti-systemd lot do "ran out of ideas a long time ago so make stuff up"
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
"Complaining in ridiculous ways about non-issues is much more fun" - its what the children do...
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
It throttles for the same reason rsyslogd (for example) throttles -- to avoid overloading the system.
The throttling is done per service, so what did you lose when some process decided to log more than 1000 messages in a 30 second period (the default).
Personally I can see a couple of ways to fix things a bit -- it should be possible to set per service throttling parameters and throttling should take message priority into account.
(By the way -- the rsyslogd throttling might not even work -- syslog is usually used over a datagram transport, so packets may be silently dropped by the kernel if it wants to).
Watch this Heartland Institute video
Just an extra point. I have used several distributions over the years with systemd including Red Hat and Debian and derivatives and have *NEVER* seem one where logs weren't being kept in /var/log/syslog in addition to the systemd journal. It's a fabricated problem by anti-systemd trolls who have never actually used it.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Having two logging systems running in parallel isn't exactly ideal and is, in fact, yet another problem.
Let me clarify, though: two logging systems for the same data. Yeah, real efficient; there's no problem with doubling the amount of storage required to store logs, nor with doubling the I/O load of your logs. Right.
The fact is that systemd's excuse for what binary logging was necessary are bullshit; the same benefits could have been achieved with a text log and, if you really want to see it perform, a separate binary index for searching.
And the whole argument ignores the fact that systemd isn't really solving any real problem; but it does violate the Unix philosophy, which is why many people who use Linux for its Unix-like environment and mostly-adherence to the Unix philosophy have a problem with it.
Personally, I don't care one way or the other as long as my servers boot and do what I need them to do. Currently, systemd isn't causing problems for me, but it is important to understand the real reason people complain about it. I'd rather still be suing sysvinit because it fits the Unix philosophy that brought me to Linux in the first place, but I'm not exactly up in arms over systemd. Unlike you, though, I do understand why a lot of people are; and I don't think they're wrong.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
systemd makes it much more likely that nearly everyone will do it wrong.
You won't do it wrong if you know how systemd works. You'll know how systemd works if you read the documentation. If you treat a systemd unit file as another kind of init script, it won't work correctly. If you recognize, from reading the documentation, that a unit file is NOT an init script and has a different way of managing the boot process, you won't have any problems with it. It's that simple.
The problem is there are a lot of old init scripts that have to be properly migrated and distro maintainers are relying on a transition helper utility (the systemd-sysv-generator) in the interim. It works, but it is an ugly hack and it sometimes creates problems that would be avoided if there were a proper systemd unit file in place.
Regardless of folks opinions, I like it a lot. Especially where it incorporates cgroups which can be handy when dealing with an unruly multiuser environment. It is more complex, but solves a lot of problems for folks who make a living on top of it.
More bullshit. "systemd doesn't follow the UNIX philosophy; it is monolithic!" Completely untrue, and you can use BASH all day if you want. systemd doesn't "pass on" log messages. You will get the same ones with or without it. Finally, if the tiny amount of I/O and disk space used is an issue you have serious problems.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
If you want to disable SELinux then disable SELinux, but not writing "bad code" isn't an option when even OpenSSL get major holes.
This reminds me of a New Yorker cartoon where the picture was of two winos laying in a garbage-strewn alley and one turns to the other and slurs "...and that's when I realized failure is an option."
In true New Yorker fashion, it's "funny" because it's true.
Android apps are fairly limited in what they can do, and in the absence of a root exploit, they can't go beyond their stated permissions
You're talking about an entirely different security model. Android apps are isolated from each other, and they generally cannot manage the operating system.
In a desktop environment, you typically cannot isolate applications in the same way. Maybe if everyone rewrote their applications to place nice that way---but that's a lot of work and a long time away.
In a server environment, you have applications which monitor/manage other applications, and often applications which monitor/manage the operating system itself. If it is difficult to bring the Android security model to the desktop, it is virtually impossible to do so for servers.
Overall, the idea would be great if it weren't completely unworkable.
---
According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
Yeah sure that's it. Just get back to me when people whining about systemd come up with a coherent compelling argument.
I never claimed it was monolithic, but it doesn't stick to a single task, nor does it necessarily do that task all that well, which is the first tenet of the Unix philosophy. Its logging system also doesn't work on a text stream, which is the third. Arguably, its components do work together, so it at least (maybe) follows the second.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
systemd is the Linux version of one of the main problems with windows. It could have been written to be a drop in replacement for _your_init_system_here__ and play nice with existing Unix ecosystems but it wasn't. It's designed to be a "F-U, we're making it solely to benefit us (RedHat) and the way we want to do stuff".
I'm tired of hearing how the old init system "needs improvement" or "just can't hack it in the modern world"... I use Slackware so BSD RC init is how we do things... BIG CLUE HERE: THEY'RE ALL BASH SCRIPTS, YOU CAN EDIT THEM TO ACT HOWEVER YOU LIKE!!!!!
Don't like that things don't start in parallel? Change your init script to bring up the absolute necessities first and then ADD A BUNCH OF "&" to the rest of your script tasks!!!!
Don't like how NFS 'locks up the machine when not available during boot? Change your init script to NOT MOUNT NFS at boot and add lines to your RC.LOCAL to add the mounts later.
The old system is plain old text human readable BASH SCRIPTS! Change what you don't like! Don't use this binary POS systemd!
Your thin skin doesn't make me a troll
That's fair too, but that's life. Sometimes you have to deal with things you are fundamentally opposed to.
True, but only an idiot would contribute to them. It's like handing the guy with a gun to your head the bullet he's going to use to shoot you. Much better to disarm him while the gun's not loaded.
That's not to say I believe that systemd contributors are idiots because I disagree with it's philosophy, just so they're no confusion; if they agree with it. But to contribute to something with which you don't agree is just plain idiotic.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Patches for those security issues would be prime examples, dunce.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Two separate points, you're conflating them when you should not be.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
"There is no sane or reasonable, let alone sensible side. Because that is how Americans are. At least it is beyond their *tiny* mental box."
Modding up overt hateful generalizations of ~300M individuals today? TFS doesn't even have anything to do with Americans.
So, like grep, more (or less), and sed, which can all be used on a disk pulled from a system with a failed init?
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
I suggest if you're struggling to remember a command (you are an administrator right?) that you simply make an alias. Or do the other things I suggested. Make systemd dump out a text file if you are absolutely incapable of learning a new command.
Write an alias or script. Is this even supposed to be a serious argument?
That is an artifact of of your misunderstanding. systemd is not a program it is a package. Claiming it doesn't do one thing is like saying the linux-tools or whatever package ls, df, man, grep, etc. are in (I don't recall at the moment) doesn't follow the philosophy because those *packages* don't do one thing. It is just another myth. Period. If you want to write BASH scripts do that, for example. You don't need to learn anything new but how unit files work, which is so easy it isn't funny. Literally every complaint I see is from people who never bothered to learn anything about systemd and are just spreading bullshit they read here from trolls and fools.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Yeah sure. I can also do away with a database by chaining together heaps of commands to filter a text file. Doesn't mean it is a sensible thing to do.
The core of systemd isn't just an init system. It's an init system and other mandatory crap, plus some optional crap. If it were simply an init system with other optional crap (sans the mandatory crap -- like journald), you would be correct. The minute your core functionality depends on an external package that serves no other purpose than to give the appearance of separation, the two effectively become one and the distinction becomes meaningless.
Can I use journald without systemd? I'm legitimately asking. If not, then it relies on systemd; and since systemd relies on it, that circular dependency makes them a unit. Following the Unix philosophy, you should have no circular dependencies in critical infrastructure; if you do, you've really got a single unit trying to do two or more jobs, in violation of the first tenet of the Unix philosophy. Period.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Is this even supposed to be a serious argument?
Considering that the flags were "-f -u", I'm thinking you're the only one who needs that question answered. No, it was not.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Then desktop distros should use it and server distros should not. Ubuntu vs Ubuntu Server, for example.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Really? Can ls, cp, and their ilk do their job without mkfs? OMG, it's a circular dependency! That's just one of 100 examples BTW. gcc can't build anything non-trivial without a make tool. OMG, it's not UNIX! The GIMP can't process png files without libpng. OMG, another one! It is a bullshit argument.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Really?
Yes.
Can ls, cp, and their ilk do their job without mkfs?
In fact, yes. I can run any of them on a system without mkfs installed, just as I can run mkfs on a system without ls or cp installed.
OMG, it's a circular dependency!
They're not dependent on each other in the slightest.
That's just one of 100 examples BTW.
Can I see the rest? Maybe one of them will be valid.
gcc can't build anything non-trivial without a make tool.
Make sets up the build configuration, gcc builds it. You can manually set up the build configuration without make and gcc will happily work with that, make just, well, makes it easier.
OMG, it's not UNIX!
Oh, but it is!
The GIMP can't process png files without libpng.
But libpng can work without The GIMP.
OMG, another one!
Ah, another what?
It is a bullshit argument.
Yes, I'm glad you see that now.
Oh, wait, you were talking about my post and not your own. Sorry, but no.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Try ls on a partition you haven't run mkfs on and let me know how that goes, and you can't run libpng at all BTW. Anyway, good luck learning about Linux!
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
KISS on Linux has been broken for a long time. As soon as the GUIs started coming into play, Linux lost KISS. Web, email, and database servers also are mostly past the KISS phase. Sure, there are the classic command-line utilities that still sit in that space, but vi and (especially) emacs don't fit in, nor have they in a very, very long time. Even the shells have grown well beyond the KISS realm.
It's a nice principle to hold onto when you can, but it's not the answer for every situation. Sometimes tying together a dozen things to get what one can do is possible, but that itself moves away from simple. Necessary complexity is where Linux has been for some time.
You can never go home again... but I guess you can shop there.
Try ls on a partition you haven't run mkfs on and let me know how that goes,
Huh, worked just find on the NTFS partition on the USB disk I just brought over from my Windows workstation.
and you can't run libpng at all BTW
I never said you could, I said it would work. And it does, in many, many applications that are not (and to not rely on) The GIMP.
Anyway, good luck learning about Linux!
I learned about it over two decades ago and have been using it ever since, thank you very much. You, on the other hand, don't seem to understand the concept of a dependency, let alone a circular one.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Only 2 decades ago? You are a newbie. News Flash, systemd is not going anywhere. Linux isn't UNIX, and that is a good thing. Have a great time misunderstanding systemd!
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Only 2 decades ago? You are a newbie.
over 2 decades ago. It's like you've forgotten how to read! That could be 20 years and 1 femtosecond, or it could be 50 years, or really anything over 20 years.
News Flash, systemd is not going anywhere.
Time will tell, I suppose. At any rate, as I said previously, I really don't care so long as it doesn't cause problems for me; and it doesn't.
Linux isn't UNIX, and that is a good thing.
Indeed, it is not, but one of its key strengths has always been its (mostly) adherence to the Unix philosophy. By Linus' own admission, Linux was built around Unix.
Then I wanted to download stuff, so I had to write a disk driver, I had to write a file system so I could read the Minix file system in order to be able to write files and read files to upload them. So essentially when you have task-switching, you have a file system, you have device drivers—that's Unix.
Have a great time misunderstanding systemd!
I understand systemd quite well, thanks; well enough that I've got a number of Ubuntu Xenial instances running with no issues, thus why I don't personally have a problem with it. If you recall from a few posts back, I was merely explaining why many others do.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Correction, actually; it really couldn't be much more than 26 years, since Linux didn't exist prior to that. I got caught up in the heat of the moment, but I wouldn't have been surprised if you'd tried to claim 3 decades or more experience. which, of course, would have been utter bullshit since... well... it hasn't existed for that long.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
I asked which patches have been rejected, not what those (so far not revealed) patches were supposed to be for. The claim was that the systemd team have rejected patches, but so far nobody has given any link or reference to any such patch.
Twat.
Watch this Heartland Institute video
I love how I'm modded down for pointing out the facts.
If you don't like journalctl, then do what I said. Configure it to dump a text file. Big deal. People moaning about this are supposed to be sysadmins.
Here's one example.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Wrong. The journal is easier to search since you can pass time ranges and other filters to journalctl and get back only those events
It's been possible to do that with insanely sophisticated tools such as "grep" for 30+ years.
And anyways, we pay a shitload of moneys to Splunk so we can a lot more than that on basic log files (pie charts, trends, etc); the systemd journal just makes it more difficult to have the same splunk rules.
One more instance of systemd trying to do everything and doing it wrong.
lucm, indeed.
For instance, often systemctl reports a daemon as failed while it's not, or suddenly decides that it didn't start because of some mysterious arbitrary timeout while the daemon just needs some time to run a maintenance tasks at startup time.
So you didn't RTFM or your distro maintainer didn't set the option in the unit file correctly?
The distro maintainer is the company that created systemd. Thanks for playing.
lucm, indeed.
It does all of those things. You just need to learn how to use the tools. For starters try,
> journalctl -b -u -o verbose
Please point out the improvement over "cat".
lucm, indeed.
The problem is there are a lot of old init scripts that have to be properly migrated
Why? They were not broken. They worked perfectly well since before the idiot who created systemd was born.
lucm, indeed.
A lot of events? I'm talking about one or two lines only! When you run the process by hand, it clearly outputs an error message either to stdout or stderr, but when starting it with systemctl, there is no output and nothing is logged in the journal. That's a major problem for troubleshooting. Yes, you can revert to starting things by hand, but sometimes that's hard to figure-out all of the commandline options and environment needed to do so.
Slashdot bitching is not really a good indication of the Linux community in general.
It's certainly not an indication of what people who know what they're doing (like distro maintainers) feel.
"Redhat wanted more control of Linux so they pushed systemd" is "insightful?"
And /etc/default is good enough for every other package but not for systemd.
Eh? There are plenty of packages that pull default configs out of some location in /usr, with /etc/ being an override. /etc has long (apart from systemd even) been considered the user-editable configuration, and /usr/share the non-user-editable configuration area (among other things).
That will not be happening for you, because you have just demonstrated you cannot recognize a "coherent compelling argument".
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
So you're new to /.? You should read back through the archived comments. You'll find some very good reasons there. Or just re-read the comments in this article.
systemd overtly funded by redhat in order to gain absolute control and veto power over the low-level linux ecosystem.
It's not completely unworkable, it's just in very early stages. And most desktop application don't need to be rewritten. Web browser: needs a rewrite so its permissions are integrated with file pickers (giving an implicitly granted permission) and prompted permissions. File explorer: needs a minor change to de-escalate permission of launched apps. Terminal: no change (running with permissive permissions, like before selinux). Chat applications: optional change (running with permission to write only to their config/data directories and read /etc and the camera/mic and their install path, but file attachments won't work until it adds implicit permission-granting via the file picker widget). Bittorrent app can run with legacy permissions until it's rewritten to use implicit permissions granted by file-picker. Git tools need to run in legacy mode. Game engines and 3D games could have restrictive permissions with no rewrite, or they could run in legacy mode for highest performance.
You're being pessimistic. Most applications could run in legacy mode until they support finer grained permissions, and many other apps could run with restricted permissions and not even know they're being restricted.
A cat can't teach a dog to bark.
Nobody uses Windows? Too complex? Unstable? What the fuck is he doing that fucks up Windows so bad? Fuck off, nobody cares for his opinion.
I don't know what the fuck you're talking about, but I like not having to google what OS uses for starting apps on boot and can use two simple systemctl commands to enable and start them regardless of OS.
It helps to to tell us we can ignore this idiot.
A big ol ball? My init.d was about 13 scripts big which were readable and editable.
On what distro was this?
Remember on many systems running sysvinit, you used to have something like rc.sysinit, which was a few thousand lines of shell script written to try and get every possible ordering possible dependencies to get all required filesystems in /etc/fstab mounted. For example, is /var on RAID on local disks? Or is it on LVM on top of local software RAID? Or is it LVM on FC? Or is it LVM on top of LUKS on top of RAID? Or LUKS on LVM on iSCSI? And is /usr on NFS accessed over a tagged VLAN interface? The dependency-based approach systemd takes for this simplifies a lot of things, but can be a bit more confusing when something isn't working.
Ever tried to edit systemd files?
Yes, and it is much easier having a pre-defined, well-documented set of features I can use (like trivially set LimitNOFILE when the distro's package maintainer didn't ever think about supporting this) and be sure that my changes won't be clobbered by a security update.
Depending on systemd version you have to create overrides, modify symlinks or edit systemd files straight up which can be in about 5 different locations and on top of that, systemd can have overrides on any changes either with an update or just inherited.
Since I started using systemd (which was before the release of RHEL7), the file locations documented in the current systemd.unit man page have worked.
You copy the existing file from /usr/lib/systemd/system to /etc/systemd/system, make any changes you want, and run systemctl daemon-reload. This provides an easy mechanism to ensure that your changes don't get overwritten by a future package upgrade, and it is very easy to see what has been customised, or mass-customise a lot of systems.
Systemd makes every system into a dependency mess.
Remove/fail a hard drive and your system will boot into single user mode, not even remote access will be available so you better be near the machine just because it was in fstab and apparently everything in fstab is a hard dependency on systemd.
Sure, one of my pet peeves is that I don't know why sshd isn't configured with fewer dependencies, but I don't think this is a specific limitation of systemd, but just with people optimising the sshd.service unit file for different use cases (like "don't start sshd until my users with NFS homes can log in", or "don't start sshd until my network-based user-management is accessible because then nscd negative caches my users and they can't log in for an hour).
However, if you want your system to boot when a device is not available, state that (as documented in fstab(5) as 'nofail'. The behaviour systemd has is correct, and avoids systems with non-local filesystems (e.g. boot from iSCSI or boot from SAN) failing to boot due to transient issues when retrying a few times would make it succeed.
According to it's documentation, FreeBSD behaves the same way (thought the option name is different):
If the option ``failok'' is specified, the system will ignore any error
which happens during the mount of that filesystem, which would otherwise
cause the system to drop into single user mode. This option is imple-
mented by the mount(8) command and will not be passed to the kernel.
And servers are another case. Server applications would definitely need to be rewritten, but until then they can continue running with legacy (user-based) permissions. User-based permissions work better on a server than on a desktop. (On desktop, the user-based permission model is destined to fail, since every application is launched by one user.)
A cat can't teach a dog to bark.
I completely agree. Troubleshooting is really a bitch with systemd, much more time-consuming. For instance, often systemctl reports a daemon as failed while it's not,
Then there is a problem with the service unit file. A common one is not setting the correct Type= value
or suddenly decides that it didn't start because of some mysterious arbitrary timeout while the daemon just needs some time to run a maintenance tasks at startup time.
Then the service unit file should have a suitable TimeoutStartSec= specified.
Of course, I have seen this in sysvinit scripts, and there if you had a service that would never start, you had to reboot and disable services to try and boot far enough to find out what was wrong with that service, and if you wanted to add timeouts, you had to make lots of changes to the init script, only to risk having it overwritten on a package upgrade.
And getting anything of value out of the log is a pain in the ass.
Really? 'systemctl' to find failed services, 'systemctl status foo' or 'journalctl -b' to see why services failed are quite easy to use and remember, and will find most boot issues.
Quite often I end up writing control shell scripts specifically to be called by systemd, because this junkware is too fragile and capricious to work with actual daemons.
It sounds more like the daemons are unreliable, or haven't got useful defaults in their service unit files, but that is very easy for you to fix (copy the original unit shown in 'systemctl status foo' to /etc/systemd/system/foo.service, edit as necessary, run 'systemctl daemon-reload'). See systemd.unit for more info.
Nothing has been gained with systemd, at least not on servers.
My experience so far has been that systemd has saved more time than it has cost, and the 'cost' is a once-off investment, and the savings continue.
Great, thanks.
A minor change (+5,-6) to Makefile.am, cool.
Watch this Heartland Institute video
Remind me again how useful journalctl and binary logs are when you can't remember the exact name of the unit? "tail -f /var/log/messages | grep dhcp" is a lot easier to remember than "journactl -f -u isc-dhcp-server" - and hopefully you ARE running isc-dhcp-server, because if it's a different server you're SOL.
'systemctl status dhcpd' shows me the logs I need to see 95% of the time.
If you don't know what the service name is, or just want to see recent logs or failures, try journalctl -b|tail or journalctl -x.
It really isn't that hard to run journaltcl --help, but these days it seems no-one on slashdot is able to do that, they are only able to use commands that existed in the previous century ...
Granted, I have never needed any kind of tampering or corruption mitigation in my log files over the last 20 years of Linux administration.
You *think* so, but how can you know for sure?
Why would you put a USB hard drive in /etc/fstab? And if you had a valid reason, why wouldn't you use either the noauto or nofail options?
Exactly! This is the MASSIVE point that pro-systemd-ers completely fail to address.
If any portion of my sysvinit system fails to process... at the console I can ctrl-c, carry on, and figure the issue out normally.
This sounds like a possible security issue. You shouldn't be able to modify system behaviour without authentication (if required), as it could allow authentication bypass (just reboot your machine and CTRL-C to access a root shell). For example, there is a recent bug regarding LUKS encrypted partitions that I believe systemd isn't vulnerable to. Even if that is not the case, correctly handling untrusted input isn't something that everyone gets right all the time and I believe systemd was designed to *not* take keyboard input at boot time by default.
If you want to boot in interactive mode with systemd, use systemd.confirm_spawn=1 at the kernel command line (see http://fedoraproject.org/wiki/...), on production systems I have deployed this would require entering a grub password (hopefully with a version of grub that can't be bypassed :-().
1) It's possible - a big part of Gnome3's growth however was weakening the "we know what's good for you" arrogance of the developers (partly due to the huge user-losses they suffered on release) and actually listening to their users. Thus far, systemd seems quite uninterested in that.
2) This leads into the other problem with systemd - which may make the odds of improvement lower. It is more on the fundamental design level. There is a reason the unix philosophy is what it is. "Small programs that do one thing and do it well", "Simple pipes and text-based configs and communications. It's because this has been the single most succesfull development philosophy is the history of computer science. Unix is now almost 50 years old - no other OS that old is still in active use. It runs on everything from massive server-farms and mainframes to cellphones. Doing widely disparate jobs and it adapts to all these completely different usage scenarios. Just within Linux you have GNU stacks, you have the JAVA based android stack, you have busybox - if you feel like it you can build a system by compiling BSD utilities from source on a Linux kernel and build BSD/Linux - nothing stops you (the only reason you can't go download that is because nobody has wanted it badly enough to maintain such a system - but there's nothing stopping you from making one).
The reason it can adapt is that philosophy - because it's made up of simple drop-in-and-replace programs you CAN adapt it for any use-case. The unix philosophy is very much the software equivalent of an old-style giant bucket of legos. You can drop and in and replace any brick with any other, the pieces are all ridiculously simple but they can connect to each other in well-understood ways and you can build truly magnificent structures by coupling all these simple pieces together in arbitrary ways.
SystemD violates that approach entirely. And so you get the very issue you describe - in one of the most common use-cases it works quite well, in the other most common use-case it works a lot less well - and in the millions of niche use-cases... it fails entirely, because I can't no longer take individual components and arbitrarily swap them out, or put them together in arbitrarily different ways.
The Unix philosophy is to give you a bucket of lego bricks so you can build whatever you need.
SystemD is more like the modern lego-kits, sure it may give you a prettier model of the death-star, but you can't build a model Boeing 747 from the same kit. The lego company apparently decided they'll make more money selliing people single-purpose kits than buckets they can play with for decades and build anything with - it doesn't mean the buckets weren't a far superior product.
And that's a real issue- because even the one use-case it's great at isn't static (not to mention it's a shrinking part of the market - I suspect it's only a matter of time before only programmers, gamers and engineers have desktops at all anyway) - the needs there will change in time, it may change very radically, and it's impossible to predict how it will change. For Microsoft it meant having to rewrite their entire API from scratch in the mid-2000s because it simply could no longer do what their market required, systemD is now creating the groundwork for the same thing happening to Linux in the end - because it's not small, generic blocks you can put together differently to meet new needs when they arrive, you either have to extend systemD to support those needs - or if it cannot be logically be extended that way, you'll have to abandon it entirely and write an all new system !
That's a very real issue - and one there is no good answer for.
So, unfortunately, that leads me to predict that systemD is more likely to get worse than better - the more our needs evolve, the harder it will be for such a large all-encompassing and interconnected project to evolve along.
Unicode killed the ASCII-art *
But downstream isn't one place, there are multiple stops along the way. The assessment of "Better" was made on stop down (the distro packagers) but nobody every really considered the question of whether it would be "better" (by your own measure) for the those even further downstream - the users, the sysadmins, the devops engineers.
I think, objectively, that it wasn't - at least for a large subset of those further downstream (notably experts and sysadmins).
Unicode killed the ASCII-art *
I'm your phantasy world problems keep popping up due to systemd. Over here in the real world I and many others have been using it for several years and have had none. It's funny that of the many people complaining almost nobody offers a real world example and in the rare case that they do it turns out to be their ignorance that is the problem. It isn't perfect, but let's not pretend init script based systems didn't have their share of problems either. It's called software. By definition it will have bugs that need to be fixed upon occaison.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Mostly these are packages that predate the establishment of the /etc/default standard, or packages that are small third-party things that aren't shipped by distros, or are so badly coded that you can't actually change installation paths during the build process.
Because even if packages typically don't do it, distros would usually change that- even when it means applying patches to the code while building packages (official debian packages almost always have patches included to modify the package to debian standards - other distros are a bit more lax about it).
But SystemD is not archaic, and it's not a small third-party package whose developers are few in number and perhaps just don't care or know about the standard. It's a major system component, which has pushed itself as an irreplaceable part of every major distro now. Surely such a component of all things should try to comply with good practise and standards ?
Surely the the bar should be higher for a component that aims to replace most of the other components in a linux system ?
But SystemD has never cared about best practise or standards or legacy of any kind. They do whatever the hell they want and everybody else has to either adapt to whatever THEY decided is how we WILL work - or we have to go to the extreme effort now required to avoid them.
That's the opposite of how it's supposed to work. You want your code in a distro ? On my PC ? You should be adapting to the distro's standards, and to MY needs and desires - if you can't do either, then you belong on neither. Upstream should not get to dictate to downstream, that's the way of closed-source software.
The entire point and purpose of free and open source software is the opposite: that downstream should be in control of itself, which requires that the only possible path to acceptance for upstream must be to comply with the wishes and standards that downstream establishes.
Unicode killed the ASCII-art *
I find that logs still get pumped out to /var/log on Ubuntu, yet journalctl captures information that never went to those logs, so it has been an absolute boon in troubleshooting things I'd never understood before. There was a time when I'd occasionally try to run the application myself, or modify the init script; frequently I found this nigh-on-impossible with the ultra-complex, 700-line bash scripts Redhat and Debian like to shove into init.d.
Docker has also been a godsend.
The one time shit pissed me off was when I had /var/spool/mail in fstab, as it's a symlink to /var/mail, and systemd decided one day it didn't like that and forever refused to boot. Took me 3 hours to figure out that wasn't allowed, fix fstab (from the systemd recovery shell it happily offered!), and reboot. That was during an Ubuntu major upgrade.
It's never given me trouble, and has cut out the amount of time spent looking under the hood and trying to muck about with machines nobody honestly understands.
Support my political activism on Patreon.
That's the first one I could find; it's not like rejected patches are published -- after all, they were rejected. You're asking for evidence that only the person who submitted the patch and the person who rejected it would have, and you're asking in a place where you know you won't find either of those people. That I was able to find one example of something that it not typically published tells me there are likely more; if you were thinking objectively, you'd see this truth.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
I've never found journalctl to contain anything that wasn't in /var/log - but if you only checked one file in a folder full of logs you'd likely have missed things.
And if you recall, I said in my original post that System-V had issues - you mention one of the worst, I just don't think SystemD was the best answer available - it wasn't even in the top-5 best alternatives that were available at the time. Personally I think upstart was but there were several other very good ones, and none of them should have been in EVERY distro - each distro should have been using the one best suited to the use-cases and target markets that distro was aimed at.
Unicode killed the ASCII-art *
Hint: look in all the "/etc/rc?.d/" directories, and not in "/etc/init.d".
Of course the /etc/rc?.d directories consist entirely of links to the files in /etc/init.d, all 9000 odd lines of them.
Tell a lie, there are two files in /etc/init.d that are not linked to by /etc/rc?.d -- /etc/init.d/README and /etc/init.d/skeleton.
So, tell me, when did you learn how sysvinit works? Been using it since 1994 like me?
Watch this Heartland Institute video
it's not like rejected patches are published -- after all, they were rejected.
Huh? You think systemd development is done in secret? On what basis?
It's been claimed that the systemd team are rejecting patches en-mass. So far the only example seems to be a trivial change to an automake file, which doesn't seem to have been proposed with any real justification.
But never mind, you've decided that because you can't find anything it must exist and be hidden.
Watch this Heartland Institute video
I can guarantee they've rejected more than one single patch. Where do they publish the list of rejected patches, then? I never claimed development was done in secret, only that no list of rejected patches is kept; and if such a list does exist, surely it lists the rejected patch I've provided, right? So where is it?
As I said, such a list does not exist; but that is not evidence that no patches are rejected; if it were, I would not have been able to provide a single rejected patch.
Dude, get a clue.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
It is a fact that GNU+Linux has got thousands of programs everything doing its task. Systemd has to specify its goals else it is doomed. First of all most programs are never used. At least on my system I mainly use emacs, gcc and make as well some libraries. Minimal operating systems are a big deal. Systemd is overloaded and doesn't really do anything the user benefits of directly. You should ask yourself if you put in a room so much theory, does it become thinking once.
(just reboot your machine and CTRL-C to access a root shell)
In pretty much every distro I've used, this is not possible. Any interaction that would give a root shell, would also require the root password. My point being that in an emergency situation you can skip things like dhcp that may completely freeze the boot process.
The goal of computer science is to build something that will last at least until we've finished building it.
Absolutely. There are some things that are definitely GOOD about systemd. The extensibility/overloading of the service/unit files is a good example of something that works well and is implemented in a way that makes a lot of sense. For example, you can have a service file at /usr/lib/systemd/system/somesystem.service /etc/systemd/system/somesystem.service.d/*.conf
And then modify functionality with units under
It's easy to do, and works nicely with packaging systems so that you can create an addon package to modify or add behavior without editing the file(s) supplied by the original package. The way you can build dependency chains is also quite useful.
There's also some stuff that is lame, like the binary logs and the needed to run journalctl or systemctl to figure out WTF your daemon is doing when it fails, or how the binary log can be corrupted so that you can *never* figure out what happened in some situations.
The biggest problem is the lack of compromise. A lot of people in SystemD-land have a "my way or the highway" attitude, whereas a lot of people in init-land have a "change is bad" mentality.
" Forceful, unconditional kernel operations. When I say "unmount this filesystem," I'm not asking a question. When I say "terminate this process," I expect the process to be removed from memory and the runqueue, regardless of consequences."
Thank you. Nothing is more maddening than doing a "-f" type of operation, particularly an unmount, and having the system bitch at you because "I think something is still using this". I've had major issues not being about to release USB devices that have glitched up because "umount -f" still refuses to actually unmount.
Why even have a fucking force option if it doesn't actually work?
I run Devuan on my home computer and seems to run OK, no big issues. I don't do much either except LibreOffice and a Browser, maybe the occasional scan and GIMP.
One thing about the Devuan community, they were strangely silent when I first tried to contact them after my first install, so I gave up. Many of their web pages also told me 404 on their links.
I update with Synaptic. Funny thing about Synaptic on Devuan. You only get the Title line of a program in the description window. There are no descriptions. If you want to find out what a program does, you have to google it up and hopefully the program name you're looking for isn't some common word.
Tracy Johnson
Old fashioned text games hosted below:
http://empire.openmpe.com/
BT
Bjarne closes with the assertion that clean code does one thing well. It is no accident that there are so many principles of software design that can be boiled down to this simple admonition. Writer after writer has tried to communicate this thought. Bad code tries to do too much, it has muddled intent and ambiguity of purpose. Clean code is focused. Each function, each class, each module exposes a single-minded attitude that remains entirely undistracted, and unpolluted, by the surrounding details.
PS: Emphasis mine
Slashdot ya no es que lo era!
Mostly these are packages that predate the establishment of the /etc/default standard,
Given all the packages I've had to mess around with over the years and seeing how they like to do things, I think /etc/default was a very short-lived standard that most just didn't pick up. I'm looking backwards at some of the distros I've used over the years, and I just don't see that it got a lot of traction.
Lots of daemons don't capture stdout. On some systems, you can see logs spew to the console, making tty1 unusable.
Upstart was another SystemV-like, but better. I generally think of Upstart and whatever Gentoo uses as "SystemV" because they attempt to be that with new capabilities.
Just imagine if they all integrated Supervisord instead.
Support my political activism on Patreon.
Upstart was in no way system V like, it had a backwards compatibility feature that led system V scripts work but that was only for non-updated third party software. Upstart's own system used config files, not scripts. Its wrapper utility commands were compatible with older ones created for system V but were drop in replacement code. Upstart was parallel capable, sensibly structured (dependency model) and fast. It was the right way to improve init. And it was just init. Upstart didn't mess with anything else.
Capturing stdout was never actually a good thing. It's not supposed to be logged. It's supposed to be read live if you manually start a command and contain information only useful in that scenario. A well written daemon will not write anything to stdout at all unless you specify foreground running in which case it should give debug level info.
I didn't work with gentoo's init enough to comment on it.
Supervisord is a prime example of why systemD is a bad design. It's a terrible init approach... For almost but not quite every use case. But for what it is designed for its absolutely brilliant, indeed better than anything else I have seen.
Thats exactly where systemD annoys me, no single program can ever be the best for every use case, so having a program that is so tightly coupled to so much of the system that it's hardly possible to replace it (and trying means weird breakages in utterly unrelated software) is terrible because it inevitably forces a bunch of use case to use inferior software.
We have apache and nginx and haproxy and there is great overlap in what they do but none can fully replace the others. Haproxy is simply a better load balancer than the others if your use case is complex because it's specialized and thus has far more powerful features. Apache is still better at doing things like tomcat hosting and nginx is deservedly popular because it's great.
But nothing in nginx says if I use it for web hosting I cannot use haproxy for load balancing despite nginx also having loads balancing features. If I need the extra power of the specialized tool nothing in either stops me combining them.
That's how it should be. The job should dictate the tool, nothing else. There must be standards about how tools talk to each other, how they respond to signals etc. But never standard tools. The task should determine the tool and no tool should make it difficult to swap out a component when a task would be better served by a different one.
There is no such thing as a best program. There is only the best program for what I am doing right now.
Unicode killed the ASCII-art *
B) Traditional init systems are very limited and badly limiting nowadays. Like still using DOS as the underpinnings of your actual system. A more generic event/trigger system is much more sensible.
Yes, the traditional init systems are so limited that I've never ever had a problem with them in the 25+ years that I've been a *NIX user and admin. The fact is they work great for the vast majority of users.
I'm so happy that my environment was migrated from RHEL to Amazon Linux where I don't have to deal with the systemd nonsense.
Even if you are right it doesn't follow that text config files belong in /usr/lib does it? That's where libraries go. At the very least if it had to be under /usr it ought to have been in /usr/share/SystemD
Unicode killed the ASCII-art *
If "service xyzzy restart" doesn't work then "systemctl restart xyzzy" wouldn't work either
Yes. So?
CLI paste? paste.pr0.tips!
Sorry, It's just that your original message wasn't clear -- I thought you were complaining that the "service" command wasn't working properly, not that systemctl restart wasn't working for you.
So did you manage to find out why "systemctl restart" wasn't restarting the service? What service was it?
Watch this Heartland Institute video
but not writing "bad code" isn't an option when even OpenSSL get major holes.
That's a bad example, the openssl people didn't even try.
"First they came for the slanderers and i said nothing."
SELinux is not hard to deal with, especially in targetted mode. Otherwise I agree.
- Michael T. Babcock (Yes, I blog)
Why would we contribute to an obviously broken concept? Most of those complaining feel systemd falls into the "shred it and start over" category, not the "needs a few patches" one.
- Michael T. Babcock (Yes, I blog)
That is to say, systemd fixes udevd not init.
- Michael T. Babcock (Yes, I blog)
It shouldn't take more than 3 lines of perl to do anything.
- Michael T. Babcock (Yes, I blog)
Systemd is an unstable, buggy, and a giant pain in the ass piece of shit.
It boggles my mind why the big distros ever jumped on it, but I can't wait for the day when they eventually get over the whole fad and move back to simple startup scripts.
Yeah, you should see my replacement for AlphaGo.
Watch this Heartland Institute video
Today I learned that "conversations of slashdot" are consider "coding" by some people...
Unicode killed the ASCII-art *
Raises the question, better for whom? Systemd seems to make some things easier for distro maintainers, at the cost of fucking shit up for users and admins.
That said, Debian's vote on the matter was essentially 50:50, and they're going to keep supporting SysV init.
they've claimed that they're supporting sysvinit... but in reality, as one of the posts further up points out, they had to REMOVE absolutely critical packages such as udisks2, policykit, and a fxxx load of other absolutely critical packages which should in absolutely NO WAY have anything to do with BOOTING.
even xorg now critically depends on libsystemd, i mean what the fxxx, man??
the only way to get rid of the dependencies cleanly and with full confidence that they're truly gone... and yet at the same time maintain a debian system... is to install angband.pl's alternative replacements.