I think you are underestimating your relative skill level. I know some system admins who are capable of that, but the vast majority seem not to be. I would guess you are in the top 10% if not the top 2% in terms of skill level. I see your point that writing init scrips is hard, and systemd will reduce problems from less-competent init writers.
My point is that only the people with as much experience (not even skill, just experience) are able to even understand the issues.
Yeah, recently is that the systemd argument has started drawing some very skilled people in to discuss what a good init system would look like. Here's one example. And of course, you've commented in some of the discussions in my journal, and I would like to think they are the work of a very skilled person too:)
I actually appreciate these because they are from people that really understand what they're talking about, it's refreshing.
One thing I've noticed is that people who favor systemd almost all favor the features of systemd. Those who oppose systemd almost all oppose because of architectural reasons, or implementation details. So theoretically both sides could come together if an architecturally sound init system were created with features people need.
I agree with this, my problem with a lot of opponents to systemd is not the fact that they have a different opinion, it's just two things : - most of the time they don't understand what they're talking about and are just following a trend; - those that are knowledgeable don't make enough serious work done to make a valuable competition to systemd;
The worse thing is that I understand the genuine flaws the knowledgeable people are talking about. They are trade-offs I think the systemd devs are well aware of. I find them acceptable, the others find them not acceptable. We're in the exact same situation of Linux vs Minix or GNU Hurd, XFree86 vs the rest, DBUS vs other IPC tools... Some people got the work done, it's not perfect, but it allows to make a useful implementation that can be improved later. Other people have legitimate complaints, but are not doing any serious work, or let go when they realize that their high standards implementation would require 10 times more work to make sth useful. It's the real life world we live in. Most of the anti systemd people don't realize that the problems systemd tries to solve, knowledgeable people have tried to solve them inadequately since 2 decades if not more. And some problems kept getting in, like the dynamic nature of the Linux kernel, which in itself caused a lot of shitstorms with devfs and the like before udev settled. These were the most painful migrations due to Linux kernel changes I ever had to do on my own made systems, and distributions maintainers must have been at huge pain since then. Separation of mechanism and policy is a good thing, but the problem is that a distribution HAS a policy to withstand, which made the mess of hugely incompatible init, which in itself is not a problems for distributions, but one from upstream projects. Systemd tackled lots of problems like these, it made some kernel Linux features prominent and simple to use (features that were rarely used before, and still not used in other init systems), improving the kernel by showing buggy, insecure or inadequate features (of course, as nobody used them, nobody noticed), some of them being huge problems for years (like mtab handling). For all that and more things (like improved security by default) that have nothing to do with systemd features, I thank the systemd devs. That busybox removed support for the journal is not really a problem though, as if systemd is used with a busybox system (that's what I do in my LiveCD), the busybox syslog is not even used, there was no point in doing that.
Since SystemD provides Sys V init, and backwards compatability, the criticism of systemd is a bit overblown as people can simply use system v init features on systemd if they want.
Most of the problems with systemd are migration problems, and most of them come from teh sysv compatibility layer.
The integration of cron, syslog and init was important for being able to launch a service dependant based on say another cron event occuring. There are better ways to do this however using a decentralized model using well defined IPC bus interfaces and protocols allowing for the functionalities to be in seperate processes but allowing processes to communicate with each other, and each a user swappable components as I will describe later. There is no need to have one big monolithic process or poorly understood components which are not swappable and do not communicate using well understood and documented protocols that can facilitate users swapping out components.
Does not compute: what you propose is what systemd is doing with DBUS. It's a so well understood IPC that KDE and Gnome flocked to it as soon as they could.
I doubt that systemd would be as big of a controversy as it is if the additional functionality was added but not heavily used all over the place for most of the services on the system and the distribution had not felt the need to convert every single service to the new type of init file. Its sort of like people who think they have to use every single C++ feature when C++ is not intended for that, its a bag of tools where the programmer is supposed to choose the tool they need, rather than something where the programmer is supposed to use every single last tool. Instead, the distributions who adopted it felt the need to convert most services over to the new init file format. This created a very much so in your face kind of obtrusiveness that was easily noticeable by many.
You're wrong, that's why you don't understand. People used the features because they were useful, and sometimes asked for for years, but only systemd devs took the challenge. It's not a case using every single tool, it's a case of using shitty tools for years and feeling pain, and as soon as sth far better arrives, everyone jumps on it. You just show that you have no clue about the countless improvements systemd brings. And also, systemd works far better with its native unit files, than with the compatibility layer for mostly badly written, abused or inherently racy and insecure init scripts.
It was unnecessary in many cases as dependancy based startups can stil even be triggered from System V style initializations. Since systemd supports SysV startup, the majority of init files could have been left in SysV format which would have avoided much controversy. Another possibility is to offer init files in both the old and new formats so people can choose which one they desire.
No you're wrong, you have clearly no experience of these things. As I said, init scripts are inherently flawed, and no, you can't do dependancy based startups with init scripts. Lots of people have tried though, it lead to all sort of horrible flawed init scripts that usually don't work at all and can crash your server.
I believe in a mechanism not policy approach. Systemd's own model of dependancy init are useful in some cases however, are probably overkill for other services. The features should be there for those cases that people may need to use them. Systemd does allow users to the flexibility to use sysV init so the fact is for starting your services you can always have the started from sysV scripts even on Systemd. Ive done it and works fine.
No it doesn't work fine, at best it's a useless wrapper that have no purpose, but most of the time it adds flaws and bugs or try to hide flaws and bugs. Your daemons should not need any shell script to run. Sysvnit doesn't need init scri
Why has nobody written a tool to view the binary log? Just 'cause it's binary doesn't mean that it can't be done - does it? I'd think that someone would do this. Maybe I'm missing something here but this doesn't seem insurmountable. If I gotta do it myself then, well... You don't want that.
Somebody has already done that, though not sth as stupid ad reading the files. The reason you're not aware of this is because you listen to the clueless anti systemd people. rsyslog reads from the journal since months, there is just no validity to the complaints of people about the journal, as you can constrain it to memory if you want (stupid thing to do IMO) and have only your "text" (but not really) files if you want. And journalctl reads the "binary" logs (which are mostly text actually, unless compressed) already. You'll be better off listening to proponent of systemd if you want to go anywhere, instead of the countless FUD and BS spouted by anti systemd people. Most of the time they are repeating completely false arguments or things that are wrong for years.
ffs, init was 20k LOC systemd is now 100+ bins and 430k LOC.
These are not the same thing at all. These systemd LOC replaces init plus countless more daemons and Unix standard tools that you had to use in order to even boot to a usable shell. The tools that made some boot firmware larger and lead to things like busybox.
Before systemd you had a log file that was text and parsable using the commands that are core to unix (or specialized applications/services to injest them later), after systemd you have a binary log that mind you has code controlling it that can choose to destroy that log if it finds it is unreadable or corrupted.
What you say is just clueless FUD. After systemd, you still have the exact same log file available (which are not always text) with even more useful and accurate information than before systemd. At least I know I do still have them, better than before, because now I actually have the log with the complete kernel logs, which I never had before systemd, not even with the kludge of using dmesg. I wonder what destroying corrupted or unreadable means, but sure enough systemd do nothing of this kind. The corrupted log is still there, it's just not displayed to you by default, but if reading corrupted or unreadable log is your (nonsense) thing, you can still do it with the journal.
Init was special purpose and streamlined to do one task well, systemd is coupled to auth, dbus, vm startup and shutdown, vm management, privilege escalation,....
What is your point, nothing is mutually exclusive in that...
No one is complaining about the features of systemd, everyone is complaining about the design of those features that is reminiscent of MS architecture and design (that even MS has started to run away from). Poettering has stood in front of rooms full of people and flatly said he does not care about posix or unix he wants to build something new. He is -- hes building a monolithic userspace kernel and RH is using the init functionality to shoehorn itself into a controlling position.
You don't make any sense. What is a userspace kernel? Who is this everyone you're talking about? It sure enough is not "everyone" in the sense used by sane people. What is reminiscent of MS architecture in systemd? Systemd is using specific Linux features which were not widely used at all by anybody, what is so reminiscent of MS architecture in Linux? You people say stupid things without ever any specific example to make your point, you just sound like crazy people that don't know what they're talking about. But that's why your an ignorant AC.
Because of the way systemd/XDG/pam/dbus are designed, the more he extends it the more other core bins on the system will need to integrate with it or rebuild functionality that has been displaced by it for no reason. It is a loss lead development and it will me Linux's loss in the long term.
Nah, I said it wrong. I should have said, "Systemd makes things easier for people who write init scripts for distros."
Not only in distros actually, but also for upstream projects that distribute init configurations. And usually distro init script writers are far better than most admins (and commercial software vendors script writers) out there that don't even understand how to write shell scripts. I've encountered countless horrors everywhere, and as early as I'm authorized, I reimplement most init scripts, and it's not true only on Linux, but even on AIX, Solaris and HP-UX (back in the day). I do that since 15+ years. I'm sure most seasoned sysadmins do the same as soon as they encounter one init script bug that breaks their OS. Someone actually documented there some of the things people that don't understand anything about init scripts, shell scripts or systemd actually do. That's the kind of horrors I see every time. You don't even want to start thinking about the security implications of such things, especially since those people usually put setuid bits everywhere when their mess does'nt work. Just like PulseAudio forced sanitizing lots of ALSA drivers, I guess systemd will at least force sanitizing init environments and weed out all these nonsense. At least I can hope.
In the end, I've concluded, I just doesn't seem to matter to me - yet. It doesn't really impact me. I'm sure that it does others but, for me, it just works. I want to hate it. I want to be in the cool crowd and rage against the evils of the domineering Red Hat and crew... I want to be enraged enough to key cars, throw bricks through windows, or at least post vile, spittle speckled, angry posts on the internet but it just hasn't bit me yet. Maybe when it does? I'll start my brick collection, just in case.
Seriously, thank you, your post is one of the best I've read on Slashdot, especially because you cite the ONLY really good (blog) post describing systemd problems I've ever read. As the author note, not a single systemd opponent can articulate any specific problem in systemd, just general things that they attribute to systemd but can't understand. This blog post is genuinely good, and from someone that actually understand what he's talking about (he's at least read some of the code in systemd). The flaws of systemd are clearly explained, and even I being a pro systemd person, can agree completely with everything written there. This is an essential read for any systemd proponent or opponent actually. What it shows, is that you can do better than systemd, because systemd devs took the practical way, not the high standard one. Basically, it's like systemd were Linux, and the alternative must be like Minix (or GNU Hurd), that's how I'd summarize what is written in the blog post. Most of the flaws described in the post are shortcuts chosen by the devs (and the systemd devs are aware of them), just like Linus did with Linux, so as to provide an implementation in a reasonable amount of time. Now, if you look at the state of Linux and the state of Minix or the Hurd, I personnally agree with the choice made by the systemd devs. The competition just now has to start implementing and proposing their high standard alternative to systemd and stop the complaining that doesn't help anyone. Some have started (s6 with OpenRC might lead to sth), but nothing usable is available yet. Instead, there's lots of red herring and bad mouthing systemd by the competition, making them losing their time in useless discussions. Things like "systemd didn't invent socket activation, it's not even really socket activation" (hint: we don't care, the functionality is provided and advertised, when it wasn't before, or the projects like inetd and xinetd went abandoned), "systemd didn't invent cgroups, you can use them with scripts" (hint: we don't care, nobody used them with sysvinit, and systemd uses them by default), "you can jail your processes without systemd" (hint: this is laughable, as it was so complicated to do, and even more to do right in shell scripts, that it was never done, or always done wrong, and wrong feeling of security is worse than no security),...
> Mind you few people will ever say a system is easier if that system > is new and requires them to read a man page. Change is never easy.
Many people change when the new tool is better, even if it requires learning new ways of doing things. Many new and improved tools make a serious effort at backwards-compatiblity to make the transition easier (systemd does not do this). That's why, for example, many people switched from syslogd to rsyslog or syslog-ng. why many changed from ncsa or cern httpd to apache. why many changed from csh to posix sh (or bash or ksh or zsh). Many of these people who have gone through all these changes and more are the same people complaining about systemd, so their objection is clearly not because they are afraid of or too lazy to change.
No, you're wrong, the people you're talking about all made the change to systemd. And I'm one of them. That's why most Linux distros switched to systemd BTW, you know, the same ones that switched from syslog to rsyslog or syslog-ng. The people complaining about systemd are a minority that are on Devuan or fled to BSD by their own admission. I know I'm never looking back to sysvinit, but then again, I started avoiding sysvinit 15+ years ago, and yet, I'm one of the most proficient admins with it. The knowledge of the braindead sysvinit by most sysadmins is actually abysmal.
You are demonstrating the biggest advantage and the biggest downsides to Linux at the same time. The rich and widely available different ways to administer the system, and the self important douchbags in the community who believe their way is the one true way (tm).
You're wrong on this one. If you need a graphical tool to administer your system, you clearly are not meant for sysadmin work. Most of the time, graphical tools like gedit aren't even usable (like on a constantly changing file) or available.
I've never heard a server administrator say systemd makes things easier for them. There are probably some server administrators somewhere who will claim that.
Systemd makes things easier for people who write init scripts. Init script writers are the people who have primarily been responsible for its adoption in various distros.
Your problem is right there: init scripts writers are server administrators, even the most seasoned one. That's why you never heard a server administrator say systemd is easier, that's because you can't recognise one when you see one.
The decision to drop stderr has made my life hell. I wish systemd guys understood how important it is to those of us that run servers.
stderr and stdout were dropped by sysvinit initscripts. Systemd upstream logs everything to the journal by default : syslog, stdout and stderr. So it's far better than initscripts ever whereby default.
No advantage as far as I can see compared to syslog and the ordinary text tools. Just a way to force the use of binary file processing tools and as soon as something pukes in the binary file it may be completely unreadable. A text file might not look good after a puke but it's still mostly readable.
No, actually, that causes no problem at all, the systemd journal even used to store core files, without any problem. It doesn't anymore though. There are lots of advantages, but if you can't see them right away, you're hopeless, or don't really work as a sysadmin. Just the fact that you can easily list all the logs between two dates for a specific service is sth that takes time and programming an awk script to manage for a seasoned sysadmin (or a tailor made shell script with lots of LOC), that won't even work with every syslog daemon.
Having a file residing in plain text vs having plain text piped to another program is a pretty significant difference. You can't seek around piped input, unless you cache it memory -- which could be resource-consuming. (And maybe your tool for reading piped input is broken because of shared library problems). Being able to read a resting file in plain text is very important in recovery situations.
What you say is clueless at best. If you want to seek around a plain text file, you have to load it in memory, which is far more resource consuming than journalctl searching the text file, and resource consumption gets worse with the bigger log files. That's one of the point of tools like more and less, and even that will consume more resources than a search with journalctl. And your example is nonsense, as in recovery situations, especially when you have shared library problems, you sure enough are not reading log files, but recovering your system. The log file reading to understand what went wrong comes AFTER having recovered. You don't read log files while your system is broken with shared library problems, you people are incompetent fools, I don't want any of you near any of my systems, be they sysvinit or systemd or anything else. And such disaster recoveries work far better and smoother with systemd than ever could with sysvinit. One readline library problem with your readline enabled bash, and most of Linux initscripts are dead. Even with a specialized shell (dash is a PITA in itself anyway, abandoned it years ago). My systemd went on without problem though.
No. Programmers proficient in bash can understand. Don't use "One" to describe every IT person out there. There are countless people who would much rather remember a couple of keywords then sift through effectively source code and a whole load of environmental variables to figure out how a program starts.
I also find it funny that Linux people of all the people complain about having to remember a few hardcoded keywords.
I agree with you, and don't mistake these people with Linux people. Most of them by their own admission on Slashdot, moved to OpenBSD or FreeBSD to avoid systemd. I'm pretty good at shell scripting, and yet, I still prefer systemd units compared to initscripts. Initscripts are a security knightmare, most admins I've worked with don't even understand them at all, most people don't understand why Red Hat implemented service, and even "service" doesn't solve every initscripts problems. All this tedious work to make initscripts work in distributions has been done by the same true sysadmins that want to move to systemd. Every people that understand shell scripting looking at initscripts and their tons of LOC (still full of racy behaviour and bugs) that required years of work and bug reports can't seriously say that it's better than systemd units. Yet, that's what is cited as an argument for sysvinit.
I cannot wait until the first time you discover that systemd's startup is nondeterministic and your carefully tested system somehow fails to come up to reboot after a power failure because, while it worked when you were testing it, systemd decided to do things slightly differently when it mattered and BOOM everything fails.
init.d scripts may be sightly slower, but you can be 100% sure that the system will boot the same way every time.
No, you can't be 100% sure of anything with init.d, you must be new to sysadmin. Stop saying clueless things like that, you'll fool the new sysadmins there. Systemd is far more reliable than initscripts for booting the more complicated your environment is, and it's on another planet as to dynamically restarting services or plumbing like network change.
So you are saying that you should rely on one system (systemd) to monitor and see that services are up correctly instead of using a real monitoring system?
With init-scripts and 3'rd party monitoring system 1. Boot 2. Verify that all services have started and are working correctly.
With systemd and 3'rd party monitoring system 1. Boot 2. Verify that all services have started and are working correctly.
The only difference between the two is possibly cutting down a few seconds in boot-time, and cutting down 5-10 seconds on a server-boot that is 60-120 seconds does not really matter that much..
In what you've written, there are no differences, but that's because you missed a lot of systemd features, and added a 3rd party monitoring system for systemd where you don't need any to monitor daemon startups (but you need it for the working correctly part). Mostly, the log problem is a huge one that you have with initscripts, be it logs on stdout or kernel logs that you may have lost. And yes, the purpose of init is to monitor services and see that they're up like you configured them to.
Second part to the whole thing, when going with systemd and you want to wait for a database to be up and responding before continuing on with the rest of the system is not only tricky but will require you to reorganize the dependencies for so many parts in the system. With init-scripts it would be a simple addon.. Add a simple Swaitforstuff that would handle it in a easily way..
Are you new to sysadmin? What you say is funny in how naive it is. These racy kludges you describe are what was done in initscripts for many databases, easily broken and insecure kludges at that, that didn't support sudden shutdown or any unexpected behaviour. Just because most init can't handle it. With systemd, for mariadb/mysql, there is nothing complicated to do. To be sure the service is started, I just added this line in the mysql service: ExecStartPost =/bin/sh -c 'until $(REPONSE=$(mysqladmin ping 2>&1) ; RET=$? ; fgrep -q "Access denied" <<<"$REPONSE" || [ $RET -eq 1 -o $RET -eq 11 ]) ; do sleep 1 ; done' That's because databases daemon are such pains, but there's no complicated dependencies nonsense like you describe, and yes, systemd allows you to launch shell scripts too. When mysql.service finishes, I'm then sure the daemon is at least accepting requests, and if not, there's a problem and I will see it in starting mode, and can kill it and investigate.
If you now are thinking about using a wapper-script.. So each and every daemon that i want to start would need to be modified with what it should depend on.... And what happens with the process-monitoring when using scripts? (exit codes from the wait-script or from the daemon..)
As soon as you try to do anything that's just a little on the edge on how the systemd people are thinking it gets complex quite fast..
No it doesn't, it's pretty simple, faster than writing tons of complicated, racy, insecure and buggy scripts.
Most of the systemd features could be implemented via a generic script-base (that could include support for older init-scripts) and at the same time adding a few new smaller daemons that would enable most of the features systemd does..
You don't know what you're talking about here. I used to do that with tailor made shell scripts for every server, but it's not viable when you have lots of systems to maintain, and you just showed some of the flaws with sysvinit. Most distributions used lots of helper binaries, none compatible, every one in a different code base, with their lot of bugs, insecure code, and such. You describe the mess that was before systemd, and one of the reasons every distribution jumped to systemd. Now, all this maintenance is in one place, have to be audited in one place. And it works better than any other distro specific implement
The logical follow up question is why does upower depend on systemd?
The team decided they didn't want to duplicate support for suspend/hibernate when there's already a tool which does so. At the same time they released a solution for those people without systemd:
[...]
So what exactly is the problem? Why exactly is systemd so evil because someone else doesn't want to maintain a certain effort they are doing and instead hand off to another package, while even providing a compatibility option for the anti-systemd crowd?
There is no problem here, and never was, it's just that like any good sysadmin would do, you've made your research as to why the change occurred. The one complaining never did any reasearch and never was affected at all by systemd, he just wanted to complain about sth he didn't understand just because. Most systemd opponents sound like this, as haters that don't understand what they're talking about, wanting to put the blame on systemd for doing the right thing, and people more knowledgeable than them (like MATE or Upower devs) taking advantage of it. The problem is that systemd is so more advanced than its competition, that it seems like the competition doesn't do anything about its manby problems, and is already years behind systemd. The systemd which is improving on a daily basis BTW.
I think the issue isn't that MATE depends on upower, rather that the latest version of upower depends on systemd.
What is the issue there? You didn't tell. Actually, unless you maintain any of the thing you complain about, which obviously you don't, you have no issue at all. You're just complaining without understanding why. Latest MATE depending on latest upower is a problem with the MATE developers, you don't even understand why that's the case, and I'm sure there's a reason other than just to be up to date. I'm pretty sure that's because older upower was broken in some ways. Which then leads to upower. Latest upower depends on systemd (if you choose so, perhaps it's optional), because some cases were just broken (or insecure) with other init systems. Again, you don't even understand why upower devs chose to depend on systemd, but you complain and see this as an issue, an issue that you can't even describe.
Perhaps MATE should not have required the latest version of upower, but that passes the problem to the MATE team rather than placing the problem where it belongs, which is with the systemd team.
So you move the "problem" because if we placed it where it should, you couldn't blame systemd. OK. Don't worry, it was obvious from the start you had no problem, and was just willing to bitch about systemd, just because.
As another poster has identifies, the problem seems to be that the systemd people aren't coding to interfaces. If they were, then dependencies wouldn't be on specific code, i.e. the implementations.
Upgrading software shouldn't require a change to the init system.
None of that is your problem, that's the distribution problem, you have exactly zero thing to do, except let the distribution replace your init with systemd, which makes no difference to you as your biggest concern is moving to the latest MATE desktop. Your distribution is telling you that if you want the latest MATE, you need systemd, but instead of complaining to your distribution, you want to complain to systemd devs, go figure.
> If you are a system administrator and you can't handle with systemd, then you should consider change job!
You sir, are a moron. Sysadmins are the janitors of computing. You do not expect them to be terribly bright. You expect them to be diligent. You don't expect them to be great programmers.
Thank you for dissing sysadmins like me. I agree with this person, a sysadmin that can't handle systemd is not worth anything. Now, explain to me why systemd opponents claim shell scripts (programming language, you know?) are better than configuration files (systemd units). Systemd opponents contradict themselves every time, when not plain insulting themselves and others.
Otherwise they would be doing that job instead.
You don't know what you're talking about, sysadmins use the Shell (KSH, Bash,...) a lot.
Once you get away from startups and before you get to "Cloud providers" you have most of the industry that follows Sturgeons Law.
If you make something "too difficult", the CxO class will find some other product to use. They might even buy the propaganda from that other guy about how "they build things to be easy".
They won't fire their "lame sysadmins", they will fire you Red Hat.
Some FUD and wishful thinking there, you people have no shame, and can't be taken seriously.
What SystemD is doing is a good idea, it's how they're doing it and their attitude. They seem to have the mindset of Devs and not sysadmins. Windows is an example of an OS by Devs. It's death by a thousand cuts. You can't quite pout you finger on exactly what is wrong, but there's a whole lot of small issues that amass into some real annoying rare cases that don't affect most users, but should never happen in the first place.
Please provide at least one example. What you say is just an opinion by someone who, from my point of view of 20+ years of Unix administration, doesn't understand anything of what he's talking about and is spouting BS he read somewhere else. The small issues amassing in real annoying rare cases are sth that always existed on any OS, but you seem to say only systemd is causing that. So what you're saying is clearly BS.
LaunchD has existed for a long time and is fully opensource and well tested. It has gotten the run-through with iOS which needs to be easy to use and work reliably in some very complicated environments, like cell phones. Of course there is the very strong "not invented here" mindset that a lot of GPL people have.
You don't even understand the GPL and what it's for, so your case is getting even worse. You sound like a proprietary software shill, not like someone who understands Linux, and therefore not as someone legitimate to talk about systemd. FYI, launchd is one of the init that have been studied before making systemd. Studied by people that actually understood the GPL, Unix (BSD and System V), and Linux. At least far better than you ever could.
Comparing SystemD to LaunchD is like comparing btrfs to ZFS. The most annoying mind-set that I've seen from the SystemD people is the whole "if everything is working as expected, this situation should never happen, so we may as well not handle this situation". How I hate that. If you know about a failure case, handle it! I hate that "limp along and some time later, fail in some unrelated way that gives the wrong impression". Works great when it works, but the failure cases are a mess.
Oh my god! Thankfully you don't do systemd administration. FYI, the kernel works just like that! Systemd is tailored for Linux, and it shares lots of its design. If your memory is physically malfunctioning and corrupted, the kernel (and systemd) is choosing to not do anything about it, and not handle it, because they decided they can't, and prefer launching a kernel panic (or a systemd halt)! That you hate that just means you hate Linux and systemd, but some people like me find this a legitimate and sensible choice and will continue to use both.
Did you know that both LaunchD and ZFS had numerous old-school Unix people working on them in all stages of development?
Did you know there was a problem with the licences of both and the GPL? Did you know that LaunchD and ZFS were not made for Linux?
These are people who grew up using and managing mainframes and many now make a living managing datacenters. Who would you rather having designing the critical infrastructure of your OS. A sysadmin dev hybrid programmer who grew up learning exactly why things are designed the way they are, or some wide-eyed dev who likes flashy things and assumes the wisdom of a sysadmin is just the rantings of some old person?
In the case of a free GPL OS like Linux, I would not want any of these sysadmins touching Linux infrastructure at all. People trained in proprietary buggy Unix OS, no thanks! People that couldn't to this day do better than the GNU OS? No thanks! Now, if the sysadmin dev hybrid programmer who grew up learning exactly why things are designed the way they are was actually working on Linux, yes of course I would chose this one. Oh wait, that's exactly who Lennart Poettering (the one that launched systemd) is!
Mind you, I'm a fairly young person that loves flashy things, plays AAA video games, and watches anime, not some neck-beard.
Don't worry, it shows in what you've written. Fortunately, the one developing systemd and Linux are not like you.
Sorry, if you need systemd to execute the kill -9 on an unresponsive java application you really shouldn't work in this field. All our java apps get a chance to shut down gracefully and get killed if the don't do it in time. That is ONE generic script dropped in any java deamons bin folder. Doesn't even need customization like the startup scripts. Btw systemd also got the job done on database shutdowns with lots of dirty pages wrecking the database. One solution doesn't fit all and that is what systemd is doing.
So you're saying that your init system can't do the job, so you had to make one custom script to handle it. I say you shouldn't work in this field then, as systemd is doing better than your custom script by design and by default, first killing your processes, letting them some (configurable) time to stop, and then only doing kill -9 on the rogue processes. Your system will be better off with one standard init doing its job correctly, instead of the mess of customized systems that was caused by sysvinit.
Some people have so many problems with systemd, because it invades every part of the system and 'solves' one problem by breaking lots of other stuff. The power of unix systems was that if you run into problems you can easily fix them. Systemd makes a lot of assumptions that might or might not fit to your problem and forces them down your throat. And the instant kill of services was one of these bad decisions they had to backpaddle on.
Here comes the FUD! I don't even remember systemd ever instant killing services. The killing process is entirely configurable, so you're mixing things up there, surely because you don't understand anything about it. It's explained in systemd.kill man page. The only thing that systemd revealed, is the amount of people doing system administration without understanding anything about what they were doing. These people then were all stuck when migrating to systemd, because they have no clue as to how to migrate all their customs scripts and helpers for dodging sysvinit flaws, scattered around their systems. Systemd being more serious about security, all these security holes in the system don't even work anymore. Your script is just an example of these nonsense.
Breaking network boot by stripping search and domain from DHCP another. At least the idea to kill your current ssh connection on a system update kept being an idea.
Systemd didn't break any network boot because it wasn't stripping any search and domain from DHCP. Only the specific systemd implementation did that at first because it wasn't implemented, it was documented, and noone therefore forced you to use the systemd implementation. Only someone not understanding what they were doing would have done such a stupid thing as replace their DHCP client with another lacking the features he needed.
Also tons of experience with RedHat is like tons of experience with Windows. Just because you know the limitations doesn't mean that you need to live with. them. And there is a big difference in patching a script compared to applying a patch to systemd.
Systemd needs to stop implementing feature requests without thinking them over.
Yet you chose to live with sysvinit limitations, go figure! The equivalent of patching a script is not to patch systemd, but just to modify some unit file. Systemd doesn't need to stop implementing requests (there's already a big filter on what is accepted upstream), as these requests are optional services, and come from legitimate admin demands, that people like you complain systemd devs don't listen to.
Systemd needs to a let another software monitor daemon statuses, Daemon states can be much more complex than they account for and there is specialized software around that doesn't mind sending systemd the restart command. In short systemd needs to focus.
systemd does things like auto-detect all of the tty devices, and automatically associate them with login prompts when the device becomes active. This sounds good, until you hit an application where the tty device should not have a login prompt. After two days of trying to work around the issue (there is a work around), I now understand what everyone was complaining about...
Actually, you don't understand anything. Systemd doesn't detect any tty devices, the Linux kernel is doing that, systemd just associates an action to dynamic appearance or disappearance of some devices, that are configured by upstream, your distribution, or yourself. If you login to a tty, and then this tty is supposed to be used by another application because it was configured like that, that means a conflict, and so a misconfiguration by your distribution or yourself. In all cases the conflict is logged by systemd as an error. So the end result is that you had a system misconfigured. What I don't understand, is why it took you two days to see the error message when journald will show it to you right away.
The biggest issue is that everything is wrapped in layers of configuration scripts, and this makes it is difficult to do something specific. The distros in an effort to "make everything easier" then have their own distro-specific scripts, and this makes the problems even worse.
The old way had one configuration script per activity, and this had the advantage that you only had to worry about one script.
Systemd doesn't wrap anything in layers of scripts, one of its goals is removing these layers instead. Distributions actually add layers of configuration files out of habit of sysvinit, where you could have configurations scattered in more than 5 different files. If you apply systemd style, configuration is just in one place, either the daemon configuration files, or in systemd if it's about the system plumbing.
Actually, I'm not a fan of systemd, but as a system programmer/administrator with 30 years of experience on just about every type of Unix system from PCs to Crays, I've seen a lot of good and bad things. With every change -- especially forced change -- comes griping - some valid, some not. I'm sure I'm not as much of an expert on this particular issue as others here, based on some of the posts, but I am trying to be optimistic. The idea of systemd (or some/much of it anyway) seems good (the Solaris Service Manager doesn't suck), but I think the implementation suffers, especially from not being well or completely thought out, being a bit over-reaching and developed by people with larger than deserved egos who are unwilling to compromise and/or accept or act on constructive criticism - some of that also from people with ego problems.
I just imagine if people worked together, things could be a lot better.
You have all these wrong impressions because you never actually read the systemd ML, but instead basing your knowledge on trolls. You would then see that you're really in the wrong here.
Agreed and I would add switching systemd to PID 2 and make a very simple init process as PID 1.
But that's how systemd works already: the minimum is put into PID 1, eveything else is separate helper daemons.
Actually, I'm hoping that the developers will get their heads out of their asses and listen to the people actually using their product, but Kay and Lennart apparently are mediocre programmers that don't play well with others, but have, for some reason, been allowed to play w/o adult supervision.
Just read the ML instead of saying nonsense, or rather don't, or you'd see how shameful your comments are. systemd introduced lots of functionality asked for by the sysadmins, from distros or not. The feature "creep" people talk about are actually not coming all from Lennart and Kay, but are useful optional additions asked for by the users (sysadmins, distro maintainers).
What nobody's explained to me is why, if systemd is as bad as most people on Slashdot think it is, why is it in so many distros?
It has been explained several times already, you just didn't pay attention or didn't understand the problem, which is understandable if you're not a sysadmin. It has been discussed even in the Debian comittee decision debates. Basically, sysvinit was a pain for every decent sysadmin, it has so many problems nowadays, it needed all the most competent sysadmin skills to work, and not even correctly work. So distros sysadmins, which have to deal with all kind of setup, were having lots of pain with it. I don't run a distro and saw how bad sysvinit was 15+ years ago, and abandoned it as soon as I could for every Linux system I used. That's why upstart and countless others (I use simpleinit-msb for years) were created too. Everyone having to deal with sysvinit wanted to get rid of it. In my opinion, systemd is the best I have ever seen on Linux (or every other Unix OS I manage) by far, so I jumped on it right away after reading the first description of it by Lennart years ago. And never looked back since. I can understand distro sysadmins doing the same, any other choice would have been insane or uninformed to me.
Slashdot's hivemind seems to have decided that systemd is simply evil, with no clear reason why. I understand that we're all traditionalists, but this often goes beyond common sense.
Well then somehow you have missed all of the good points. None of these points are "rumors" and I will be glad to show you sources for each.
Mission creep. Your init system now has a logon shell, and handles DHCPD tasks. Why is init handling logons and dhcpds? Binary log files (PUKE) Extremely poor documentation Rushed to market with little objective testing Bugs pile up with no resolution in sight, they just keep going for another dameon.
And then when you ask a fan of it why they like it, the response is "My system boots faster."
How about instead you tell me why systemd is so much better then everything we had before? And no cheating you dont reboot servers typically so boot time is meaningless./me gets popcorn.
The sad thing is that you prove the parent post with yours: an anonymous coward posting rumors, outdated or plain false information without any shame. systemd init never handled logons or DHCPCD tasks, it's actually in the binary helpers. The only difference with sysvinit/upstart for these tasks, is that the tools are integrated with the init system and can benefit from it. Binary log files is a matter of opinion, there's no point citing them as you can have your standard log files at the same time, even have a minimal journal (the thing trolls call binary log file) in memory and all your usual log files at the usual place. The documentation is extremely good, and if you take sysvinit and init scripts as reference, the documentation can't even be compared, as sysvinit and init scripts have close to none. Rushed to market is a matter of opinion, years of testing doesn't qualify as such to me. If it was for me, systemd would have been default in all distro a long time ago, but I was there from the start. Why systemd is better has been explained already, we don't need to convince everybody, and especially not people masquerading as sysadmins that ask. A good sysadmin will document himself, not wait for random people to spoonfeed him.
Slashdot Mirror
I think you are underestimating your relative skill level. I know some system admins who are capable of that, but the vast majority seem not to be. I would guess you are in the top 10% if not the top 2% in terms of skill level. I see your point that writing init scrips is hard, and systemd will reduce problems from less-competent init writers.
My point is that only the people with as much experience (not even skill, just experience) are able to even understand the issues.
Yeah, recently is that the systemd argument has started drawing some very skilled people in to discuss what a good init system would look like. Here's one example. And of course, you've commented in some of the discussions in my journal, and I would like to think they are the work of a very skilled person too :)
I actually appreciate these because they are from people that really understand what they're talking about, it's refreshing.
One thing I've noticed is that people who favor systemd almost all favor the features of systemd. Those who oppose systemd almost all oppose because of architectural reasons, or implementation details. So theoretically both sides could come together if an architecturally sound init system were created with features people need.
I agree with this, my problem with a lot of opponents to systemd is not the fact that they have a different opinion, it's just two things :
- most of the time they don't understand what they're talking about and are just following a trend;
- those that are knowledgeable don't make enough serious work done to make a valuable competition to systemd;
The worse thing is that I understand the genuine flaws the knowledgeable people are talking about. They are trade-offs I think the systemd devs are well aware of.
I find them acceptable, the others find them not acceptable. We're in the exact same situation of Linux vs Minix or GNU Hurd, XFree86 vs the rest, DBUS vs other IPC tools...
Some people got the work done, it's not perfect, but it allows to make a useful implementation that can be improved later.
Other people have legitimate complaints, but are not doing any serious work, or let go when they realize that their high standards implementation would require 10 times more work to make sth useful. It's the real life world we live in.
Most of the anti systemd people don't realize that the problems systemd tries to solve, knowledgeable people have tried to solve them inadequately since 2 decades if not more. And some problems kept getting in, like the dynamic nature of the Linux kernel, which in itself caused a lot of shitstorms with devfs and the like before udev settled. These were the most painful migrations due to Linux kernel changes I ever had to do on my own made systems, and distributions maintainers must have been at huge pain since then.
Separation of mechanism and policy is a good thing, but the problem is that a distribution HAS a policy to withstand, which made the mess of hugely incompatible init, which in itself is not a problems for distributions, but one from upstream projects.
Systemd tackled lots of problems like these, it made some kernel Linux features prominent and simple to use (features that were rarely used before, and still not used in other init systems), improving the kernel by showing buggy, insecure or inadequate features (of course, as nobody used them, nobody noticed), some of them being huge problems for years (like mtab handling). For all that and more things (like improved security by default) that have nothing to do with systemd features, I thank the systemd devs.
That busybox removed support for the journal is not really a problem though, as if systemd is used with a busybox system (that's what I do in my LiveCD), the busybox syslog is not even used, there was no point in doing that.
Since SystemD provides Sys V init, and backwards compatability, the criticism of systemd is a bit overblown as people can simply use system v init features on systemd if they want.
Most of the problems with systemd are migration problems, and most of them come from teh sysv compatibility layer.
The integration of cron, syslog and init was important for being able to launch a service dependant based on say another cron event occuring. There are better ways to do this however using a decentralized model using well defined IPC bus interfaces and protocols allowing for the functionalities to be in seperate processes but allowing processes to communicate with each other, and each a user swappable components as I will describe later. There is no need to have one big monolithic process or poorly understood components which are not swappable and do not communicate using well understood and documented protocols that can facilitate users swapping out components.
Does not compute: what you propose is what systemd is doing with DBUS. It's a so well understood IPC that KDE and Gnome flocked to it as soon as they could.
I doubt that systemd would be as big of a controversy as it is if the additional functionality was added but not heavily used all over the place for most of the services on the system and the distribution had not felt the need to convert every single service to the new type of init file. Its sort of like people who think they have to use every single C++ feature when C++ is not intended for that, its a bag of tools where the programmer is supposed to choose the tool they need, rather than something where the programmer is supposed to use every single last tool. Instead, the distributions who adopted it felt the need to convert most services over to the new init file format. This created a very much so in your face kind of obtrusiveness that was easily noticeable by many.
You're wrong, that's why you don't understand. People used the features because they were useful, and sometimes asked for for years, but only systemd devs took the challenge. It's not a case using every single tool, it's a case of using shitty tools for years and feeling pain, and as soon as sth far better arrives, everyone jumps on it. You just show that you have no clue about the countless improvements systemd brings.
And also, systemd works far better with its native unit files, than with the compatibility layer for mostly badly written, abused or inherently racy and insecure init scripts.
It was unnecessary in many cases as dependancy based startups can stil even be triggered from System V style initializations. Since systemd supports SysV startup, the majority of init files could have been left in SysV format which would have avoided much controversy. Another possibility is to offer init files in both the old and new formats so people can choose which one they desire.
No you're wrong, you have clearly no experience of these things. As I said, init scripts are inherently flawed, and no, you can't do dependancy based startups with init scripts. Lots of people have tried though, it lead to all sort of horrible flawed init scripts that usually don't work at all and can crash your server.
I believe in a mechanism not policy approach. Systemd's own model of dependancy init are useful in some cases however, are probably overkill for other services. The features should be there for those cases that people may need to use them. Systemd does allow users to the flexibility to use sysV init so the fact is for starting your services you can always have the started from sysV scripts even on Systemd. Ive done it and works fine.
No it doesn't work fine, at best it's a useless wrapper that have no purpose, but most of the time it adds flaws and bugs or try to hide flaws and bugs.
Your daemons should not need any shell script to run. Sysvnit doesn't need init scri
Why has nobody written a tool to view the binary log? Just 'cause it's binary doesn't mean that it can't be done - does it? I'd think that someone would do this. Maybe I'm missing something here but this doesn't seem insurmountable. If I gotta do it myself then, well... You don't want that.
Somebody has already done that, though not sth as stupid ad reading the files. The reason you're not aware of this is because you listen to the clueless anti systemd people. rsyslog reads from the journal since months, there is just no validity to the complaints of people about the journal, as you can constrain it to memory if you want (stupid thing to do IMO) and have only your "text" (but not really) files if you want.
And journalctl reads the "binary" logs (which are mostly text actually, unless compressed) already.
You'll be better off listening to proponent of systemd if you want to go anywhere, instead of the countless FUD and BS spouted by anti systemd people.
Most of the time they are repeating completely false arguments or things that are wrong for years.
ffs, init was 20k LOC systemd is now 100+ bins and 430k LOC.
These are not the same thing at all. These systemd LOC replaces init plus countless more daemons and Unix standard tools that you had to use in order to even boot to a usable shell. The tools that made some boot firmware larger and lead to things like busybox.
Before systemd you had a log file that was text and parsable using the commands that are core to unix (or specialized applications/services to injest them later), after systemd you have a binary log that mind you has code controlling it that can choose to destroy that log if it finds it is unreadable or corrupted.
What you say is just clueless FUD. After systemd, you still have the exact same log file available (which are not always text) with even more useful and accurate information than before systemd. At least I know I do still have them, better than before, because now I actually have the log with the complete kernel logs, which I never had before systemd, not even with the kludge of using dmesg.
I wonder what destroying corrupted or unreadable means, but sure enough systemd do nothing of this kind. The corrupted log is still there, it's just not displayed to you by default, but if reading corrupted or unreadable log is your (nonsense) thing, you can still do it with the journal.
Init was special purpose and streamlined to do one task well, systemd is coupled to auth, dbus, vm startup and shutdown, vm management, privilege escalation, ....
What is your point, nothing is mutually exclusive in that...
No one is complaining about the features of systemd, everyone is complaining about the design of those features that is reminiscent of MS architecture and design (that even MS has started to run away from). Poettering has stood in front of rooms full of people and flatly said he does not care about posix or unix he wants to build something new. He is -- hes building a monolithic userspace kernel and RH is using the init functionality to shoehorn itself into a controlling position.
You don't make any sense. What is a userspace kernel? Who is this everyone you're talking about? It sure enough is not "everyone" in the sense used by sane people.
What is reminiscent of MS architecture in systemd? Systemd is using specific Linux features which were not widely used at all by anybody, what is so reminiscent of MS architecture in Linux?
You people say stupid things without ever any specific example to make your point, you just sound like crazy people that don't know what they're talking about.
But that's why your an ignorant AC.
Because of the way systemd/XDG/pam/dbus are designed, the more he extends it the more other core bins on the system will need to integrate with it or rebuild functionality that has been displaced by it for no reason. It is a loss lead development and it will me Linux's loss in the long term.
Another MS shill.
Nah, I said it wrong. I should have said, "Systemd makes things easier for people who write init scripts for distros."
Not only in distros actually, but also for upstream projects that distribute init configurations.
And usually distro init script writers are far better than most admins (and commercial software vendors script writers) out there that don't even understand how to write shell scripts. I've encountered countless horrors everywhere, and as early as I'm authorized, I reimplement most init scripts, and it's not true only on Linux, but even on AIX, Solaris and HP-UX (back in the day).
I do that since 15+ years. I'm sure most seasoned sysadmins do the same as soon as they encounter one init script bug that breaks their OS.
Someone actually documented there some of the things people that don't understand anything about init scripts, shell scripts or systemd actually do. That's the kind of horrors I see every time.
You don't even want to start thinking about the security implications of such things, especially since those people usually put setuid bits everywhere when their mess does'nt work.
Just like PulseAudio forced sanitizing lots of ALSA drivers, I guess systemd will at least force sanitizing init environments and weed out all these nonsense.
At least I can hope.
[...] Anyhow, if you've not seen this then this makes an EXCELLENT read:
http://blog.darknedgy.net/tech...
In the end, I've concluded, I just doesn't seem to matter to me - yet. It doesn't really impact me. I'm sure that it does others but, for me, it just works. I want to hate it. I want to be in the cool crowd and rage against the evils of the domineering Red Hat and crew... I want to be enraged enough to key cars, throw bricks through windows, or at least post vile, spittle speckled, angry posts on the internet but it just hasn't bit me yet. Maybe when it does? I'll start my brick collection, just in case.
Seriously, thank you, your post is one of the best I've read on Slashdot, especially because you cite the ONLY really good (blog) post describing systemd problems I've ever read. ...
As the author note, not a single systemd opponent can articulate any specific problem in systemd, just general things that they attribute to systemd but can't understand.
This blog post is genuinely good, and from someone that actually understand what he's talking about (he's at least read some of the code in systemd).
The flaws of systemd are clearly explained, and even I being a pro systemd person, can agree completely with everything written there.
This is an essential read for any systemd proponent or opponent actually.
What it shows, is that you can do better than systemd, because systemd devs took the practical way, not the high standard one.
Basically, it's like systemd were Linux, and the alternative must be like Minix (or GNU Hurd), that's how I'd summarize what is written in the blog post.
Most of the flaws described in the post are shortcuts chosen by the devs (and the systemd devs are aware of them), just like Linus did with Linux, so as to provide an implementation in a reasonable amount of time.
Now, if you look at the state of Linux and the state of Minix or the Hurd, I personnally agree with the choice made by the systemd devs.
The competition just now has to start implementing and proposing their high standard alternative to systemd and stop the complaining that doesn't help anyone.
Some have started (s6 with OpenRC might lead to sth), but nothing usable is available yet. Instead, there's lots of red herring and bad mouthing systemd by the competition, making them losing their time in useless discussions. Things like "systemd didn't invent socket activation, it's not even really socket activation" (hint: we don't care, the functionality is provided and advertised, when it wasn't before, or the projects like inetd and xinetd went abandoned), "systemd didn't invent cgroups, you can use them with scripts" (hint: we don't care, nobody used them with sysvinit, and systemd uses them by default), "you can jail your processes without systemd" (hint: this is laughable, as it was so complicated to do, and even more to do right in shell scripts, that it was never done, or always done wrong, and wrong feeling of security is worse than no security),
> Mind you few people will ever say a system is easier if that system
> is new and requires them to read a man page. Change is never easy.
Many people change when the new tool is better, even if it requires learning new ways of doing things. Many new and improved tools make a serious effort at backwards-compatiblity to make the transition easier (systemd does not do this). That's why, for example, many people switched from syslogd to rsyslog or syslog-ng. why many changed from ncsa or cern httpd to apache. why many changed from csh to posix sh (or bash or ksh or zsh). Many of these people who have gone through all these changes and more are the same people complaining about systemd, so their objection is clearly not because they are afraid of or too lazy to change.
No, you're wrong, the people you're talking about all made the change to systemd. And I'm one of them.
That's why most Linux distros switched to systemd BTW, you know, the same ones that switched from syslog to rsyslog or syslog-ng.
The people complaining about systemd are a minority that are on Devuan or fled to BSD by their own admission.
I know I'm never looking back to sysvinit, but then again, I started avoiding sysvinit 15+ years ago, and yet, I'm one of the most proficient admins with it.
The knowledge of the braindead sysvinit by most sysadmins is actually abysmal.
Or I could just open a file in gedit.
You are demonstrating the biggest advantage and the biggest downsides to Linux at the same time. The rich and widely available different ways to administer the system, and the self important douchbags in the community who believe their way is the one true way (tm).
You're wrong on this one. If you need a graphical tool to administer your system, you clearly are not meant for sysadmin work.
Most of the time, graphical tools like gedit aren't even usable (like on a constantly changing file) or available.
I've never heard a server administrator say systemd makes things easier for them. There are probably some server administrators somewhere who will claim that.
Systemd makes things easier for people who write init scripts. Init script writers are the people who have primarily been responsible for its adoption in various distros.
Your problem is right there: init scripts writers are server administrators, even the most seasoned one. That's why you never heard a server administrator say systemd is easier, that's because you can't recognise one when you see one.
The decision to drop stderr has made my life hell. I wish systemd guys understood how important it is to those of us that run servers.
stderr and stdout were dropped by sysvinit initscripts.
Systemd upstream logs everything to the journal by default : syslog, stdout and stderr.
So it's far better than initscripts ever whereby default.
No advantage as far as I can see compared to syslog and the ordinary text tools. Just a way to force the use of binary file processing tools and as soon as something pukes in the binary file it may be completely unreadable. A text file might not look good after a puke but it's still mostly readable.
No, actually, that causes no problem at all, the systemd journal even used to store core files, without any problem. It doesn't anymore though.
There are lots of advantages, but if you can't see them right away, you're hopeless, or don't really work as a sysadmin.
Just the fact that you can easily list all the logs between two dates for a specific service is sth that takes time and programming an awk script to manage for a seasoned sysadmin (or a tailor made shell script with lots of LOC), that won't even work with every syslog daemon.
Having a file residing in plain text vs having plain text piped to another program is a pretty significant difference. You can't seek around piped input, unless you cache it memory -- which could be resource-consuming. (And maybe your tool for reading piped input is broken because of shared library problems). Being able to read a resting file in plain text is very important in recovery situations.
What you say is clueless at best. If you want to seek around a plain text file, you have to load it in memory, which is far more resource consuming than journalctl searching the text file, and resource consumption gets worse with the bigger log files.
That's one of the point of tools like more and less, and even that will consume more resources than a search with journalctl.
And your example is nonsense, as in recovery situations, especially when you have shared library problems, you sure enough are not reading log files, but recovering your system. The log file reading to understand what went wrong comes AFTER having recovered.
You don't read log files while your system is broken with shared library problems, you people are incompetent fools, I don't want any of you near any of my systems, be they sysvinit or systemd or anything else.
And such disaster recoveries work far better and smoother with systemd than ever could with sysvinit.
One readline library problem with your readline enabled bash, and most of Linux initscripts are dead. Even with a specialized shell (dash is a PITA in itself anyway, abandoned it years ago). My systemd went on without problem though.
why would you even need to use systemd and unix at the same time? they are conceptually oil and water.
FTFY
Nobody does that, as it doesn't work. Systemd is only usable with Linux. Get your facts straight.
I like init scripts. One can understand
No. Programmers proficient in bash can understand. Don't use "One" to describe every IT person out there. There are countless people who would much rather remember a couple of keywords then sift through effectively source code and a whole load of environmental variables to figure out how a program starts.
I also find it funny that Linux people of all the people complain about having to remember a few hardcoded keywords.
I agree with you, and don't mistake these people with Linux people. Most of them by their own admission on Slashdot, moved to OpenBSD or FreeBSD to avoid systemd.
I'm pretty good at shell scripting, and yet, I still prefer systemd units compared to initscripts.
Initscripts are a security knightmare, most admins I've worked with don't even understand them at all, most people don't understand why Red Hat implemented service, and even "service" doesn't solve every initscripts problems.
All this tedious work to make initscripts work in distributions has been done by the same true sysadmins that want to move to systemd.
Every people that understand shell scripting looking at initscripts and their tons of LOC (still full of racy behaviour and bugs) that required years of work and bug reports can't seriously say that it's better than systemd units. Yet, that's what is cited as an argument for sysvinit.
I cannot wait until the first time you discover that systemd's startup is nondeterministic and your carefully tested system somehow fails to come up to reboot after a power failure because, while it worked when you were testing it, systemd decided to do things slightly differently when it mattered and BOOM everything fails.
init.d scripts may be sightly slower, but you can be 100% sure that the system will boot the same way every time.
No, you can't be 100% sure of anything with init.d, you must be new to sysadmin. Stop saying clueless things like that, you'll fool the new sysadmins there.
Systemd is far more reliable than initscripts for booting the more complicated your environment is, and it's on another planet as to dynamically restarting services or plumbing like network change.
So you are saying that you should rely on one system (systemd) to monitor and see that services are up correctly instead of using a real monitoring system?
With init-scripts and 3'rd party monitoring system
1. Boot
2. Verify that all services have started and are working correctly.
With systemd and 3'rd party monitoring system
1. Boot
2. Verify that all services have started and are working correctly.
The only difference between the two is possibly cutting down a few seconds in boot-time, and cutting down 5-10 seconds on a server-boot that is 60-120 seconds does not really matter that much..
In what you've written, there are no differences, but that's because you missed a lot of systemd features, and added a 3rd party monitoring system for systemd where you don't need any to monitor daemon startups (but you need it for the working correctly part).
Mostly, the log problem is a huge one that you have with initscripts, be it logs on stdout or kernel logs that you may have lost.
And yes, the purpose of init is to monitor services and see that they're up like you configured them to.
Second part to the whole thing, when going with systemd and you want to wait for a database to be up and responding before continuing on with the rest of the system is not only tricky but will require you to reorganize the dependencies for so many parts in the system.
With init-scripts it would be a simple addon.. Add a simple Swaitforstuff that would handle it in a easily way..
Are you new to sysadmin? What you say is funny in how naive it is. : /bin/sh -c 'until $(REPONSE=$(mysqladmin ping 2>&1) ; RET=$? ; fgrep -q "Access denied" <<<"$REPONSE" || [ $RET -eq 1 -o $RET -eq 11 ]) ; do sleep 1 ; done'
These racy kludges you describe are what was done in initscripts for many databases, easily broken and insecure kludges at that, that didn't support sudden shutdown or any unexpected behaviour. Just because most init can't handle it.
With systemd, for mariadb/mysql, there is nothing complicated to do. To be sure the service is started, I just added this line in the mysql service
ExecStartPost =
That's because databases daemon are such pains, but there's no complicated dependencies nonsense like you describe, and yes, systemd allows you to launch shell scripts too.
When mysql.service finishes, I'm then sure the daemon is at least accepting requests, and if not, there's a problem and I will see it in starting mode, and can kill it and investigate.
If you now are thinking about using a wapper-script.. So each and every daemon that i want to start would need to be modified with what it should depend on.... And what happens with the process-monitoring when using scripts? (exit codes from the wait-script or from the daemon..)
As soon as you try to do anything that's just a little on the edge on how the systemd people are thinking it gets complex quite fast..
No it doesn't, it's pretty simple, faster than writing tons of complicated, racy, insecure and buggy scripts.
Most of the systemd features could be implemented via a generic script-base (that could include support for older init-scripts) and at the same time adding a few new smaller daemons that would enable most of the features systemd does..
You don't know what you're talking about here. I used to do that with tailor made shell scripts for every server, but it's not viable when you have lots of systems to maintain, and you just showed some of the flaws with sysvinit. Most distributions used lots of helper binaries, none compatible, every one in a different code base, with their lot of bugs, insecure code, and such. You describe the mess that was before systemd, and one of the reasons every distribution jumped to systemd. Now, all this maintenance is in one place, have to be audited in one place. And it works better than any other distro specific implement
The logical follow up question is why does upower depend on systemd?
The team decided they didn't want to duplicate support for suspend/hibernate when there's already a tool which does so. At the same time they released a solution for those people without systemd:
[...]
So what exactly is the problem? Why exactly is systemd so evil because someone else doesn't want to maintain a certain effort they are doing and instead hand off to another package, while even providing a compatibility option for the anti-systemd crowd?
There is no problem here, and never was, it's just that like any good sysadmin would do, you've made your research as to why the change occurred.
The one complaining never did any reasearch and never was affected at all by systemd, he just wanted to complain about sth he didn't understand just because.
Most systemd opponents sound like this, as haters that don't understand what they're talking about, wanting to put the blame on systemd for doing the right thing, and people more knowledgeable than them (like MATE or Upower devs) taking advantage of it.
The problem is that systemd is so more advanced than its competition, that it seems like the competition doesn't do anything about its manby problems, and is already years behind systemd. The systemd which is improving on a daily basis BTW.
I think the issue isn't that MATE depends on upower, rather that the latest version of upower depends on systemd.
What is the issue there? You didn't tell. Actually, unless you maintain any of the thing you complain about, which obviously you don't, you have no issue at all.
You're just complaining without understanding why.
Latest MATE depending on latest upower is a problem with the MATE developers, you don't even understand why that's the case, and I'm sure there's a reason other than just to be up to date. I'm pretty sure that's because older upower was broken in some ways.
Which then leads to upower. Latest upower depends on systemd (if you choose so, perhaps it's optional), because some cases were just broken (or insecure) with other init systems. Again, you don't even understand why upower devs chose to depend on systemd, but you complain and see this as an issue, an issue that you can't even describe.
Perhaps MATE should not have required the latest version of upower, but that passes the problem to the MATE team rather than placing the problem where it belongs, which is with the systemd team.
So you move the "problem" because if we placed it where it should, you couldn't blame systemd. OK.
Don't worry, it was obvious from the start you had no problem, and was just willing to bitch about systemd, just because.
As another poster has identifies, the problem seems to be that the systemd people aren't coding to interfaces. If they were, then dependencies wouldn't be on specific code, i.e. the implementations.
Upgrading software shouldn't require a change to the init system.
None of that is your problem, that's the distribution problem, you have exactly zero thing to do, except let the distribution replace your init with systemd, which makes no difference to you as your biggest concern is moving to the latest MATE desktop.
Your distribution is telling you that if you want the latest MATE, you need systemd, but instead of complaining to your distribution, you want to complain to systemd devs, go figure.
> If you are a system administrator and you can't handle with systemd, then you should consider change job!
You sir, are a moron. Sysadmins are the janitors of computing. You do not expect them to be terribly bright. You expect them to be diligent. You don't expect them to be great programmers.
Thank you for dissing sysadmins like me. I agree with this person, a sysadmin that can't handle systemd is not worth anything.
Now, explain to me why systemd opponents claim shell scripts (programming language, you know?) are better than configuration files (systemd units).
Systemd opponents contradict themselves every time, when not plain insulting themselves and others.
Otherwise they would be doing that job instead.
You don't know what you're talking about, sysadmins use the Shell (KSH, Bash, ...) a lot.
Once you get away from startups and before you get to "Cloud providers" you have most of the industry that follows Sturgeons Law.
If you make something "too difficult", the CxO class will find some other product to use. They might even buy the propaganda from that other guy about how "they build things to be easy".
They won't fire their "lame sysadmins", they will fire you Red Hat.
Some FUD and wishful thinking there, you people have no shame, and can't be taken seriously.
What SystemD is doing is a good idea, it's how they're doing it and their attitude. They seem to have the mindset of Devs and not sysadmins. Windows is an example of an OS by Devs. It's death by a thousand cuts. You can't quite pout you finger on exactly what is wrong, but there's a whole lot of small issues that amass into some real annoying rare cases that don't affect most users, but should never happen in the first place.
Please provide at least one example.
What you say is just an opinion by someone who, from my point of view of 20+ years of Unix administration, doesn't understand anything of what he's talking about and is spouting BS he read somewhere else.
The small issues amassing in real annoying rare cases are sth that always existed on any OS, but you seem to say only systemd is causing that.
So what you're saying is clearly BS.
LaunchD has existed for a long time and is fully opensource and well tested. It has gotten the run-through with iOS which needs to be easy to use and work reliably in some very complicated environments, like cell phones. Of course there is the very strong "not invented here" mindset that a lot of GPL people have.
You don't even understand the GPL and what it's for, so your case is getting even worse. You sound like a proprietary software shill, not like someone who understands Linux, and therefore not as someone legitimate to talk about systemd. FYI, launchd is one of the init that have been studied before making systemd.
Studied by people that actually understood the GPL, Unix (BSD and System V), and Linux. At least far better than you ever could.
Comparing SystemD to LaunchD is like comparing btrfs to ZFS. The most annoying mind-set that I've seen from the SystemD people is the whole "if everything is working as expected, this situation should never happen, so we may as well not handle this situation". How I hate that. If you know about a failure case, handle it! I hate that "limp along and some time later, fail in some unrelated way that gives the wrong impression". Works great when it works, but the failure cases are a mess.
Oh my god! Thankfully you don't do systemd administration. FYI, the kernel works just like that! Systemd is tailored for Linux, and it shares lots of its design.
If your memory is physically malfunctioning and corrupted, the kernel (and systemd) is choosing to not do anything about it, and not handle it, because they decided they can't, and prefer launching a kernel panic (or a systemd halt)! That you hate that just means you hate Linux and systemd, but some people like me find this a legitimate and sensible choice and will continue to use both.
Did you know that both LaunchD and ZFS had numerous old-school Unix people working on them in all stages of development?
Did you know there was a problem with the licences of both and the GPL? Did you know that LaunchD and ZFS were not made for Linux?
These are people who grew up using and managing mainframes and many now make a living managing datacenters. Who would you rather having designing the critical infrastructure of your OS. A sysadmin dev hybrid programmer who grew up learning exactly why things are designed the way they are, or some wide-eyed dev who likes flashy things and assumes the wisdom of a sysadmin is just the rantings of some old person?
In the case of a free GPL OS like Linux, I would not want any of these sysadmins touching Linux infrastructure at all. People trained in proprietary buggy Unix OS, no thanks! People that couldn't to this day do better than the GNU OS? No thanks!
Now, if the sysadmin dev hybrid programmer who grew up learning exactly why things are designed the way they are was actually working on Linux, yes of course I would chose this one. Oh wait, that's exactly who Lennart Poettering (the one that launched systemd) is!
Mind you, I'm a fairly young person that loves flashy things, plays AAA video games, and watches anime, not some neck-beard.
Don't worry, it shows in what you've written. Fortunately, the one developing systemd and Linux are not like you.
Sorry, if you need systemd to execute the kill -9 on an unresponsive java application you really shouldn't work in this field. All our java apps get a chance to shut down gracefully and get killed if the don't do it in time. That is ONE generic script dropped in any java deamons bin folder. Doesn't even need customization like the startup scripts. Btw systemd also got the job done on database shutdowns with lots of dirty pages wrecking the database. One solution doesn't fit all and that is what systemd is doing.
So you're saying that your init system can't do the job, so you had to make one custom script to handle it.
I say you shouldn't work in this field then, as systemd is doing better than your custom script by design and by default, first killing your processes, letting them some (configurable) time to stop, and then only doing kill -9 on the rogue processes.
Your system will be better off with one standard init doing its job correctly, instead of the mess of customized systems that was caused by sysvinit.
Some people have so many problems with systemd, because it invades every part of the system and 'solves' one problem by breaking lots of other stuff. The power of unix systems was that if you run into problems you can easily fix them. Systemd makes a lot of assumptions that might or might not fit to your problem and forces them down your throat. And the instant kill of services was one of these bad decisions they had to backpaddle on.
Here comes the FUD!
I don't even remember systemd ever instant killing services. The killing process is entirely configurable, so you're mixing things up there, surely because you don't understand anything about it. It's explained in systemd.kill man page.
The only thing that systemd revealed, is the amount of people doing system administration without understanding anything about what they were doing.
These people then were all stuck when migrating to systemd, because they have no clue as to how to migrate all their customs scripts and helpers for dodging sysvinit flaws, scattered around their systems. Systemd being more serious about security, all these security holes in the system don't even work anymore.
Your script is just an example of these nonsense.
Breaking network boot by stripping search and domain from DHCP another. At least the idea to kill your current ssh connection on a system update kept being an idea.
Systemd didn't break any network boot because it wasn't stripping any search and domain from DHCP. Only the specific systemd implementation did that at first because it wasn't implemented, it was documented, and noone therefore forced you to use the systemd implementation.
Only someone not understanding what they were doing would have done such a stupid thing as replace their DHCP client with another lacking the features he needed.
Also tons of experience with RedHat is like tons of experience with Windows. Just because you know the limitations doesn't mean that you need to live with. them. And there is a big difference in patching a script compared to applying a patch to systemd.
Systemd needs to stop implementing feature requests without thinking them over.
Yet you chose to live with sysvinit limitations, go figure!
The equivalent of patching a script is not to patch systemd, but just to modify some unit file.
Systemd doesn't need to stop implementing requests (there's already a big filter on what is accepted upstream), as these requests are optional services, and come from legitimate admin demands, that people like you complain systemd devs don't listen to.
Systemd needs to a let another software monitor daemon statuses, Daemon states can be much more complex than they account for and there is specialized software around that doesn't mind sending systemd the restart command.
In short systemd needs to focus.
Systemd doesn't prevent you fr
systemd does things like auto-detect all of the tty devices, and automatically associate them with login prompts when the device becomes active. This sounds good, until you hit an application where the tty device should not have a login prompt. After two days of trying to work around the issue (there is a work around), I now understand what everyone was complaining about ...
Actually, you don't understand anything.
Systemd doesn't detect any tty devices, the Linux kernel is doing that, systemd just associates an action to dynamic appearance or disappearance of some devices, that are configured by upstream, your distribution, or yourself.
If you login to a tty, and then this tty is supposed to be used by another application because it was configured like that, that means a conflict, and so a misconfiguration by your distribution or yourself. In all cases the conflict is logged by systemd as an error.
So the end result is that you had a system misconfigured.
What I don't understand, is why it took you two days to see the error message when journald will show it to you right away.
The biggest issue is that everything is wrapped in layers of configuration scripts, and this makes it is difficult to do something specific. The distros in an effort to "make everything easier" then have their own distro-specific scripts, and this makes the problems even worse.
The old way had one configuration script per activity, and this had the advantage that you only had to worry about one script.
Systemd doesn't wrap anything in layers of scripts, one of its goals is removing these layers instead.
Distributions actually add layers of configuration files out of habit of sysvinit, where you could have configurations scattered in more than 5 different files. If you apply systemd style, configuration is just in one place, either the daemon configuration files, or in systemd if it's about the system plumbing.
Actually, I'm not a fan of systemd, but as a system programmer/administrator with 30 years of experience on just about every type of Unix system from PCs to Crays, I've seen a lot of good and bad things. With every change -- especially forced change -- comes griping - some valid, some not. I'm sure I'm not as much of an expert on this particular issue as others here, based on some of the posts, but I am trying to be optimistic. The idea of systemd (or some/much of it anyway) seems good (the Solaris Service Manager doesn't suck), but I think the implementation suffers, especially from not being well or completely thought out, being a bit over-reaching and developed by people with larger than deserved egos who are unwilling to compromise and/or accept or act on constructive criticism - some of that also from people with ego problems.
I just imagine if people worked together, things could be a lot better.
You have all these wrong impressions because you never actually read the systemd ML, but instead basing your knowledge on trolls.
You would then see that you're really in the wrong here.
Agreed and I would add switching systemd to PID 2 and make a very simple init process as PID 1.
But that's how systemd works already: the minimum is put into PID 1, eveything else is separate helper daemons.
Actually, I'm hoping that the developers will get their heads out of their asses and listen to the people actually using their product, but Kay and Lennart apparently are mediocre programmers that don't play well with others, but have, for some reason, been allowed to play w/o adult supervision.
Just read the ML instead of saying nonsense, or rather don't, or you'd see how shameful your comments are.
systemd introduced lots of functionality asked for by the sysadmins, from distros or not.
The feature "creep" people talk about are actually not coming all from Lennart and Kay, but are useful optional additions asked for by the users (sysadmins, distro maintainers).
What nobody's explained to me is why, if systemd is as bad as most people on Slashdot think it is, why is it in so many distros?
It has been explained several times already, you just didn't pay attention or didn't understand the problem, which is understandable if you're not a sysadmin.
It has been discussed even in the Debian comittee decision debates.
Basically, sysvinit was a pain for every decent sysadmin, it has so many problems nowadays, it needed all the most competent sysadmin skills to work, and not even correctly work.
So distros sysadmins, which have to deal with all kind of setup, were having lots of pain with it.
I don't run a distro and saw how bad sysvinit was 15+ years ago, and abandoned it as soon as I could for every Linux system I used.
That's why upstart and countless others (I use simpleinit-msb for years) were created too. Everyone having to deal with sysvinit wanted to get rid of it.
In my opinion, systemd is the best I have ever seen on Linux (or every other Unix OS I manage) by far, so I jumped on it right away after reading the first description of it by Lennart years ago. And never looked back since. I can understand distro sysadmins doing the same, any other choice would have been insane or uninformed to me.
Slashdot's hivemind seems to have decided that systemd is simply evil, with no clear reason why. I understand that we're all traditionalists, but this often goes beyond common sense.
Well then somehow you have missed all of the good points. None of these points are "rumors" and I will be glad to show you sources for each.
Mission creep. Your init system now has a logon shell, and handles DHCPD tasks. Why is init handling logons and dhcpds?
Binary log files (PUKE)
Extremely poor documentation
Rushed to market with little objective testing
Bugs pile up with no resolution in sight, they just keep going for another dameon.
And then when you ask a fan of it why they like it, the response is "My system boots faster."
How about instead you tell me why systemd is so much better then everything we had before? And no cheating you dont reboot servers typically so boot time is meaningless. /me gets popcorn.
The sad thing is that you prove the parent post with yours: an anonymous coward posting rumors, outdated or plain false information without any shame.
systemd init never handled logons or DHCPCD tasks, it's actually in the binary helpers. The only difference with sysvinit/upstart for these tasks, is that the tools are integrated with the init system and can benefit from it.
Binary log files is a matter of opinion, there's no point citing them as you can have your standard log files at the same time, even have a minimal journal (the thing trolls call binary log file) in memory and all your usual log files at the usual place.
The documentation is extremely good, and if you take sysvinit and init scripts as reference, the documentation can't even be compared, as sysvinit and init scripts have close to none.
Rushed to market is a matter of opinion, years of testing doesn't qualify as such to me. If it was for me, systemd would have been default in all distro a long time ago, but I was there from the start.
Why systemd is better has been explained already, we don't need to convince everybody, and especially not people masquerading as sysadmins that ask.
A good sysadmin will document himself, not wait for random people to spoonfeed him.