That the kernel buffers some kernel log files during boot really is independent of what init system there is. But as you can see when studying dmesg output, it only have "internal" kernel messages. It really doesn't know anything of mount points etc., so that leaves a gap between the kernel dmesg output and when syslog finally is ready. systemd plug that gap by being able to log events while in initramfs.
Please tell me why it is needed for servers. What does it replace that was broken in servers? It has nothing to do with relearning things, it has to do with a solution looking for a break, when there is not one. And you are still ignoring the blatant examples of it NOT WORKING
It has a total process and service supervision chain, including systemd as PID1. It simply does everything better that SysVinit does, including when all the hack tools are bolted on. It can also deal with OS containers, which will becomes just as important as VM's are now. It exposes powerful kernel features like cgroups, kernel capabilities and namespaces in an easy to use fashion, providing strong security and useful features out of the box. Want to limit a service to only 50% CPU resources on a certain CPU? Just add a simple keyword to structured text config file and restart the service. Since systemd have total supervision of all processes, it will track all the sub-processes that the service spawns too, and place them under the 50% limit.
I could go on, but it really seems to me that you haven't done a serious study of systemd with an open mind. Considering that all the commercial distros are switching to systemd, it is a worthwhile thing to do for anybody with professional interest in Linux.
Unix wasn't even born with the now basic concept of "piping", it was a development over time.
It was an extremely early development, introduced before Unix was introduced to the world at large. That's why it's described in the first edition of "The Unix Programming Environment". Describing piping as a johnny-come-lately feature of Unix is disingenuous.
As I said, Unix wasn't even born with piping, it was a later development. And of course, Unix wasn't born fully fledged with all features and made according to some pre-existing Unix philosophy. They were pioneers in much what they did after all.
My point was simply to stress, that what the early Unix developers did was a reflection of the challenges they faced at the time, and that the lessons they learned reflects that. There are no dogmatic and universal Unix rules with a permanent truth value forever and in all ways of doing computing.
The systemd developers really did their homework well when designing the systemd log implementation
No. Maybe the log file implementation, but they didn't even get that right. An error in the file means the whole thing is useless.
Of course not. Just because a daemon died before finishing its log entry doesn't mean the log file can't be read. journalctl is quite good at dealing with such corruptions.
Also, binary logs are just plain wrongheaded, period, end of story, if they are not in a format which common tools can already read.
Not a problem; all the standard Linux text tools like "grep" and "tee" work great together with journalctl through the basic concept of piping. It is a very Unix way of dealing with such "problems".
Anyway, "grep" can learn to understand the journal file structure, so you can have a "jgrep" just like there is a "zipgrep" for dealing with zipped syslog files. I am sure that grep have been modified before to deal with new things like UTF-8 etc.
If you don't agree, then we can't agree. You simply don't understand the problem of trying to deal with potentially corrupt binary logs on another computer entirely, which is a real scenario. On occasion I have to resort to pulling the disk and slapping it into something else for analysis, and I shouldn't need special tools for that. I should be able to use anything lying around.
Not having the right tools in the box is simply a shameful thing for a paid SysAdmin. How do you expect to read a LVM volume or a new filesystem by using random, perhaps outdated tools?
It is such a basic requisite to have a working boot media. And yes, some old rescue discs doesn't support reading journal files yet, but it was the same situation with LVM and btrfs etc. If you didn't have an up to date boot media or similar, you couldn't mount or read the content of the LVM/btrfs disc.
It is so trivial to read and analyze journal log files on other computers or through a boot media. Since the journal has both a stable API and language bindings, several non-systemd journal readers will pop up over time too.
Anybody who has a free choice in which distro to run can always choose e.g. Slackware. Nobody is stuck with systemd on their home server against their will.
I really like systemd, but I applaud any serious attempt to make a distro with alternative ways of doing things. Competition is good.
As argued, I think there is a pressing need for the non-systemd camp that they make a long term distro a focal point for the needed development of non-systemd infrastructure (cgroups, udev, ConsoleKit, etc). It will be much better for the non-systemd camp to fork Debian, than to continue with it since it will become a full systemd distro in the end.
As it is now, the non-systemd camp is entirely scattered and un-organised. It is every distro for it self. Cooperation and making a developer community is crucial if non-systemd distro are going to survive this decade.
You got to be joking, systemd is much more flexible than anything else on non-systemd distros. And it is trivial to extend for third party developers since it has lots of libraries, stable API's and language bindings, something no other alternative have.
If you really think systemd isn't needed for servers, you simply haven't done a serious study of it. I have no problem with people not wanting to use systemd, but please don't reject it out of ignorance.
Yes, a lot of SA's have to relearn a lot of things, including how do debug problems, boot sequences, how to use cgroups and use the systemd kernel security features etc. Experience helps, but is no substitute for learning. These things happens once in a while in tech.
So much for GNU/Linux.
However, this still isn't a reason to force systemd, since we have around a dozen init systems out there, most of which are directly compatible with sysvinit.
Nobody is forcing systemd on anybody. That all the major distros have chosen systemd, is because it is so technical superior in every way to any alternative out there, and because it makes life easier for distro maintainers and developers, and actually help upstream projects by providing them with needed features and some sort of cross distro compatibility layer.
As you say there are lots of other init systems out there. However, in order to be a viable alternative to systemd, the non-systemd camp have to take control and start developing _all_ the necessary infrastructure code necessary, like ConsoleKit, cgroups, kdbus, udev, etc.
Of course we think UNIX should continue to evolve. But we think it should improve. Taking ideas from OSX and Windows is not making things better. If you want a polestar to navigate by, look at Plan 9.
A dead OS that haven't had a release in over a decade can hardly be a "polestar" for future Linux development.
I prefer "Linux philosophy" over "Unix philosophy" any day, because Linus Torvalds opinions are, that Linux is all about solving real world problems in the best manner possible, not adhering to any current fashion-of-today among OS designers. This is why he choose a monolithic kernel design, even though micro kernels where all the rage and the "right thing to do" at the time.
Plan 9 is probably a beautiful implementation of "everything is a file", is just happened to forget its users in the pursuit of that inflexible dogma, so it withered and died.
The same will happen to every OS that stand still and refuses to develop to solve contemporary problems.
These days certified Unix's are practically dead except Oracle Solaris and Mac OSX, and they both have an init system that resembles systemd. No wonder since the systemd developers studied launchd and SMF extensively before making systemd. taking what they liked, and dropping other things like XML config files.
systemd is simply an improvement overall in all areas in it deals with, compared to the old style legacy init systems with their executable config files.
So it hasn't actually needed a change in years (meaning it is fully matured) but you're worried that there isn't enough manpower to churn the code (that needs no churning)?!?
I am not worried since I use systemd and will never run a SysVinit distro again in my life. My point was that those who doesn't want to run systemd need to realize that a lot of work is needed in the future, and that the non-systemd camp is entirely responsible for making and maintaining the necessary code in order to e.g. run SysVinit in the future.
Trying to making a virtue out the fact that SysVinit is understaffed (and this is going to get worse when the paid developers from SUSE/RH stops making bugfixes that other distros can leach), seems to be a common reaction among non-systemd users.
There seems to be a lot of reality denying going on among non-systemd users; denial that work is needed to even maintain status quo, that only they are responsible for making it so, and that sitting under the palms waiting for a magical appearance of a non-systemd alternative simply will disappoint.
The failure to realize these future challenges and the lack of coordination and development to face such challenges, will simply doom all general purpose non-systemd distros in the future.
Why in the world would Xorg need systemd? It doesn't need it now.
In order to run X.org without root rights in a safe manner on Linux, you need something to deal with user sessions. Only systemd provides that. Here is a fosdem talk about it:
https://archive.fosdem.org/201...
Yes, bugs are a problem, but that's not what you said. You said it is bad because they haven't had a release in five years.
That shows a huge problem in your understanding of system design, which you should fix now or continue making poor systems. Stability in a core system component is a good thing, not a bad thing. Don't forget it and your code will be better.
Yeah, it is bad that there are outstanding bugs and they aren't being fixed. That is the case with SysVinit. These days SysVinit bugs are being fixed in distro repos, meaning that every sysvinit distro potentially got different releases, and the bug fixes aren't being mainlined with the GNU SysVinit. Not having a release in so many years is a sign of trouble, not stability.
Even SysVinit isn't in such a hot state, it haven't made a release in five years
This kind of stability is a good thing.....once you get a tool right, it shouldn't need to change much.
You seem to misunderstand the sorry state of SysVinit; all the bugfixes are upstreams in SUSE/RH packages, not in any official release of GNU SysVinit. The SysVinit developers doesn't even have a proper test framework, so the only way to test a patch is by installing it and reboot, hoping the system will come up.
When SUSE/RH drops their engagement in SysVinit, it will decay even more.
Not having a official release of SysVinit for so many years, or even a "beta/developer" release, isn't a sign of maturity, but lack of developers.
It sounds a lot like the non-systemd camp have no idea what they are actually for, they only know what they are against. So this kind of thing is not surprising to hear.
Yes, they are split among those who think SysVinit should be used the next 40 years too, and those who recognize something else is needed for modern computing needs. Even the latter group is sub-divided into factions about one should make an improved systemd clone for compatibility reasons, or use OpenRC for BSD reasons, or making something new etc.
So instead of focusing on making a developer community to counter systemd with new code, they focused on a negative campaign against systemd instead. It is so much easier to rant on the net than organizing and making stuff happening. But that negative strategy is also the single most important reason why systemd-opponents have been routed whole-sale from every major distro; they attacked open source developers and projects, while failing to provide an alternative.
Agree about the Unix thing. "Unix philosophy" It has become a cartoonish mockery of all the great things the Unix developers did back in 60's and 70's. Totally without content and with no connection to reality.
I like the UNIX philosophy and don't think it goes out of style just because it's a few decades old.
Sure, the problem is "What is Unix Philosphy"? and is it meant as a dogmatic ex cathedra so that Unix can never deviate from whatever that philosophy is, no matter that computing changes every decade with new domain problems?
Unix wasn't even born with the now basic concept of "piping", it was a development over time. So I think that the so called "Unix Philosophy" is much more about sound guidelines and how the Unix developers tackled the computing problems in their day, than any dogma that can't be deviated from.
These days we have massive use of Linux OS containers and VM's, using petabyte of storage spread across continents and many other domain problems that was unheard of in the 1960's. I do think that the present development and use of Linux in so many ways, also require new ways for Linux to function. If Linux is put in a 1990's time freeze it will simply become irrelevant and wither away.
I am against systemd, for now, mainly because of the binary log files and how it was railroaded through the community.
You can still use the same old flat text files logs with systemd distros by using rsyslog like you always had. Nothing is taken away, and in fact, since systemd can log from before root-filesystem is even mounted, you get better logging.
I was really skeptical about binary log files before I tried it, but walked away convinced that binary logs like those used by systemd's journald, is the way forward.
They really solve so many hard/impossible to fix problems with flat text file logs, and I have yet to find any real world problems with their actual implementation. All the usual Linux text tools like "grep" and "tee" works with the systemd journals through the basic Unix concept of piping.
The systemd developers really did their homework well when designing the systemd log implementation, and it is worth a serious study by anybody working with Linux, instead of a upfront dismissal just because they are binary.
I don't understand why even shell scripts are needed. Seems like they should be the exception, not the rule. Seems like configuration should be a single file that lists the programs to start from top to bottom. If you wanted add some parallel start-ups, it seems like you could just make the config file format a little fancier, maybe with some braces or indentation to express dependency.
Maybe instead of systemd we could come up with a start-up standard, sort of like the POSIX standard. Most programs seem already to be callable with the same arguments: start to start it, stop to stop it, restart to restart it. So the simple config file would call one or the other depending on which cycle we're in. Why the need for shell scripts? I've looked at them, and they mostly seem to be doing this anyway: call start on the shell script, and it calls start on the program. I see some checking, some setting of environmental variables maybe, but is this really needed?...
Using scripts (basically executable config files) to start daemons is probably a relic of the time when invented decades ago. The needs where much simpler in those days, and shell scripts was just a handy tool to have a quick and dirty solution to the problem. It haven't made sense for a decade at least to still using SysVinit and similar solutions, and all? certified Unix'es have switched long ago. In fact, launchd and Solaris SMF where major inspiration points for systemd.
It is quite doable to make a init system that uses declarative statements in text config files, both systemd and SMF does it. But it wouldn't be SysVinit anymore, so which distro will actually use such a init system? Slackware has its own style of SysVinit and is extremely conservative, an unlikely distro to change from what is has. Gentoo has OpenRC, and is also highly unlikely to change from that too.
So while possible to make, it is probably hard to find "buyers" for such a new init system, and therefore also developers to make it.
To me the most enlightening - and saddest - moment of the init system selection discussion was when Debian leadership quite clearly stated that they are not interested in something being developed in-house, they are just distro which packages somebody's else work.
Debian doesn't have a big pool of paid developers they channel into whatever project they wishes. The Debian technical committee is just doing the only sensible thing in choosing a working, well maintained init system for Jessie, instead of a not-quite-here/vapourware/unproven init system so close to the freezing of Jessie.
That decision doesn't prevent anybody from actually making an init systems that is better than systemd and the Debian could adopt for Jessie+1 (the decision was strictly for Jessie).
There has to be real tangible code and some track record for such a project to have a realistic change of being the new Debian init system however.
There are +150 Debian forks (derivates) already, so yet another one hardly matters. The main reason why its is an empty "threat" is that there basically isn't any real development of needed infrastructure in the non-systemd camp, and as time goes by, more and more alternative development will be need by non-systemd distros.
The fork of systemd's "udev", "eudev", is basically just a shadow fork with patches, but soon eudev maintainers have to decide between having to support a kdbus manager, thereby become more developers instead of just patch maintainers, or their fork will deviate so much from the real udev, that they no longer just can leech new patches from it.
Of course, ConsoleKit is still dead with nobody picking up development, the only alternative is a rather limited implementation of systemd-logind, and is basically maintained by a Canonical developer who are unlikely to maintain it after Canonical have switched to systemd.
Stuff like root-less X.org can at the moment only be safely done by systemd. Some Wayland implementations will also depend on systemd simply because the upstream projects aren't getting any help at all in supporting non-systemd distros.
Even SysVinit isn't in such a hot state, it haven't made a release in five years, and the defacto upstream maintainers have been SUSE/Reed Hat for years. At some point they will drop maintaining it anymore.
I could go on, but the fact is that there is an increasing amount of work needed to be done, just in order to keep status quo somewhat, and that the non-systemd camp are severely lacking developers that could help maintaining such critical infrastructure.
It would actually be quite good for the non-systemd camp if there was a proper Debian fork that solely was about non-systemd developemnt. They have been lacking a focal point for such development for a long term stable distro for years (Slackware, despite its merits, is ultra conservative and probably too limited in certain ways for this).
The problem is that some factions in the non-systemd camp are pursuing systemd "emulation" by using shims and forks. That way you just get a second rate systemd, and it will remove any motivation from upstream projects to support anything else than system. Using Ubuntu's "logind" is a short term gain, but a strategic failure for the non-systemd camp. They need their own implementation of needed infrastructure, not just copying or emulating systemd.
Seriously, what do people want? That nothing must be using Linux specific kernel features ever, because that is unfair to other OS's?
When I use gimp, pidgin, geany etc on a Windows desktop, it's because they consistently work well with a thin Gtk+ shim over Win32. That's without installing a Linux compatibility layer like cygwin.
If in future one has to install some cygwin-systemd abomination just to run Gimp, then free software will have lost a fan.
The problem is that nobody really develops for non-systemd distros anymore. Sure, a loud minority is constantly attacking systemd, but they don't bother with developing crucial software needed to run non-systemd distros, nor do they help upstream projects to support them either.
The reason why upstream projects depend on systemd, is because systemd provides essential low level stuff that nothing else really provides on Linux.
There will probably be no problem with running Gimp etc. on Windows (or OSX) simply because those OS's have the necessary low level stuff to keep modern software running, so the projects can just use that instead of systemd.
I program, therefore I am.
