Oh I know Dan Bernsteins "Daemontools" like "supervise". With all due respect for the man, those tools are an ugly hack that tries to make up for the almost non-existing functionality of SysVinit. Systemd are so much better in any respect compared to "Daemontools" that has no rate-limiting, no intelligent restarting, no total supervising chain (who monitors "svok"?), no resource control etc. etc.

SysVinit has been on the official UNIX kill list for decades with every Unix OS getting something else. Only Linux kept on using it long after it should have been killed off, only because there where no central Linux development outside the kernel. It wasn't because SysVinit was good it lasted so long, it was lack of development.

Come on, if anyone said: lets mix config statements and executable code in a free form, unstructured executable config file, people would laugh at them. Nevertheless, this is exactly what Linux has done with script based init systems like SysVinit and OpenRC and the rest of the lot.

With systemd we finally have separated code and config statements. You configure the init-system (systemd) handling of services by adding simple keywords in a structured text file that can easily be parsed by both humans and machines.

With systemd there finally is a central, coherent development of the "system glue" outside the kernel. It is exactly what the "Linux Plumber Initiative is all about. Systemd allows end users, SA's, developers and Distro maintainers, to enable powerful Linux kernel features in userland (like cgroup, Capabilities and soon, IPC's like kdbus) with simple keywords added to config files.

SysVinit and all those script based init-systems are effectively dead.
The discussion is over what the new Linux default init-system and plumbing system is; systemd won by a landslide because of its technical superiority.

You will doing yourself a disfavor if you keep on listening to all the systemd haters; they don't know what they are talking about, and their religious hatred against Linux changing will mean they will get left behind. Don't fall for that trap, stay sharp and hone your skills on systemd.

Either you have an actual user case for not using eg. RHEL's setup and version of systemd, and then you act upon that, or you don't have an actual user case, and there the problem just disappears.

You seem to try to make a problem out of nothing, what exactly is the precise problem you have since you want to configure systemd differently from RHEL?

The problem with discussing with systemd opponents like you is that you are hopelessly uninformed about systemd. That is why the critique seems so vague and imprecise.
Stop getting your information from ignorant systemd haters, and study the project itself. I can recommend the video talks on the systemd page if you want to understand the design of systemd. In a few years, all Linux distros will use it, so it is worth investigating.
http://www.freedesktop.org/wik...

I am aware that some turn of SELinux, because it is "easier" and they don't understand how it works, and they don't want to learn anything new. Yes, there a many SA's that lack both the technical skills and the ability to learn new skills.

But frankly, uneducated people with lack of skills, shouldn't hold back the development of Linux, just because they can't be bothered learn anything new even though they as SA's are paid to keep up with technologies (let's use SysVinit the next 30 years too, hooray!). They will be punished by life and left at the wayside. I have seen this happening to a lot of people in the IT business since the 1980's; they stagnated and stayed in their comfort zone and was later ejected out of the IT business because of outdated and obsolete skills.

Systemd is now the new defacto Linux plumbing system, and SA's either learn it, including its security features, or they will have to stop being Linux SA's.

Besides that, using "Kernel Capabilities" are very simple. Just put a single keyword into a text file and restart the service. Most end users will never have to edit anything since the services will come with some standard "kernel capabilities" features turned on, like "ReadOnlySystem=" and "ProtectedHome="

So yes, people will use systemd's many new security options, since they will be turned on by default in their distro, and it will increase security dramatically compared to old legacy Sysvinit systems, that are hard to protect. And yes, in the future there will be more kernel security features that systemd can utilize like kdbus, making services ever more hard to exploit, and making the defense ever deeper, practically sandboxing exposed services.
Systemd will make Linux more secure, it is a simple fact.

No, "Compile switch options" are entirely relevant for every distro. The distro has full control over which part of of systemd they want to include and with which options switched on as default. Systemd can be tailored in many different ways to fit both super computers and clusters, servers and VM's and OS containers, and desktops and tiny embedded systems. It is extremely flexible.
Just look at the documentation and the source code; it is all there for everyone to see.
http://www.freedesktop.org/wik...

If you don't want how RHEL are distributing systemd, just get another distro, or talk to Red Hat and explain you particular user case.

No it doesn't. If you need text files logs for some legacy reason, just direct all logging output from journald to syslogd. It enhances the logging info while keeping standard syslog text logs. It is a simple one liner in the systemd config file to enable that behavior.

Furthermore, the journal viewer, "journalctl" can easily be combined with any standard unix tool like grep; that way you can have all the advantages of having an indexed logfile while using standard GNU text utilities.

In fact, the standard pager for viewing log files is good old "less". You can easily disable the pager, or use another one of you like.

All the systemd tools are just normal Linux tools, just better implemented than average. So all the text utils and find utils etc. works absolutely fine with systemd tools. I really don't know where you got that idea that this wasn't the case.

