Slashdot Mirror
New Year's Resolutions For *nix SysAdmins (cyberciti.biz)
An anonymous reader writes: A new year, with old systems. It is time to break bad old habits and develop good new ones. This list talks about new years resolutions for Linux and Unix sysadmins. List includes turning on 2FA on all services, making peace with systemd, installing free SSL/TLS certificates, avoiding laptops with horrible screens or wireless whitelist in BIOS, building Linux gaming rig and more. What resolutions are on your list regarding sysadmin or IT work in 2016?
is 4k baby!
maybe i should finally do dnssec. i've been planning to do it for about 5 years.
"making peace with systemd" Might as well make peace with terrorists.
I've made my peace with systemd by switching all my machines to BSD variants - pfsense for my router, FreeNAS for my file server and OpenBSD for my desktop and laptop.
I'm one of many who have fled into BSD-land. 2016 will see an even further decline in the amount of Linux users. Linux can only shit on its userbase for so long (systemd just being the most well-known example of not listening to users) before the mass exodus kicks off.
This is a problem with "old vs new".
sys V init is old. So are the old, genuine unix wizards.
SystemD is new. So is Pottering and Pals.
The divide comes from "old culture" vs "new culture." The old unix culture adores simplicity, sparseness, and adaptability. The new culture adores easiness, one-stop shopping, and cohesive wholes.
This argument will never really die. The old culture will point out the endless littany of security problems with software like systemd, simply because of the complexity and scope-creep of the project. (this increases its attack surface, and makes it attractive to malware authors and hackers.) The new culture will point out the endless littany of hair pulling and hours spent dealing with obtuse scripts and strange scripting behaviors for things they feel should be solvable with a mouseclick.
These two will never live under the same roof. Both are right, and both are wrong. There are systems and applications where sysVinit makes sense, and is desirable. There are systems and applications where systemd makes sense, and is desirable.
The real sin here is not heresey by either group.
The real sin is the decision of the foss community to pick a side, and in so doing, remove that choice from other people, by choosing to make systemd a hard requirement, solely for their own convenience.
systemd was thrust upon everyone and you want us to accept it just because? how about this: document the code, document the interfaces, solidify the ABI, make the code portable, do a security audit instead of trying to force me to use systemd!
my resolution is to uproot systemd's tendrils from an otherwise decent operating system.
Anons need not reply. Questions end with a question mark.
I'd mod you up if I hadn't used all my points.
They sentenced me to twenty years of boredom
This is a problem with "old vs new".
sys V init is old. So are the old, genuine unix wizards.
SystemD is new. So is Pottering and Pals.
The divide comes from "old culture" vs "new culture." The old unix culture adores simplicity, sparseness, and adaptability.
The "old culture" knows that a server is just part of a bigger process, and reliability and maintainability are more important than simplicity, sparseness (whatever that means in this context), and adaptability. Without something like systemd, Linux cannot be enterprise ready. "Rolling your own" scripts for failover and redundancy is the worst idea when more than one admin has to diagnose problems at 2:00 AM. You want something supported by the vender, with standard configuration options, that can be easily understood by everyone on the team. Sometimes the "most elegant" solution is not the best for the business.
The only thing worse than a Democrat is a Republican.
The main arguments against systemd are that it's monolithic
Here is the output of ps -ef | grep systemd on a Ubuntu 14.04 desktop which uses upstart and not systemd as its init system:
root 387 1 0 2015 ? 00:00:00 /lib/systemd/systemd-udevd --daemon /lib/systemd/systemd-logind
root 701 1 0 2015 ? 00:00:00
It's clearly not completely monolithic if you can run two fairly central components without even the init daemon present.
rapidly becoming non-optional
Yes, in some distros. It's entirely up to the distro maintainers what options they want to support. That they choose to focus on supporting systemd is hardly systemd's fault.
was quickly shoved into every distro that matters.
Systemd was included in Fedora 15 which was released almost five years ago and we still have distros that are going to switch. This is one of the slowest tech migrations ever to take place in the GNU/Linux community.
I don't buy that init scripts are simple or even particularly adaptable. I've hand crafted a few in my time and they are always a pain in the arse to manage. When you get to the point of having multiple scripts bring called which then call sub scripts and all of them somewhat unique to that machine... It's time to look for something better.
I have not played with systemd extensively, but it seems to have the right idea. While in theory scripts give you more control, in practice they just make it harder to admin the system and make you waste time hacking them. Having it all tied together and controllable from one place is much better.
I used to have a highly customised Firefox install. Eventually Firefox sucked enough to drive me to Chrome. At that point I realised it was better to just adapt my workflow to something better some times, instead of proclaiming it sucks because it doesn't do things the way I did a decade ago.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
That's because it's not related to init. Init is one subsystem. systemd, being a process manager, doesn't care if init is included or even when it is started. Once it's started, the communication between the parts are within the systemd communication channels (increasingly). This is what makes it monolithic. SMH
Please correct me if I'm wrong here but what process manager are you talking about? Pid 1 on Ubuntu 14.04 is upstart and it owns both of those two services. They are as far as I can see running completely independent.
If just systemd really was easiness, it's definitely just like fishing in muddy water.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
The real sin is the decision of the foss community to pick a side, and in so doing, remove that choice from other people, by choosing to make systemd a hard requirement, solely for their own convenience.
Did you just try to make writing software to scratch your own itch sound like a bad thing? If Poettering wants to write systemd-only software, nobody's going to stop him. Nobody should be able to stop him. Nobody's going to force him to create or maintain SysV init scripts either. And if other projects find that depending on systemd is convenient, so can they. Open source is not a democracy. Developers do what developers want, regardless of what their users think and by users I mean everybody from other projects to distro packagers to system administrators to end users. The conflict was lost when systemd was voted in as the default, trying to bend the Debian system to force developers to preserve the old ways was a fool's errand. If it had passed, all that would have happened is that Debian would have lost them. Nobody can make that kind of committee decision stick.
Live today, because you never know what tomorrow brings
In particularly one that is trying to destroy all that is good and proper like systemd? Making peace with it would be stupid!
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I don't buy that init scripts are simple or even particularly adaptable. I've hand crafted a few in my time and they are always a pain in the arse to manage.
If a daemon needs a complex init script to manage it, then systemd won't be able to manage it at all, because it can't do everything a script can do. If systemd can manage a daemon, then it didn't need a complex init script, and you did it wrong.
When you get to the point of having multiple scripts bring called which then call sub scripts and all of them somewhat unique to that machine... It's time to look for something better.
If you need that much complexity to run a daemon, then either your daemon sucks or you do. Unless, of course, you're just talking about simple things like script libraries. If those confuse you, perhaps Unix is not for you. Shell scripting is a core Unix feature.
If you could explain cogently what you meant, perhaps you would get different responses. But so far, you're talking bananas. Systemd's unit files are merely a handful of name-value pairs, they don't even need sections because all of the names are unique (even between sections) but they put sections into them anyway because systemd is all about obfuscation, and needless effort. Systemd's "additional functionality" (unit files, cgroups support) could be replaced by a relatively small shell script, based on existing init scripts. Indeed, any distribution which uses script libraries in its init scripts could have done this cheaply. For example, cgroups are a kernel feature manipulated via short, common commands, like creating directories.
I used to have a highly customised Firefox install. Eventually Firefox sucked enough to drive me to Chrome.
I used to use Chrome for Google services. Eventually Google fucked Chrome hard enough to break Youtube ad-blockers. Then I realized that people who use Chrome are Part Of The Problem.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Seriously, I hate that shit. Your computer is not a "rig".
Nice propaganda piece, full of lies and slander. My guess is you still work for that marketing company and got paid to write that.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
The real sin here is not heresey by either group.
The real sin is the decision of the foss community to pick a side, and in so doing, remove that choice from other people, by choosing to make systemd a hard requirement, solely for their own convenience.
I completely agree. If I could just easily ignore systemd, because whenever I install a new Linux machine, I get offered both alternatives by default, I would not care at all. This way, I have the thing forced on me (or nearly so), which is just not acceptable.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Wrong - it's with systemd that Linux will have a very hard time to be enterprise ready.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
The "old culture" knows that a server is just part of a bigger process, and reliability and maintainability are more important than simplicity,
That is why Systemd is fail. Shell scripts have reliability and maintainability. Systemd complicates troubleshooting of the boot process, and requires that we trust code written by a known lame. Remember pulseaudio? I sure do. I spent hours fighting with it.
Without something like systemd, Linux cannot be enterprise ready.
Why?
"Rolling your own" scripts for failover and redundancy is the worst idea when more than one admin has to diagnose problems at 2:00 AM.
Only if your goal is to hire sysadmins too stupid to comprehend shell scripts. The problem is that people that dumb are also too stupid to troubleshoot problems. Try hiring some of the many out-of-work qualified sysadmins who actually know Unix, instead of an H1-B or some kid just out of school.
You want something supported by the vender, with standard configuration options, that can be easily understood by everyone on the team.
And that is how vendors have been using Unix since forever. With shell scripts, supported by the vendor, with standard control flow, that can be easily understood by anyone intelligent enough to be a systems administrator to begin with. Your complaint is that the point and click Microsoft-or-Apple-fanboy-wannabe-sysadmin cannot point and grunt his way through poorly implementing Unix configuration. No one who knows what they are doing will have sympathy for that idea, because there are so very many qualified professionals going unemployed right now. It's not hard to get people who know what they are doing, if you try to hire them. You don't want to do that. You want to hire idiots and you want magically good results. But someone incapable of systems administration without systemd will simply fall flat on their face when a problem crops up, and because they're using systemd it will be harder to troubleshoot the problem.
TL;DR: A monkey who can't understand a shell script can't be a real sysadmin anyway. All they can be is a button puncher. They should work in a NOC, and you should hire someone who knows Unix to administer Unix.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Completely bogus argument. Linux has been "enterprise ready" 10 years ago. You probably also think Solaris was not "enterprise ready" before it got SMF, (the
"systemd" of Solaris) yet most enterprise sysadmins hate its guts and Solaris did run a lot of mission-critical things long, long before SMF ever made an appearance.
Incidentally, in actual enterprise-setups, you do fail-over via network elements, not on the machine itself. But I guess you do not know that because you actually have no clue what you are talking about.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
... are not in my future.
now we need to go OSS in diesel cars
Uh huh.
And how did that work out for Gnome3, Ubuntu's choice of Unity, or MS's choice of Metro?
Oh, right. It resulted in a user revolt.
It's a two-way street, even if you don't like that fact. Developers become irrelevent without user satisfaction.
Except of course, that the old strategy doesn't work without constantly having sysadmins grooming and spoiling their pets (servers), something they seldom do other than as an afterthought after a long and hard failure. Heck, at some companies I've been to, nobody can reboot any servers without all the admins being alert and starting services manually.
If we are to compete with cloud solutions, we need to treat servers and services like cattle. Slaughter the ones that have problems, diagnose later and bring up new ones to replace bad parts of the whole system. This requires something like systemd on the infrastructure/platform side, and then it makes sense to have similar strategies on each server also - to support hot-swappable parts and a rapidly changing platform. To do this manually with scripts is really not feasible, as it doesn't work in practice and you're often dealing with race conditions that always can bring new surprises. The next OS update might change everything again as well, and does not support your assumptions, prayers and hopes.
What we need to support is private cloud solutions, or we will be out-competed by more efficient public cloud solutions. For this to happen, some of the grumpy old grey beards need to retire. You have planned for that, right? No, I think most of the old-timers have planned for nothing but their own benefits, and deserve absolutely no sympathy in this regard. Fuck you, for making the workplace a miserable place to be at!
Captcha: nestling
If a daemon needs a complex init script to manage it,
Define complex. 99% of init scripts are handling of the state of the daemon, PID files, configuration etc. Or to put it another way: Every daemon on my system can be started with a single line in the console, why do I need a script to manage it at all?
You are right. Init scripts don't need to be complex. Yet on every system they are still longer than 1 line, actually they are typically longer than 100 lines. I've written systemd scripts (or whatever they are called). I've written upstart ones. I've copied and pasted and modified a sysv init script and would have probably cut myself if I were forced into a position to write one from scratch.
Eventually Google fucked Chrome hard enough to break Youtube ad-blockers.
That is news to me. I haven't seen a youtube ad on my computer in many years.
This has been this way for a long time. Redhat maintainers actually wrote a long post about "choice" a decade ago. Their efforts for maintaining a distribution go up exponentially far more than simply maintaining 2 packages with 2 startup scripts if they give the user choice. Their summary was you have choice as far as what distribution you use. Don't like what is being provided, then fork or move to another distribution.
Quite frankly given the poor state of many distributions with regards to unresolved bugs and very slow moving adoptions of features I fully support them not wasting time on trying to please everyone.
Keeping track of the PID is important if you want to kill the process reliably when it hangs up. (because invoking the executable to tell it to down wont work reliably with a hung process.)
That is, unless invoking ./etc/init.d/foo shutdown is harder for you than doing
ps -A
to find the process ID then doing
sudo kill FooID
I suppose you might feel it safe to use
killall foo
but what if you have multiple instances of the daemon running? (say, different ssh server daemons on different ports)
Taking the time and enduring a little pain so that you can do ./etc/init.d/foo#x shutdown
to shutdown instance x of the daemon saves lots of time and effort later.
I agree. I just disagree that you should replicate a 100 line script for every bloody instance and every daemon over and over again when that should be handled by the parent part of the system.
What we need to support is private cloud solutions,
No, junior. That's called a cluster. Cloud computing is when you spin up instances as you need them, and get billed appropriately. We don't need systemd for clusters. They predate it dramatically. And we're already using virtualization, which also doesn't require systemd. If there's anything else old that's new again that you would like explained for you using only short words, let me know. I'm here for you.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
If a daemon needs a complex init script to manage it, then systemd won't be able to manage it at all,
I see...
If you need that much complexity to run a daemon, then either your daemon sucks or you do.
So what you are saying is that some daemons suck and are better avoided anyway. Okay.
Eventually Google fucked Chrome hard enough to break Youtube ad-blockers.
Strange, they work fine for me. There is an issue if you install the YouTube app because, for security reasons, extensions can't screw with apps. Just uninstall the YouTube app and it will go back to loading as fast as in other browsers, but your ad-blocker will work.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
I like many people, have used init scripts for years and very rarely have i had to customise any of them or write my own, and almost always use the standard init scripts that come with the package.
However i do understand shell scripting, so i can see what the init script is trying to do and go through it manually if i need to debug something or if i need to run something in a non standard way (for instance recently i had a hardware failure, so we mounted the drive in another server and brought its services online temporarily inside a chroot).
I have a recurring problem on OSX where a service checks a pid file, but if that service failed to shut down correctly before a reboot the pid file is still there and if something else has started on the same pid the service won't start... This was a pain to debug with the launchd system on osx, but would have been easy with init scripts.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
The world keeps moving forward. The enterprise world looked different ten years ago. Back then you treated servers like pets. Now everything is about cloud and servers are seen more as cattle and that changes everything. Sysadmins used to keep the same installation up for years, even rebooting only when switching out the hardware. That era is going away. Bring up a new server instead, or 10 000 new ones. Rebuild your entire infrastructure every single day. Why install updates when you can just create new servers instead. Keeps the systems reproducible. That's where systemd fits it, because it handles all of this. Sysvinit made assumptions about what the world looked like, where it could write files and not. It does not lean well to making atomic systems, which is where the enterprise is going. That's why we need systemd.
That's why systemd doesn't use "PID files". It's a broken concept.
Systemd on slashdot? That might go over like a lead balloon from what I've seen herer with some.
Surely you mean a lead (spelled led) zeppelin?
The article is rather insightful and one of the few that are worth reading. I disagree with a few points (2FA for ssh on his personal workstation?!?) but there are some good points in there:
* Make peace with systemd
* Learn the new tools: ip, ss, iw (not on his list, but on mine)
* Learn ZFS (on my list for half a decade)
* Use tools such as Lets Encrypt on all websites (good idea in theory, in practice not feasible due to 3 month certs)
* Learn Android
* Stop doing IT consulting for cheap businesses. Unfortunately, this is actually where the bulk of my bread comes from!
It is dangerous to be right when the government is wrong.
When I read that, I hear the voice from the "mongo db is webscale" cartoons.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Not just exponentially, but far more exponentially?
Since I'm obviously not as clever at maths as you are, can you tell me the equation for that?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
LOL, Linux and Gaming Rig in the same sentence, who'd have thunk it eh. Microsoft should also port excel to the playstation 4 and Xbone so they will obviously take off in the financial industry as a direct replacement for Windows based PC's.
I've been using unix (ie. only Linux but we'll pretend that counts) for over 15 years now. Not quite the "old" you may think of but old enough.
I gave systemd a try. It actively fought me and I cannot accept that. It has too much of a "my way or the highway" mentality that you just can't fix without major C hacking and recompiling. If you don't like its way of doing things then too bad.
sysvinit scripts may be slower to boot and have fewer automatic/behinds-the-scenes features you want, but I can make any arbitrary change to them with minimal effort. I can run them with line-by-line tracing using "set -x" and find out exactly why it's hanging. I can rescue it with *any* install media even if it doesn't have systemd and '/etc/init.d/servicename start' will actually work.
systemd is fine for desktops run by people who think Firefox is the only app they really need to Surf The Net. sysvinit is designed for people who want control of their systems and want to be able to inspect what it's doing. And I'm sorry, I NEED the latter to do my job properly.
You want equations look on the RedHat mailing list. The example they cited involved maintaining 2 programs in the distribution, doubling the testing cases for some 50 other programs that now rely on not one but two dependencies, and writing and maintaining a program to allow the user to switch between the two cases.
You can crap on my pre-morning-coffee post all you want, but that doesn't change the facts. The maintainers of a distribution themselves have come out and said WHY they don't provide more choice to the user. Don't complain to me, complain to them.
* Use tools such as Lets Encrypt on all websites (good idea in theory, in practice not feasible due to 3 month certs)
Take it as a good incentive to learn automation.
The real sin is the decision of the foss community to pick a side, and in so doing, remove that choice from other people, by choosing to make systemd a hard requirement, solely for their own convenience.
Did you just try to make writing software to scratch your own itch sound like a bad thing? If Poettering wants to write systemd-only software, nobody's going to stop him. Nobody should be able to stop him. Nobody's going to force him to create or maintain SysV init scripts either. And if other projects find that depending on systemd is convenient, so can they. Open source is not a democracy. Developers do what developers want, regardless of what their users think and by users I mean everybody from other projects to distro packagers to system administrators to end users. The conflict was lost when systemd was voted in as the default, trying to bend the Debian system to force developers to preserve the old ways was a fool's errand. If it had passed, all that would have happened is that Debian would have lost them. Nobody can make that kind of committee decision stick.
I am a little suprised that someone with your UUID would have such a philosophy about the Debian project, but fair enough. I'd like to refer you to the Debian Manifesto, a document that was written when the Debian project was first founded. In particular, I'd like to refer you to section A.3:
thus, a distribution is created based on the needs and wants of the users rather than the needs and wants of the constructor.
, with "constructor" referring to the creator.
To be very clear, I am not advocating that Poettering shouldn't be programming what he pleases, nor that all work should be productive. However, I am saying that at least for the Debian project, the focus (used to be) on the users, and making a solid operating system useful to everyone. There's been a large resurgence in the "developers first" attitude the last couple years, and while it lends itself well to hobbyists, these kinds of people should not be working on a large and collaborative project with the goal of being useful to everyone - because, as you've made very clear, the center of that philosophy is all about your wants and needs, something which is directly contrary to the main goal of the Debian Project (and really, any large open source project whose goal is to be useful to more than the developers).
"Set a man a fire, he'll be warm for the rest of the night. Set a man afire, he'll be warm for the rest of his life."
Take it as a good incentive to learn automation.
You are 100% correct, and I will in fact address it that way!
It is dangerous to be right when the government is wrong.
Without something like systemd, Linux cannot be enterprise ready.
Why?
"Rolling your own" scripts for failover and redundancy is the worst idea when more than one admin has to diagnose problems at 2:00 AM.
Only if your goal is to hire sysadmins too stupid to comprehend shell scripts.
And there you've just answered your own question as to "why?" Not that their goal is to hire stupid sysadmins, but their goal is, to some extent, to avoid relying on people being particularly competent.
I see this as part of the disconnect between techies and business/manager types, and you're only illustrating it. For those who are pretty good at the tech stuff, they think, "That's ok, I'll just write a custom script, and if something breaks I'll figure it out." Meanwhile, the business guy has been burned by that too many times. For the handful of competent techs he's hired, he's also hired a couple incompetent guys, as well as some who were fairly competent but not as smart as they thought they were. He's seen a tech write that custom script, he's seen it work well enough for a while, and then seen it turn into a disaster as soon as someone else had to touch it.
It's hard to run a business relying on everyone to be a bunch of super-hero super-geniuses. Businesses want a solution that's drop-dead simple. They want things to be used in the way they're supposed to, and to be fully supported. They don't like customization unless it's something that was designed to be customizable, and supported in that customization. They want it all to be documented and clear, and they don't like relying on people to be good at their jobs, because no matter how hard you try to hire good people and how much you're willing to pay them, most people turn out not to be particularly good at their jobs.
I'm not saying these are unbreakable rules, but there is a sort of tendency. The point is, larger and established businesses don't really want a clever hack that saves them a few thousands of dollars at the risk of a failure that would cost millions. Whether systemd is relevant to that issue-- I don't want to get into that discussion. But you're asking why you need something "the point and click Microsoft-or-Apple-fanboy-wannabe-sysadmin" can figure out in order to be considered by some people to be "Enterprise ready", then that's why.
The most vocal opponents of systemd (whom you mislabel as "systemd trolls") tend to be professional system administrators and professional software developers with decades of experience.
Many of them have been responsible for hundreds of thousands of production servers and desktops. They've used more operating systems than you could probably count. They've dealt with nearly as many different init systems.
These decades of experience has taught them a thing or two. They've come to learn what works, and what doesn't.
Well, it turns out that systemd embodies just about everything that's known not to work well! It's rife with architectural problems, for example. Binary logging is a big no-no. Trying to do absolutely everything, and doing it all very poorly, is a big no-no. Not following the proven UNIX philosophy is a big no-no. These aren't just minor bugs that can be fixed with some code changes. These are deep flaws that require systemd to be thrown away.
It's no wonder we see Linux distribution mailing lists and bug trackers filled with so many reports of problems caused by systemd. Systemd has thrown out decades of accumulated knowledge and experience, and replaced it with approaches that are known to not work.
Systemd has caused a lot of inexcusable problems for a lot of its victims. We're talking about things as serious as Linux installations that don't boot properly. That's one of the worst things that can happen to a Linux installation; it renders it unusable!
Instead of labeling these professionals as "systemd trolls", you should be thankful that they've done the right thing and started moving away from Linux. Many of them have, or are in the process of, converting the systems they're responsible for from Linux to FreeBSD or OpenBSD. They just can't let their critical systems fall victim to systemd and the problems it has been shown to cause.
Fuck you!
I don't buy that init scripts are simple or even particularly adaptable.
Hang on a minute - are you talking about /etc/init.d scripts that get linked to a runlevel in /etc/rc or a script called from /etc/inittab managed by init? - because they are different.
Using /etc/inittab it's pretty easy to make something a system managed service using init this way, to be either respawned, run once, on or off, from a single file.
Customizing rc level 4 is also an option, for example to make the system boot in a more specific way for a media centre client or something more specific. There is no reason why you can't mangle runlevel 4 to make it do what you want and then save runlevel 3 and 5 for more general purpose modes. Following thew media centre example to make an operational rc4 and maintenance mode rc3 or rc5 which you might configure as a boot option.
I think the reason people think it is difficult is because of context. The rc script in /etc/init.d should exit, however the script called from /etc/inittab should not, so that init can act appropriately to manage the process. Scripts in /etc/init.d should only run once at start up or when called manually.
However you can make init maintain a process easily with a line like:
mc:4:respawn:/etc/runMediaCentre If the process is killed, init respawns it. I think people think it's some sort of secret sauce, however it is just a file and a line is similar in complexity to a unit file.
I've hand crafted a few in my time and they are always a pain in the arse to manage.
Yes, they can be however I found that was because of my thinking. I just remember scripts called from inittab don't exit.
When you get to the point of having multiple scripts bring called which then call sub scripts and all of them somewhat unique to that machine... It's time to look for something better.
It might help to think of the design pattern "Strategy". The runlevel scripts linked from /etc/init.d to /etc/rc.d set the context of the machine (like making vpn, db or other things avilable) and the entries in /etc/inittab define the aplication specific strategy that is dependant on that context.
Because init knows what the runlevel is, the strategies are only ever run in context. If there is something wrong with the context, then you have a problem (like no db or vpn).
I run systemd on desktops and test systems - mainly to see what the fuss is about and ensuring I'm prepared if I need to be. I just haven't seen a compelling argument for it. I ask why we are replacing something elegant and powerful.
If you are arguing for systemd, have you ever tried using inittab or customizing runlevels? It is powerful and demanding, but not impossible. As a core *ix paradigm it forces you to skill up to the next level of mastery over your systems and understand how your processes behave.
systemd seems to abstract away that knowledge of how processes behave, like wishing for less challenges instead of more skills.
My ism, it's full of beliefs.
I agree. I just disagree that you should replicate a 100 line script for every bloody instance and every daemon over and over again when that should be handled by the parent part of the system.
No, you should have one script and 100 lines in /etc/inittab. Each line should have different arguments, ideally pointing to a configuration file for that particular instance of your daemon, i.e you have 100 differently configured instances of the same deamon. Then init manages them for you.
My ism, it's full of beliefs.
That's why systemd doesn't use "PID files". It's a broken concept.
You don't need a PID file if you use init properly.
My ism, it's full of beliefs.
* Learn the new tools: ip, ss, iw (not on his list, but on mine)
ip and ss are massive improvements over netstat, well worth learning. These tools are certainly more evolved than netstat
My ism, it's full of beliefs.
How can you become someone like him? Just make things up and force distros to use it...
Wait a minute, that's not really what happened didn't it?
Same here. My biggest worry was about binary logging - I often will grep thru various logs looking for stuff, even if to just show students what is actually going on when something is happening.
But... my Debian 8 setup, with systemd, still has all the log files I'm used to, in the same places they've always been, with the same information in them. So I don't know if systemd is "double logging" or if Debian set this up to keep us old farts happy.
Don't blame me, I voted for Kodos
Unfortunately that includes the people writing systemd.
A binary log that is written to by several things at once if an example of people who have either never heard of a race condition or do not care if the log gets corrupted for example - utter newbie mistake. A computer that won't boot because systemd can't work out what to do with a usb mouse dongle is one of the many examples of how immature the system is despite a decade of work - it's parallel when it's insane to be so and serial when it should be able to do several things at once instead of getting hung on what to do with a USB device when it's really none of it's business and it should let the kernel do that job instead.
Their goal is really just to bring a lot of separate things under the control of a single small group that does not have the patience to solve one problem before they expand to replace another bit of software.
If we are to compete with cloud solutions, we need to treat servers and services like cattle. Slaughter the ones that have problems, diagnose later and bring up new ones to replace bad parts of the whole system.
Here's a guy who gets it.
This requires something like systemd on the infrastructure/platform side
I'd argue that. systemd is pointless in this context. If your server is inflicted with mad cow, you don't restart its left eyeball and hope for the best. You shoot it in the head and burn the corpse.
Virtualization, containerization and configuration management technologies are far, far, far more important than whatever init system is running on your disposable nodes.
My kingdom for a mod point :) Bravo, Mr. poo! Good way to start a year.
Stupidity is an equal opportunity striker.
Fellow slashdotter Bill Dog
It's insulting to call it "old" or "new" (it's also a mindless stereotype). Plenty of people can see the benefits of systemd, at the same time seeing the drawbacks of systemd.
For my own part, I've been working on a code review of systemd. I spent a lot of time trying to understand why it was getting adoption. I've delved into the code and looked at the interfaces.
I suggest reading my reviews, but the end result is this: systemd is a good attempt to solve problems that people have, but it isn't a very good solution.
"First they came for the slanderers and i said nothing."
I agree. I just disagree that you should replicate a 100 line script for every bloody instance and every daemon over and over again when that should be handled by the parent part of the system.
Systemd's daemon management system, which is based around unit files, is dedicated to the idea that you don't need a multitude of init scripts. And in fact, it's broadly true; most programs fall into one of a very small set of cases. But solving this problem doesn't require a new init daemon. All it requires is a new init script which parses unit files, or something like them. The files get a hashbang at the top which calls the script, which reads the unit file and does whatever needs to be done using the usual init script library used by the distribution, if any. You could, in fact, do this with unit files themselves, and if I ever download something that doesn't have an init script but does have a unit file and I don't feel like bashing out an init script based on some other init script, maybe I'll actually do that. But so far, thankfully, it hasn't come up.
I'm not saying that every program needs its own unique init script. What I'm saying is that the important functionality provided by systemd (nobody cares about saving a few seconds' boot time on the desktop when the POST takes aeons) could have been provided by a series of small shell scripts. Yet here we sit arguing about how horrible shell scripts are, because they're being misused. Meanwhile, shell scripts are still easy to troubleshoot, and certainly much easier to troubleshoot than systemd. I should not need to somehow connect a debugger to my system in order to find out why it won't boot, but that's what systemd brings to the table.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
because...
...anything that needs to know what the PID of a process to manage the process should not be managing the process. That is what init does, and it already knows the PID.
Typically, a PID file is scripted when you need to maintain a process. If you need to maintain a PID file, chances are you are using a script in /etc/init.d linked to a runlevel entry in /etc/rc.whatever. The use case here is that you want to shut the process down on shutdown *OR* change of runlevel. In that mode you're trying to figure out K ans S scripts and what order the script is started and shut down so that you can kill your process gracefully on exit.
The answer is you let init manage it. People seem to get confused about setting up the "context" of a runlevel (/etc/init.d) as opposed to the "strategy" employed in that runlevel (/etc/inittab) and then try to write an unnecessary script. If you are scripting an init process and you need to use a PID file, then you are addressing the strategy of the system from within the context and I suspect this is where many people get confused.
init will manage the execution of the system strategy by managing the lifecycle of the process for you. If you want it to stay up, you tell init to "respawn" it, then if you kill it or the process exits, init restarts it. If the system changes runlevel, say for shutdown or other, then init shuts the process down. Or, if you want to take the process down, you disable it in /etc/inittab and kill -1 1 when you are ready. I think there is a vim inittab command that does this for you.
This is where systemd tries to mix the strategy of the runlevel into the context, whereas what you actually want is to have the two concepts loosely coupled so they are easier to manage by isolation. People might be surprised how much raw performance potential init has to offer when you get your head around it especially when you discover that in a lot of cases you don't need a script at all.
My ism, it's full of beliefs.
It's hard to run a business relying on everyone to be a bunch of super-hero super-geniuses. Businesses want a solution that's drop-dead simple.
I get that. The problem that they don't seem to get is that we live in a complicated world, and there is no such thing as a simple solution to that which doesn't involve raining fire down from the heavens, a global flood or some other such reset button which is only available in god games. In the really real world, we simply have to deal with complexities. A computer which could solve all its own problems would be smart enough to go on strike.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
So called "new" culture is just Red Hat trying to force their proprietary crap on everybody by name-calling and shaming.
MS does the same thing. The entire systemd scam is right out of MS's playbook.
The Debian team seems to agree with you, at least, that's why they adopted systemd.
I've written about the things that I like, and that disturb me about systemd.
"First they came for the slanderers and i said nothing."
making peace with systemd, .... building Linux gaming rig
Have gnu, will travel.
New Year's Resolutions For *nix SysAdmins
After 30 years as an admin and systems programmer, finally find out what that damn asterisk stands for.
It must have been something you assimilated. . . .
Lazy system admins don't mess with things. There are always improvements to be made and testing to insure things can fail and be restored. People like you are why nobody can reboot that 10 year old Solaris box that nobody understands.
A good system admin shouldn't be afraid to break something and use the opportunity to fix it and learn something new. They should always be on the lookout for ways to smooth processes and verify documentation.
Cheap storage VM.
A good system admin shouldn't be afraid to break something and use the opportunity to fix it and learn something new.
Along with being willing to pay for a good system admin, a company has to be willing to pay for test hardware in order for IT to be successful. I've definitely worked in situations where I didn't have that, and was expected to do more with less, and then complained at bitterly when there were coughs. Sorry, kids, if you want it done right, you should pay for it to be done right. If you want it done wrong, I'll do my best.
They should always be on the lookout for ways to smooth processes and verify documentation.
And document processes — but it's easy to document your way right out of a job if your management is sufficiently short-sighted. I really enjoy writing documentation, and take some pride in it, but I'm leery of getting carried away any time it's not the point of a fixed-period contract. Even making too many templates can get you replaced with a mouse monkey. Now I know why so many design files don't have any guide lines left in them.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Basically the idea of freedom in the o.s. Is dead because we build Linux as programmers not thinking about ease of use or support, we tree and split the code base between every flavor of Linux yet the code is tied to a disbusion then we fight over every little stupid thing unless there is agreement Linux is a failure as a network admin I want a turn key system that I plug a IP address in do some basic tranning with my staff and logs everything so I can watch it as it works away addressing things as they come up and is supported by staff of the product.
I strongly disagree with his recommendation for DNS. That’s because I want to spread DNSSEC.
The problem with services like Amazon Route 53 is they generate DNS records dynamically. That means they need the signing key to be online, on the DNS load balancer, and they don’t bother to do so. If you really need your DNS to be globally distributed (How many people actually look for your domain, anyway? How many times is the answer cached on Google public DNS already?), you should look into CloudFlare. CloudFlare uses a custom implementation of ECDSA to decrease the cost of DNSSEC signatures, making it practical to do online signatures and also very effective NSEC white lies.
Have a nice time.
You seem to have zero experience with actual enterprise IT. What you say is straight from a "cloud services" ad, but it has no resemblance to what is going on in the real world, where an application has to work or 10'000 people can go for coffee. And yes, servers may still run many months at a time without reboot. For enterprise applications on server-side it is often a requirement that they can run for an unlimited time.
You also seem to have no actual system administration experience. If you install a new server, you still have to configure it and the configuration part is the major part of the work. Nobody brings up "10'000 new" servers unless they all follow a very carefully created pattern (and hence sysv-init is an advantage because of higher reliability).
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
HPC is easy: If a job is lost, you just re-schedule it. HPC is also not what most enterprise software does.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Where are these good out of work sysadmins you speak of? In the Los Angeles area, I have found exactly one (contractor). It is pushing me to need to migrate off Samba and onto Windows/AD for our office after a decade. Systemd also pushes me in that direction, as it becomes closer to a Windows type of solution anyway... just not as mature.
And before you suggest a full time sysadmin, we are a 40 person shop and there just isn't enough to justify a full time position. I would much rather pay $135-150/hour for the ~200 hours a year of work we have and let someone make a lot more money than they could as a FTE.
Nothing better than a boot process that randomly segfaults. SUPER COOL!
Thank you, that was awesome. I'm sick to death of these inexperienced self important idiots reinventing things we've had for years and then complaining when we don't worship at the altar of whatever they think is cool this week.
The most vocal opponents of systemd tend to be unprofessional system administrators and architects from an unrelated field, with decades of experience on unrelated systems.
Many of them have been responsible for configuring hundreds of thousands of systems in a non-systemd manner. The biggest variation in their system experience is usually whether they use pacman, apt, or yum. They've only dealt with one, or maybe two init systems.
These decades of experience have made them unable to consider anything different. They've come to reject anything that doesn't fit squarely in their particular interpretation of the Unix Philosophy.
Well, it turns out that it's extremely easy to mischaracterize systemd. Its architecture rejects the knee-jerk assumptions that we've used for so long. Rather than a "simple" storage backend, logs are viewed with a tool that filters down to relevant information. Systemd presents minimal interfaces to everything, intending them to be overridden with the usual system tools. It emphasizes the "do one thing and do it well" concept, where the "one thing" is "integrate programs into a coherent system". Systemd has different answers to the underlying question of "how do we turn a kernel into a productive system", that require sysadmins to work from a different perspective.
It's no wonder we see Linux distribution mailing lists and bug trackers filled with so many reports of problems caused by ignorant sysadmins. As a different approach to bringing up a system's components, when sysadmins blindly try to use their irrelevant experience and poor guesses to configure the system, things don't work.
Those poor sysadmin habits have caused a lot of inexcusable problems for a lot of their victims. We're talking about things as serious as Linux installations that don't boot properly. That's one of the worst things that can happen to a Linux installation; it renders it unusable!
Instead of taking the professional approach of understanding the new system prior to judging it, these sysadmins have blamed systemd. Many of them have, or are in the process of, spreading blatant lies and myths about systemd to distort public opinion. They just can't bring themselves to accept that a new perspective might ultimately serve their needs just as well, if not better.
You do not have a moral or legal right to do absolutely anything you want.
When do you decide to have a system managed service (for example apache) or a /etc/init.d initscript ?
No competent administrator would run something as arcane, unreliable, and fragile as systemd on a server, given any sort of choice.
Goals for 2016?: remove those last few linux boxen and migrate the services to *BSD (Open is my choice, but it does have some lag on drivers; have to brush up on writing those, I guess).
What you say is spot on and the bit about the changes in attitudes is also astute. I've made it this far down the thread while saying nothing. I probably should continue that trend but, alas, here I go...
Am I a systems administrator? Sure, I guess. Not so much now as I once was and that was quite some time ago but, today, I've got a ton of Linux installs - on desktops and servers alike. I even have remote co-lo hardware that runs Linux. I'd not /really/ call myself a sys admin but, for the sake of this conversation, I guess I might fit - even though absolutely none of what I run is important to anyone but me and a few other people who may do stuff like use my hardware for remote backups or hosting a small site.
I've tried to dislike SystemD. I really have. I mean, yeah, I love me a good hate fest and I love ranting about philosophical things like the Unix Way. Yet, I learned a few new commands (it's kind of neat to be able to check and blame things in the startup to see if you can eek out a few more milliseconds or find out what barfed and where) and I've found a few places where it comes in handy.
In other words, I've not really had any problems. Yes, I had to change a few things but I'm kind of used to that. Yes, I had to learn some new things and that's okay - I actually enjoy that part. I can still use init scripts if I want but I don't actually have any compelling reason to do so. I can even use a GUI and make stuff start on boot if I want - I can even stuff scripts in there.
So, I guess I've already made peace. I'm not saying you have to but I'm saying that my life is easier having done so. I get that the developers didn't listen to everyone but, how many users are not complaining? Keep in mind, it's the people who are unhappy that make the most noise. The people who are content say very little. They can't please everyone and make changes. I suspect that the people who don't like it are a small, but noisy, minority.
"So long and thanks for all the fish."
Lennart has poured his heart and soul into creating a solution, and you don't have the problem to go with it? You inconsiderate bastard!
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
... All you systemd haters. Flock to your precious *BSD variant, whichever you think will get more than a smidgen of server market share.
Wake me up when you can run Docker or rkt containers on any BSD. Or when there is any major outage that is attributable to systemd. Or when you can find a job at any hosting provider or IaaS vendor that doesn't require strong Linux credentials.
Just a bunch of whiny babies who spam any forum anywhere with their anti-systemd vitriol when any mention of systemd is made, no matter how tangential it may be to the discussion at hand.
Make peace or make tracks, just please shut the hell up already!
"The only good windmill is a tilted windmill."
"Without something like systemd, Linux cannot be enterprise ready."
You are a complete and utter dumbass. You don't even know how much you don't know. Why don't you actually listen to some of the greybeards, instead of shouting them down because you know better.
Do you realize how many mission critical enterprise systems run on Linux, and have since well before systemd was even thought of? You understand how massively large some of those systems are?
Pull your head out of your ass and get some perspective.
I don't hate systemd but dumbass comments like yours make me think systemd might actually be the colossal mistake that so many people are screaming it is. You jackasses think that those old greybeards have no idea how business works, what's actually important or how to do 'real' computer things. F*cking arrogant jerks.
Systemd can't even manage to bring a system up when a redundant drive has failed. Init scripts in the initramfs work around it for RAID by bringiong the raid up before systemd gets a chance to screw up. It's still just plain broken for btrfs.
For applications that have special requirements there, you want an init system that is truly modular. That is where you can just drop in replace the functionality on an as-needed basis. That implies a need for a simple and well documented API/. The APIs involved in systemd are neither simple nor well documented.
Translation, the business guy has hired cheap monkeys who turned out not to be able to handle any difficulty.
That's the problem. Anybody can captain a ship in calm seas. It just doesn't take all that much to stand at the wheel and look important if the controls are dumbed down enough. The problem is, in rough seas it takes real ability and controls that haven't been dumbed down to get through it. If the controls have been dumbed down, even the old salts can't help you.
Lift the hood on systemd sometime. Look at the bazillion twisty little config files hidden away in the lib directories. You'll be horrified.
Have a look at the hundreds of inscrutable little config files under systemd's hood and be horrified.
Somewhere in there and the thousands of lines of C code is the reason that systemd cannot handle a degraded raid or btrfs filesystem gracefully, but even the authors of systemd cannot find it for over a year.
If the init scripts have gotten that complex, it's surely self inflicted damage. Just rip it all out and go with a simple script that just does what is actually necessary.
No, he made tossing out software that scratches other people's itches over their objections so you don't have to bother with co-existing in an ecosystem a bad thing.
Nobody would mind systemd if it didn't try so hard to preclude other solutions.
Lift the hood on systemd sometime.
I'm not advocating for systemd. Just pointing out why "enterprise ready" to some extent can mean, "doesn't require any special genius to operate".
Translation, the business guy has hired cheap monkeys who turned out not to be able to handle any difficulty.
That's a really dumb translation, and shows you missed the whole point. You might get how the tech works, but you have no idea how to run things if you think the solution is to hire more expensive people. Sometimes you hire very expensive monkeys on the idea that they're brilliant and "worth it", and then they still make a mess of things. If you've actually had to do hiring, you probably know that it's very difficult to find good people, and "expensive" doesn't always mean "good".
And really, it doesn't make sense to always hire very experienced people. To keep things running well, you need a mix. You get some senior people to do the difficult stuff, and then you get some junior people to handle the stuff that no senior person is going to want to waste their time managing. And then you train the junior people as you go, which means at some point, you're going to have to hand off some of the senior work to the junior people, even if they're not 100% "ready", because sometimes that's how you learn.
It may be true that anyone can captain a ship in calm seas, but part of the goal of a business is to engineer the seas to be calm. A lot of the "old salts" get off on being the guy who heroically and astoundingly manages to patch up the Titanic before it goes down, but the business-oriented guy just wants to steer around the icebergs.
In Enterprise IT, try "cannot be migrated away" as worst case frequently encountered in practice, as there is no spec or source, the people doing it have left and the system still is needed. As to FAI, I have used it and while it is very nice for HPC clusters with mostly or fully identical configuration, I do not think it is a good approach if each system is different. You problem with Ubuntu was not Ubuntu, but shoddy system administration and documentation practices. Technology cannot fix that.
I would also suggest that while your current approach works well now, unless you very carefully document what each application needs from its container and why, you are going to run into exactly the same problem as before in 5 years.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Shell scripts are junior admin material already. To a degree, they're power user material. If your admins aren't even up to power user level then my point stands. They're not even really admins, why do you let them have root access to your boxes?
Perhaps more to the point, it's not like init scripts need to be constantly messed around with. Surely there must be an actual admin somewhere in the enterprise that can deal with it the once a year (if your enterprise is large enough) it is needed?
{U|LI}
"First they came for the slanderers and i said nothing."
You realize that I was joking - right?
It must have been something you assimilated. . . .
Nah, I'm too tired to realize
"First they came for the slanderers and i said nothing."
Shell scripts are junior admin material already. To a degree, they're power user material. If your admins aren't even up to power user level then my point stands.
Again, this is apparently just over your head. The question is not whether a theoretical smart, qualified, careful, competent person should be able to handle it. The question is whether you want to bet the future of your multimillion dollar business on the competent execution of a particular action of any single individual. The answer you'll get will often be, "not if I can avoid it." The idea is to make things as pre-built, standardized, and fool-proof as possible so that you're only relying on people to be competent as much as is absolutely unavoidably necessary.
Because if you've ever actually run anything in your life, you know that most "qualified" people are still not good at their jobs, and even those relatively rare individuals who are very good at their jobs make incredibly stupid mistakes every once in a while.
So you really do think you can design a workplace for monkeys and somehow get a decent work product out of them.
You actually do prefer something too inflexible to be fixed in the event of a problem over something that requires a minimum of competence.
Do you also hire sales people with no social skills and accountants who flunked arithmetic?
Did your lawyers pass the bar?
It is supposed to be automated, so that would be a sensible approach.
Along with being willing to pay for a good system admin, a company has to be willing to pay for test hardware in order for IT to be successful. I've definitely worked in situations where I didn't have that, and was expected to do more with less, and then complained at bitterly when there were coughs. Sorry, kids, if you want it done right, you should pay for it to be done right. If you want it done wrong, I'll do my best.
They should always be on the lookout for ways to smooth processes and verify documentation.
And document processes — but it's easy to document your way right out of a job if your management is sufficiently short-sighted. I really enjoy writing documentation, and take some pride in it, but I'm leery of getting carried away any time it's not the point of a fixed-period contract. Even making too many templates can get you replaced with a mouse monkey. Now I know why so many design files don't have any guide lines left in them.
This there is the true reason why so called "old sysadmins" despise systemd so much: it makes everything much more simpler and faster to do correctly, and allows them to be replaced far more easily by less paid individuals.
I never thought of that, but now it's clear. Because true sysadmins could never say so many absurdities about systemd if they really tried it.
Though I think these syadmins are thinking to much into this, you still need to be a competent sysadmin to manage systemd, the countless clueless mistakes made by very bad old sysadmins (if even you can call them that sometimes) seen in bug reports are there to prove it.
I'm not worrying at all. Systems were impossible to manage correctly with initscripts, one bad sysadmin could destroy everything or compromise the security of your boxes without you seeing anything, I've seen that countless times.
If you are arguing for systemd, have you ever tried using inittab or customizing runlevels? It is powerful and demanding, but not impossible. As a core *ix paradigm it forces you to skill up to the next level of mastery over your systems and understand how your processes behave.
systemd seems to abstract away that knowledge of how processes behave, like wishing for less challenges instead of more skills.
Do you realize that every single one of the anti-systemd crowd is not advocating what you are talking about (really using init), but the crazy crappy way with symlinks and everything used by every distro that used sysvinit?
You're right of course, but what you describe is roughly the same work that has to be done with systemd: trimming these insecure faulty initscripts to one invocation line.
Sometimes it's not possible and requires a shell script, but the work is the same with systemd and truly using sysvinit.
But sysvinit is really too limited compared to systemd, and would need lots of shell scripts to work properly, just to bott a Linux system, and most importantly, sysvinit needs a competent sysadmin custom configuring it.
Have a look at the hundreds of inscrutable little config files under systemd's hood and be horrified.
Not if you are used to the hundred of big initscripts under /etc . I know I never was intimidated by systemd config files.
Somewhere in there and the thousands of lines of C code is the reason that systemd cannot handle a degraded raid or btrfs filesystem gracefully, but even the authors of systemd cannot find it for over a year.
You are wrong, the problem lies in the Linux kernel and btrfs implementation, the developers explained this long ago, but you're too computer illiterate to understand the explanations given by developers. You surely didn't understand that systemd by default won't use a policy that can lead to data loss, no matter how loud you yell at it. And these problems are partly policy problems, managed everywhere (even with hardware RAID) by daemons or services, that won't let you boot by default, you have to configure them to do it.
If the init scripts have gotten that complex, it's surely self inflicted damage. Just rip it all out and go with a simple script that just does what is actually necessary.
"Just do it" is the answer of clueless people that have no experience or knowledge of what they're talking about, especially when they're saying this to people with lot more experience, like distro sysadmins.
Initscripts are inherently broken in a dynamic environment, just starting with race conditions.
I am quite familiar with the scripts under /etc/init.d. The bazillion config files for systemd aren't intimidating, they're horrifying. They actually use "come from" (a popular programming language joke) style logic! I don't just mean the ones under /etc, I mean the ones under /lib (under the rug?).
The kernel and btrfs work just fine when systemd isn't there to muck it up. I tested that by setting up a system under sysV, testing, and then under systemd. The sysV system booted up fine in degraded mode (after I specified that I wanted that behavior). The systemd system refused to boot in degraded mode in spite of me specifying that I wanted degraded mode when necessary.
System tools are supposed to provide the mechanism to enforce the admin's policy. They are not to dictate policy to the admin.
Backups are supposed to prevent data loss. RAID either hard, soft, or implemented within the filesystem is helpful there but the primary purpose is to improve the machine's availability. Sitting at an emergency shell prompt in the initramfs is anathema to availability. The correct behavior is often mount it anyway and email the admins. If my policy for the server is that it shouldn't mount the degraded volume, I can certainly do that with or without systemd. If it should mount the volume anyway, I can only do it without systemd.
I doubt you want to use your experience in a dick measuring contest here. Just do it is also sometimes used by people good enough to actually just sit down and do it.
While I do recognize that sysV is limited in a dynamic setup, I also recognize that whatever the real solution is, systemd will hinder it's development and actively fight it's implementation through tightly coupled dependencies, poor documentation, and unstable APIs If the systemd project would put up real walls between "moduiles" such that it becomes truly modular and drop it's all things to everyone but it's our way or the highway attitude, parts of it might actually figure in the solution. It really needs to get divorced from freedesktop.org.
Do you realize that every single one of the anti-systemd crowd is not advocating what you are talking about (really using init), but the crazy crappy way with symlinks and everything used by every distro that used sysvinit?
Which was *Red Hat's* idea. No, I didn't.
Red Hat layered that crappy rc system over the original, effective and very simple way init implemented things. Now you're telling me that this is the justification for systemd! Such irony, I can't see their second being any better.
It's a shame, init is one of the purest O.S paradigms there is, it really shows the genius of the people who designed UNIX and C in the first place. Simple elegance.
You're right of course, but what you describe is roughly the same work that has to be done with systemd: trimming these insecure faulty initscripts to one invocation line.
In systemd implementations the unit files will use those init scripts. People usually learn the minimum they can get away with and make do from there.
Sometimes it's not possible and requires a shell script, but the work is the same with systemd and truly using sysvinit.
So the point is?
Go back to init and see what it *can* do. It's simplicity makes it extremely flexible for a large amount of boot conditions. I doubt you have a use case it can't satisfy.
But sysvinit is really too limited compared to systemd, and would need lots of shell scripts to work properly, just to bott a Linux system,
How so? Be extremely specific please.
and most importantly, sysvinit needs a competent sysadmin custom configuring it.
What sort of argument for systemd is that? That you don't have to be competent to configure it or that it is necessary to dumb down an elegant, simple, powerful, flexible paradigm for a bloated one so that you understand it?
My ism, it's full of beliefs.