Sure, you can't grep the structured journal directly, but that is what piping was invented for. "journalctl -b1 -p err | grep -i rpcbind" shows all instances of "rpcbind" in the previous boot log only, and only at error level "critical".
It is that easy.

Oh, and the structured journal is well documented with a interface stability promise, and many language bindings to read and write into it. Even rsyslog can read systemd journal files directly.
Here is how it is designed:
http://www.freedesktop.org/wik...

I don't think there are any aspect where shell scripting can't be used together systemd and its tools. In fact, systemd enhances the admins ability to gain secure knowledge about the system and executing programs depending on the state of the system.

No offense meant, but systemd opponents are usually badly informed about even basic points about systemd. They seem to get their opinions about systemd, not from the systemd documentation, but from other users on the net, and quite frankly, some of those users are just spewing random lies and made up stories about systemd because they are blinded by their hatred.

Do yourself a favor, and don't rely in random anonymous systemd haters for your information, but get it from the source instead.
http://www.freedesktop.org/wik...

It is worth getting a proper knowledge about systemd since this is the future of Linux, especially if one intends to poke around and make custom stuff.

"Need" is an elastic term. Sure, sysvinit worked on Linux servers for many years despite its many shortcomings, but it was always a very resource intensive endeavor to make it work and support it (think; all distros have different init scripts for each service and everybody of them hard to debug and prone to bugs). All the missing functionality of sysvinit had to be made up with complex scripting at each and every service.

But the old sysvinit model relied heavily on a certain way of doing computing, basically running servers directly on the metal with a few selected services and often with lots of "scripting" glue hand crafted for each server. They where individual servers, maintained by admins that needed a rather thorough knowledge about how a particular server worked.
But that model have changed considerably over the years and that is the main reason why old style script based systems no longer is working as well as it used to do.

Massive and rapid deployment of servers, virtualization, OS-containers, instantiated services etc. are becoming important. OS's needs to be automatically configured, or mass configured by machines. It is all about speed and hardware density in order to stay competetive. Take for example a hosting provider that has 10.000 Linux instances hosted. It used to be that they would have to run 10.000 instances of sshd or similar, even though only 1000 users where active at the time. With systemd they only need to run exactly the amount of services as there are current users, since services can be "on-demand socket activated". (no, it isn't like inetd, read here: http://0pointer.de/blog/projec... )

In short, the provider can pack more users into each hardware unit, that saves money.

systemd also makes it possible to upgrade a service and restarting it without breaking any end user connections (it buffers the client requests).

There are many systemd enhancements for servers because it isn't just simple init systems. I think that in order to stay relevant, BSD will have to start cloning a considerable amount of systemd features. It will be different on BSD because they don't suffer the same fragmentation chaos as Linux, but the main points of systemd, like (k)dbus service communication, intelligent PID1 that utilizes kernel features like security modules making them available to services without reprogramming, a total service and process superviser chain, early "metal-to-metal" logging etc. will be cloned by BSD. It is only a matter of time.

I don't think it is similar to the GUI formerly known as Metro. As I understand it, Metro removes abilities from the end user, while systemd actually enhances the end user by providing many more powerful features in an easy to use manner.
Also, systemd enhances both tiny embedded systems, servers and desktop systems. It doesn't have any weak points in that regard.

You shouldn't worry about "read/modify/log.." when it comes to systemd. It enhances early boot logging considerably since it is active from initramfs. All the config files are well documented text files with declarative statements that are easy to parse for both humans and programs. Systemd has a lot of really nice helper programs like "systemd-delta" that instantly tells which of the hundreds of service config files (unit files) that have been changed, and it is also smart enough to see whether it is a functional change, or just an added comment.

It is however a new way running and maintaining Linux. You can't avoid reading up on the subject if you want to modify or understand things. What many discussions on systemd makes clear is that many people are quite ignorant of its features and its design. They simply haven't studied it.

If you want to admin Linux in the future, it is simply mandatory to read up on systemd. The official systemd site isn't a bad place to start.
http://www.freedesktop.org/wik...

First of all, let me say that "Unix model" and all similar references to Unix philosophy etc, are totally content free platitudes in my opinion. There is no canonical "Unix" book where a Unix-pope have decreed ex catedra what "Unix" is. Heck, Unix was even born without support for "piping" between programs. The "Unix model" end up as 1990's time freeze because that keeps some old sysadmins happy that they don't need to learn anything new.

So it is easy to argue that systemd actually follows the "Unix model" in every way, and is modular, even in the "admin" sense of the word as you describe it.

Systemd is an umbrella project with many small programs collected in one utility box, just like "busybox" or "kernel-utils". It consist of many small binaries, like "systemctl" "localed" "timedated" etc. All these binaries behaves exactly like any other Linux/Unix binary tools; they tend to do one thing only (and do it very well), and can easily be combined with any other standard GNU tools like grep, sed, tee, ed, less and so on, by utilizing piping (eg. "systemctl | grep -i foobar") . They are in fact indistinguishable from any other Unix tool in the way they behave.

You are off course also wrong about systemd requiring the whole package or nothing. Just look at the compile switch options. There is even an official page about how to reduce systemd even further http://freedesktop.org/wiki/So...
One of the key drivers behind systemd is the embedded market, and they want minimal systems. On desktop and servers, it doesn't make much sense removing systemd options, since they are basically zero-overhead and provides options that nobody else does.

And yes, systemd works fine with together syslogd, in fact it enhances it considerably because systemd is able to get early and late boot log info since it is active from early boot in initramfs.

What you can't do is ripping random elements out of the systemd toolkit and expect it to work unmodified together with any other random system.

One reason why systemd simply routs any opposition is, that when people actually study it, they find that is has awesome new features and solve so many of the sysvinit shortcomings. From terminating services correctly http://0pointer.de/blog/projec...
to actually tracking and supervising all running processes http://0pointer.de/blog/projec...

And because of its design, it also offer superior security features, because as PID1 it can hook into advanced kernel features like "kernel capabilities" http://man7.org/linux/man-page... and "cgroup", and soon, also kdbus. Systemd works as a Linux plumbing layer, making all these features available for end users and distro maintainers, and making them easy to use by just adding simple keywords into a text config file.

Systemd is also a cross distro comparability layer; that means upstream projects can develop against systemd, and be sure it works across many different distros. It is easy to develop DE developers to make a GUI for setting networks or NTP/time or keyboard layout etc, on a systemd OS. On non-systemd distros, everything is scattered and fragmented, making it impossible to do.

The end result is, that all new development will be done with systemd. And because people like you think that nothing needs to be changed, the non-system distros will remain utterly fragmented and unsupported from upstream projects.

The bottom line is, that if people want to use non-systemd distros in the future, they better start getting off their couches and start develop an alternative. Not only do they need to maintain sysvinit infrastructure now that the "big boys" like Red Hat and Debian and Suse and Ubuntu are converting to systemd and therefore drops sysvinit/upstart development, but also extend the present infrastructure to deal with eg. safely using rootless X. They also ought to organize to help upstream projects like KDE and Gnome, by making a similar compatibility layer that work across the few remaining non-systemd distros.

Because it can't be done safely in any other way. This is why certified Unix'es like Solaris and Mac OSX have dropped old style init scripts; sysvinit and its brethren doesn't belong in the modern world. They are outdated and unsafe.

That situation is easily handled by systemd since it has total knowledge and supervision of all running processes and services, and has extensive capabilities for various ways of restarting crashed services. This included ways to limit restarts, so as if a services crashes more than eg. two times within eg. 10 minutes it wont restart that service again (or reboot the entire system, or many other actions). This is controlled by simple keywords added to the config files like "StartLimitInterval=, StartLimitBurst="

You can even make systemd clean up core dumps after a failure if that is what you want.

Here is a overview of the many fine grained service control mechanisms that systemd supports;
http://www.freedesktop.org/sof...

The problem is, that on a multi user system, something have to track user sessions, or else suspend, sleep and shutdown (and many more things) doesn't know when it is safe to operate. On Linux this used to be done by ConsoleKit, ("logind" is the systemd solution), but CK have been abandoned for almost 2 years now. It is bit-rotting and starting to break, and upstreams projects like KDE and Gnome are finding it increasingly hard to support.

So in order to run a multi-user or multi-seat Linux system in a way people expect, you have to use systemd.

There is also root-less X.org. It can't be done safely on Linux without systemd's "logind" because of eg. raw input devices needs to be tracked by a session manager. ConsoleKit could probably be extended to do the same, but nobody seems to try.

At the moment it also look like that Wayland Desktop Environments will be a systemd thing only. Eg. KDE KF 5 will support non-systemd systems running X.org, but only systemd systems with Wayland. Again, they don't do it because they are remote controlled by Poettering, but because all new development outside KDE is happening around systemd. There are no alternative developers actively supporting other solutions than systemd, so KDE simply have no other choice.

There are many more problems for non-systemd systems that will crop up, once all the major Linux distros and their developers shift their focus to systemd.

I have no problem with people preferring other init systems than systemd, in fact, some competition to systemd would be nice. But in order for people using eg. sysvinit in the future, they better start making a clear, technical analysis of what maintenance problems they have to deal with, and start working on them.

As it is now, even distros like Slackware that isn't so hot on systemd, will probably become systemd distros, simply because they have no real alternative, and are too small to pick up all the maintenance burden themselves.

At the moment, http://www.freedesktop.org/wik... is the best site for systemd information. It could have a better organization, but there is an awful lot of information about systemd, even the nitty gritty details needed for developers.