If I use KDE - which I do - then packages for that become unavailable at some point in Slackware given the above. That means I will be forced to use systemd if I want to continue using KDE; which also means I will have to change distributions, assuming Slackware remains systemd free, as well.
First, KDE like all other main DE's are officially committed to supporting non-systemd distros and BSD. The only ones believing otherwise are alarmist systemd-detractors.
Second, the KDE component mentioned in the rather whining blog, isn't a central component, but just a login/display manager. There are other options to use.
Third, the reason why SDDM hasn't got CK support is quite understandable; KDE doesn't have big corporate sponsors, they are volunteers and are stretched to the limit regarding developers. Investing costly developer resources in using a dead and deprecated module like CK is simply insane.
But here is what KDE/Gnome developers and many others have said for years: it is up to the non-systemd distros to support upstream projects, just like the systemd distros does. Don't like systemd software, fine, but develop your own software stack so that upstream projects work on your distro.
Yes it will suck for small non-systemd distros that they just can't leech software development from the big commercial distros anymore. But the answer to that isn't trolling every systemd thread about how bad systemd allegedly is (not so credible to hear from non-users you know), but to get organized! Why is it that you only hear from systemd-dislikers in systemd threads? Why don't you create your own _positive_ community that is about creating cross distro non-systemd software? Why no "New SysVinit alliance created" threads?
The small non-systemd distros will have to cooperate for the first time in Linux history; if they play "every distro for itself", they will sink.
Not trivial. Not easy. Not freedom of choice.
No, things won't be easy for the non-systemd distros. Some of the development needed in order to have even some feature parity with systemd isn't trivial either (cgroups etc). But there is a freedom of choice, the point is that the non-systemd distros and their users are solely responsible for creating such choices.
It simply solve a lot of real world problems and makes life easier for both upstream developers, distro makers and end users.
That is simply a lie.
It is almost tragic so badly the non-systemd users like you are analyzing the situation. I really like systemd, but have no problems with people not using it, and in fact wished that systemd had even a tiny bit of competition.
If the non-systemd crowd don't understand that systemd actually both work, is good, and have compelling features, you will never be able to make an alternative to it. You won't even be able to have status quo. Know your enemy and all that.
The community is not forming around systemd. Systemd is being rammed down our throats by one company.
systemd had hundreds of contributors before it was used in any long term stable Linux distro like RHEL7. So many developers started to drool when they saw the systemd feature list; it presented much of what many people have longed for in a Linux init system. So yes, systemd was quick to gather a community and is now probably one of the largest Open Source projects when it comes to developers.
systemd is simply superior to SysVinit in every way which is why all the major distros adopted so quickly. It simply solve a lot of real world problems and makes life easier for both upstream developers, distro makers and end users.
For those who think SysVinit style init systems is what Linux should be using the next 30 years, there is Slackware. It is a nice general purpose distro that is very traditional. So nobody is forced to use systemd if they don't want to.
Newer versions of GNOME (3.8 and after?) rely on a DBus API of systemd's logind component, for reasons I've never seen adequately explained.
The talk of forcing all cgroup interactions to go through systemd would in effect make anything that interacts with cgroups or cpusets such as hwloc, TORQUE, and SLURM rely on systemd. I can't imagine that the developers of hwloc, TORQUE, and SLURM are especially happy about that.
That there can only be one cgroup manager at the time is caused by the cgroups developers decision to make a unified hierarchy tree with only one canonical manager instead of exposing cgroups fs directly to end users. systemd is just an example of such a manager. If you don't use systemd, you can just use another cgroups manager instead.
Regarding SLURM, they are of course starting to integrate systemd in their project. I assume most other cgroups projects are doing the same.
That LWN article is 3 years old and very outdated. The systemd developers was still developing the journald in those days, so they didn't want to freeze the API etc. it until they thought it was ready.
The journald log file format have been stable for a very long time now. Here is the developer info and documentation: http://www.freedesktop.org/wik...
There are already independent journald readers and several log watch programs that query the journald directly. Most tellingly; rsyslog can now read systemd journals directly. No need to forward syslog messages to it anymore if you use it as a log sink. It can read and write journald log files directly.
They are not "options", but field names in the systemd journal. So journalctl is querying the "database" directly for the values in the "_KERNEL_SUBSYSTEM" field that again contains fields like usb, pci, etc., that again have log entries.
"journalctl -F (tab)" will show you all possible main field names. Selecting eg. "journalctl -F _KERNEL_SUBSYSTEM (tab)" will show the the possible values: sound hid pci_bus acpi watchdog usb pci pnp scsi vc clockevents (snip)
You can basically "tab" your way to every log entry since they are indexed, and every log entry can be selected and shown by exactly which part of the system that generated them. It is an incredible powerful feature. It also allow you to generate on-thefly log entry lists of every PID/GID/Hostname/executable/service name/etc. that have ever written to the log file. Just press tab and all the values appear instantly.
The field names starting with _underscores have Kernel guarantee of not being faked.
At least with journald you can have logging done just binary, just text or both types simultaneousl
False. You cannot log only to text with systemd. And who wants twice the I/O (binary and text) to appease the systemd folks when text logs have been not only the defacto standard, but a rudimentary part of the UNIX philosophy. There are several other reasons I don't like systemd ( try to chroot to a broken system and tell me how much fun that is if the system is a systemd system ) but binary logging with no text only option is arrogant and a show stopper for me as well.
Of course you can have text only log files. Just tell journald not to make any journal files, and forward log messages to rsyslog. It is trivial to do.
Btw, did you know that rsyslog was started because of the inherent limitations of flat text files. These limitations is why all Unix/Linux Enteprise central logging solutions involve some kind of database (Splunk, rsyslog with db-driver modules etc).
Really, systemd's logging solution is seriously cool. It is worth a serious try out.
That is all nice and good until journalctl hangs on you, or you can even reach a command line because systemd has insists that the GUI configuration has priority is more important than setting up virtual terminals early in the boot process.
You got it all backwards; systemd provides outstanding early boot support, including VT's, especially because it starts from initramfs even before the root-filesystem is mounted.
The systemd journal is an open standard with a stable API and many language bindings, so there already exist alternative readers. There are no realistic scenarios where a systemd log file can't be read. They can be copied just like files to another machine one way or another, or the machine can be booted with a rescue disc
In spite of that, you give a good example of how really cryptic journalctl can be.
short-monotonic? --boot ? Why not --output snakes-n-oil???
The systemctl syntax is extremely easy to both use and understand. Yes, you will have to read a man page before using it, but then again, the only intuitive interface is the nipple, everything else is learned. It is trivial in comparison to learning regex, but much more efficient.
I see you find "--boot" and "short-monotonic" cryptic. That is probably because they are features that doesn't exist in traditional flat file log files (and more or less impossible to implement). But with systemd, every boot is marked in the journal with an unique ID, so it is trivial to select certain boot sequences. Really hard to do reliable with a regex. Monotonic timestamps is a meta-data time stamp in every log entry. The monotonic time counter starts from zero at every boot, so that every hardware, kernel and service initialization can be followed with an easy time delta. Here is a short monotonic log snippet; notice how time is incrementing.
You can still use "grep" and all the other standard Linux tools in conjunction with "systemctl". "systemctl" just act as a powerful log filter so often grep isn't needed.
I like your example for grep'ping for the word "error". That way you would miss both "Error" (no "i" switch") and "Warning" "Critical" "Failure" and what not. For systemd you could just use "systemctl -p err" and you would have found all critical log entries.
And why call everything a 'service'. It's called a 'daemon' in unix. Daemons provide services. Services are windows things. To me systemd is the toy for the noobs and wantabe cool ubuntu-ites that have no experience in the thick of server land. And second, I don't find systemd an elegant solution at all. systemv-init, now that is elegant, with the various run levels, and system states.
You are happy about Red Hat's hostile takeover of Linux?
Red Hat have always been a corner stone of Linux. If it wasn't for Red Hat, Linux wouldn't exist today. They have fueled money and developer time into almost all aspects of Linux over the decades, and their lawyers have fought off so many patent trolls and entities trying to harm Linux. AFAIK, Red Hat have been one of the biggest kernel contributors for decades too, so they have had a huge influence on both its design and features.
So I think the "let's hate Red Hat" fad among systemd haters is puerile, stupid and anti-Linux.
And I think even less about the tin foil hat conspiracy theories about mysterious Red Hat forces, working behind the scenes hell bent on taking over Linux.
The accusation of Red Hat's intention of "hostile takeover of Linux" is always vague. How exactly are RH controlling Linux by being a contributor among many when developing systemd? Is there some kind of mind control in the source code, or is it done by chem trails? Why is RH Kernel and glibc contributions not a problem, while their systemd contributions are?
All the major distros have changed to systemd simply because it is superior in every way to the existing alternatives. systemd simply solves real world problems for both distro makers, upstream developers and end users in a much better way than anything else.
What a rose tinted look at the past. I was there too, but I don't remember the way you do at all. The main reason why Linux took of was that it solved real world problems in an efficient way. So many OS's have been made in order to follow some dogmatic doctrine about microkernels/"everything is a file" etc., instead of focusing on how to solve problems for its users, but not Linux.
So Linux made things possible for admins, developers and ISP's that was otherwise difficult or expensive. In short, Linux made money and increased productivity. That is also why its users fueled developer hours and money back into the Linux community. The LAMP stack wasn't made by a lone hero hacker, but a collective of business' and developers that saw an opportunity for making money or increase efficiency and getting a competitive edge.
The LAMP stack was never designed by the cartoonish Unix design interpretation of "only do one thing", in fact almost no program of any complexity is, yet this was what was driving Linux forward.
systemd is just yet another change in Linux that follows the old Linux philosophy on focusing on solving real world problems for its users instead of riding a "Unix/Posix" hobby horse.
If you are beginning to have problems with how Linux have always evolved, then it is you who are beginning to act old, not Linux.
Keeping Linux in an eternal 1990's time freeze where nothing must be changed will simply kill of Linux just like all the other OS's that forgot both their users and how to adapt to the times.
Wait, so now we aren't setting read/write status in fstab anymore?
Yes, for file systems. Notice this is for a single running daemon. Think of it like a kind of sand boxing that prevents the service and all processes it spawns to e.g. read/write/boot/home/root etc.
Since it is build on "capabilities", those directories will be inaccessible even if the process is exploited. It is seriously cool stuff that systemd makes it easy to use.
Those facilities are not given by systemd. They are given by cgroups and other security features. Systemd just has a way for you to specify them for services, it's not doing all of the heavy lifting.
systemd makes it easy for both end users, upstream developers and distro makers to take advantage of those advanced kernel features; no low level hacking needed, no home made bash scripts, no endless hacking needed to make three dissimilar sub-systems talk together by fragile scripts.
With systemd strong hardening features comes ready to use out of the box. Just add a simple "keyword=value" in a text config files, and everything works.
The reason why kernel features like "capabilities" and "cgroups" have existed with very little or no use on general purpose distros, is exactly because they are very hard to use on systems that aren't designed like systemd. It is the same with the new Kernel IPC system "kdbus". Systemd will make it easy for upstream projects to use kernel IPC, while SysVinit and similar won't.
You don't have any knowledge about how systemd restarts services. You haven't read the systemd documentation, but instead seem to rely on some random systemd haters wrong info about how systemd restarts services. Think about that.
systemd doesn't restart services unless told so. And it can be quite intelligent about restarts, distinguishing between several different ways the service was terminated and making conditionally restarts depending on the service's exit signal and combining it with rate limiters.
But it will be. The "systemBSD" and "Uselessd" projects are just a warm up. Of course all the BSD's will get modern init systems like systemd before this decade is over.
I like the fact that systemd's wholesale acceptance by all major Linux distros means much less fragmentation in both the way the Linux OS is managed and the easy that upstream projects are now able to support advanced features in a distro agnostic way.
I also like the fact that it exposes advanced kernel features like "cgroups" and "Capabilities" and make them easy to use; just add a keyword in a text config file and restart the service.
Add ProtectSystem=full in a service config file, and the service and all processes it makes can only "read"/usr and/etc enforced by capabilities. So even if the service is compromised, the hacker can't modify these directories, even if the hacker are able to execute code with root privileges. http://www.freedesktop.org/sof...
Also "ProtectHome=" makes the service unable to read/home, so that no information stealing can take place.
Perhaps the best thing about these features and the many other systemd features like those, are that they can be enabled by either upstream or the distro makers, so that the end user doesn't have to anything in order to improve the system security. It will simply mean improved security and "defense-in-depth" as deafault on systemd distros.
systemd's logging system is a huge improvement over old legacy style text logs. It has more early boot logs since it can log while still in initramsfs, and with kdbus it will probably get even earlier and late logging; the goal is "metal-to-metal" logging.
Having structured and indexed logfile (called journal) is a huge improvement in many ways; it allows for rich meta-data like monotonic timestamps, high precision time stamps, UUID's, exe file names and paths, and incredible easy and powerful sorting and filtering with tools like "systemctl".
If you try to add meta-data like monotonic timestamps in flat text files, they become very long and cluttered, making them hard to read for humans.
Another problem with flat text files are the fact that watch scripts depends on the exact wording of the daemon output strings; if the developers changes the wording, third party scripts will fail. In a perverted sense, the exact wording have become a API that cannot easily be changed or extended. Not so with systemd; it has a stable API and lots of language bindings. It is easy to make a watch script that targets the stable field's.
Some CLI examples: I have used full length options for readability and since systemd have excellent bash completion for everything, it doesn't involve much more typing.
journalctl --boot -1 --priority err
Show all log entries from previous boot only, that have log level "error".
Show only messages generated by the kernel USB subsystem that have log level "warning"
journalctl --field _PID
The "--field" option makes systemctl show all values of the following journal field. In this case it will show a list of all PID's that have ever written to the journal. Want to see every executable that have ever generated log output, substitute _PID with _EXE. Notice the underscore. Field values with underscores have kernel guarantee for being correct.
It is also easy to track two services that you suspect are causing each other problems:
1) If a daemon keeps failing, systemd just keeps restarting it. Admins prefer to be notified so that they can fix the root problem.
systemd doesn't restart crashed daemon unless configured to do. It is also really smart about restarting daemons with rate limiting and timers and what not. systemd can distinguish between manually stopped daemons, and those who have been SIGHUP'ed or those with a unclean exit code.
2) If there is a problem with/etc/fstab, systemd will not allow the system to boot, and gives no reason for the failure. Admins prefer the system boot, and send a message. That way they have a running system, and can fix the problem.
Yes, systemd stops and goes into emergency mode if some hard disk in fstab doesn't show up. This is the right behavior. You can really mess up a system if you allow it to boot with missing mount points. SysVinit and similar init systems may allow booting of a broken system without any notification, but that is simply buggy behavior.
systemd does complain loudly about missing entries in fstab, a quick "journalctl -b -p err" would show that.
Mounting devices with "nofail" in fstab will allow systemd to continue to boot even if the devices are missing, since that implies the admin knows the system will be all right despite missing discs.
Number of executables which can parse systemd journal log files: 1 Number of executables which can parse traditional log files: >10000
Single points of failure are rarely a good idea.
systemd's journal is an open standard with a stable API and many language bindings. There already exist independent journal readers; they are easy to make.
Personally I don't care if there was forty trillions programs that could read legacy style text logs. If they don't provide the same power and ease of use as systemctl, I won't bother using any of them.
And the sad fact is, that old style text logging and parsing has several fundamental problems. They have a chaotic and messy structure where the actual wording of the error messages have become an API, so if a program changes the wording of its logging strings, it will break all kind of watch scripts.
Legacy style text logs don't have any rich meta data like monotonic time stamps etc. And if you try to extend the content of the log files they become more and more unreadable for humans, and it will break watch scripts.
There are many problems with text logs and as time goes by, and systems dump more and more info in the log files, the more these problems will be exposed.
I am fully aware that the systemd-hating techno-Luddites will deny that there are any problems with text logs, just like they will deny there are any problems with SysVinit. Everything is perfect and can't be improved according to them.
So sure, go ahead and use an unmodified SysVinit for the next 30 years too together with syslog text files. But don't complain that somebody else are tackling these problems like systemd does.
Why do you think you need to modify vi to edit systemd config files? All systemd config files are just text files.
I don't. It's a metaphor, you flid.
If I'd said "do I need to resolder my amplifier to connect different speakers in" would that have confused you less, or more?
Ah, so it was a made up story about systemd simply because you don't have the technical insight or knowledge about systemd to give are real example.
systemd requires modifications to many other programs. Or do you deny that?
Like what? You do know that backwards compatibility was a primary design goal for systemd, so that it worked as a drop in replacement for SysVinit/Upstart. You don't have to modify your programs to work on a systemd distro, it will read SysVinit scripts just fine, and understand syslog style logging too.
That developers are starting to use systemd features, is simply because systemd help upstream projects solve real world problems. systemd is all about making things work better on Linux, for both the end users, distro makers, and developers. This is why it has gained such widespread popularity and adoption.
And you don't have to modify vi to edit their config files. That's one of the things that worries me - systemd needs modifications to all manner of other things..
Why do you think you need to modify vi to edit systemd config files? All systemd config files are just text files.
The basic lack of knowledge about systemd among those who dislike it is simply embarrassing for the Linux community; it is like people have forgot what a "man" page is, that sometimes you actually have to read up on stuff in order to understand it.
Seriously, try reading up on systemd: It is cool new Linux tech with lots of exceptionally fine features: http://www.freedesktop.org/wik...
As I understand it, it bundles a large number of services into a single process, which takes place of the init daemon.
That is just wrong. Please read up upon the systemd project before having strong opinions on its design. Don't rely on people foaming at their mouth with rage for information on how systemd actually works. In the future, all major Linux distros will use systemd, so it is prudent to actually read and understand it. This is a good starting point: http://www.freedesktop.org/wik...
What I don't get is why it isn't split up into multiple processes. All the same functionality could be provided by having a simple core init daemon that loads a set (perhaps a small set) of child processes. (...)
What's even more surprising is that someone with some sense hasn't done exactly that:
First, systemd is of course split up in multiple processes each running with their own PID.
Second, in those case where there is e.g. kernel feature integration, systemd follows the most logical way to design a system. The reason why you don't see a systemd re-implementation done in hundreds of little independent modules, is that is a bad design with a huge overhead, when a module needs to talk with 3 other modules, that again needs to talk to 3 other modules every time a daemon request whether it eg. have more cgroup slices available.
So systemd is designed the way it is because it is meant to solve real world problems better than anything else out there, not be a show case of some dogmatic design philosophy.
What about systemd trying to do too much? Ie, someone earlier said it was great that systemd did ntp and dhcp, which seems ridiculous to me; if those services had problems then get better services, don't just wrap them up into systemd. Were those written as examples of systemd services to be emulated, or do the systemd devs really think it's their job to subsume services?
Interesting problem; if systemd had taken existing sNTP and DHCP clients, modified them so they fitted the systemd user case, the systemd developers would have been accused of "subsuming" other projects.
I think it is important to understand why systemd made a sNTPv4 and a DHCP client; in both cases it was user requests, and it was all about OS containers. Most sNTP and DHCP clients are made for stand alone systems, but the OS container density on a system is between 10 to 100 times that of a system running VM's.
That means a server, instead of booting 5 VM's will perhaps boot 250 OS containers. That is 250 instances of Fedora/CentOS/Debian that all wants a DHCP lease and syncing time at the same time. Reducing the time for getting a DHCP lease means significant time savings. In this case systemd developers improved DHCP connections times by reducing the time spent in getting a lease by a factor of 1000. Very cool.
As it is now, you can now boot an entire Linux OS container from zero in 100ms, including getting a DHCP lease. That again means Linux OS containers on demand.
As you can see the DHCP client and server is implemented as a library, meaning everybody can use their work for their own super fast DHCP implementation.
Of course, no one is forced to use systemd's versions of sNTP or DHCP. Their versions are made for speed, not for features.
I work on servers with systemd as the init system. Yes, it's quite possible to run a server with it. It does things that in fact make much more sense for a desktop. It's not terrible, but it's moving away from the simplicity and modularity we've come to expect.
I would say that out-of-the-box cgroups and kernel capabilities are making extremely much sense on servers. Being able to put hard limits on a service's CPU/IO/networking can only be a good thing, same with having defense in depth, by eg. preventing a service process/or any of its children/ from ever getting any privilege escalation (NoNewPrivileges). Combine it it with PrivateTmp=, and white-listing of what dir's it can read or write and you get some real hardening of the system in a very easy way.
Same with reliable killing processes, having a total supervision chain, including PID1 itself, being able to restart crashed processes, not by simplistic means, but using rate limiting, and perhaps based on exit signals too (only restart on unclean exit signals etc).
Regarding simplicity, then I am the opinion that the old legacy script based init systems where more "crude" and "primitive" rather than simple, and their total lack of features isn't so much a virtue, than a real downside to their use; even basic features had to be hacked and bolted on top of SysVinit.
I do agree though, that systemd is a rather hefty piece of software to understand, doing things in new ways, and lots of documentation to read. It also sucks to discard knowledge about e.g. boot sequences, and relearning everything again. But looking back, there was a lot of new tech that seemed extremely complex to begin with, that these days seem trivial, so I guess some of the seeming complexity of systemd will disappear once people "get it".
Regarding modularity; people may argue all day long that systemd isn't "really modular". But the point is in many ways moot; there is no real substitute for systemd's udev or logind or journald (syslog doesn't do all what journald does and vice versa), so what did it matter if systemd increased its internal complexity by supporting other modules than these; there simply haven't materialized any alternative despite years of warning from upstream projects.
Another thing I like about systemd and its wide acceptance in all major distros, is that it is a long needed reduction in needless fragmentation, being able to share knowledge about doing certain things on so many different distros is a boon.
So it should be a piece of cake to show me the patch, but you failed. Perhaps you have no idea what is what.
Look at the changelog numbers. Each number after the release number points to a specific patch. "2.88dsf-53.4" decodes as upstreams version 2.88. "53.4" the fourth patch set to the version 53 (usually one patch per version). So "2.88dsf-42" or "2.88dsf-53.4" refers to specific patches.
You ARE confused. Please do apt-get source sysvinit and point me to a patch that addresses a bug in the upstream code (hint, there isn't one).
An RFE is in no sense a bug.
What the patches DO show is startpar being added in. That is, the ability for the init to happen in parallel.
But note, I don't advocate staying with the old unimproved sysvinit forever, just until a truly superior solution that doesn't try to own the world is ready to go.
Have a look at the SysVinit changelog. There have been 53 commits since 2.88 was released years ago. Sure some of them are Debian specific, some are startpar, but others are not. http://metadata.ftp-master.deb...
Dismissing RFE's as "not bugs" may mean dismissing request for making SysVinit work with other programs or take advantage of important new features. Thinking that init can live in its own little time bubble while the rest of the system evolves is wrong.
I am not talking about bugs in SysVinit scripts used by daemons, but bugs in SysVinit itself. As you can see both Debian, RHEL, SUSE etc. all carry bug patches against the 2.88 release of SysVinit, none of them have made it back to upstream SysVinit. Notice how all development on SysVinit and releases stopped when upstream distros like SUSE, Ubuntu and Red Hat changed their init to Upstart.
And lets forget RFE's (request for enhancments) bugs; there simply aren't any work being done in that regard either, so they will languish away in the bug trackers too.
Again, sweep those problems under the carpet if they offend your eyes, but be assured that the reality of things will become apparent as time goes by.
Yes, there are alternative non-systemd distros out there, but if people don't start fixing the backlog of problems facing non-systemd distros, it is a question on how long they will survive. Being in denial of all the problems non-systemd distros are facing will only accelerate this.
Thinking that everything can go on as before without development and coordination is a failure in analyzing the situation.
Slashdot Mirror
Until some key functionality used by people is no longer available in that distro due to decisions made upstream to no longer support the code base, or other dependencies.
If I use KDE - which I do - then packages for that become unavailable at some point in Slackware given the above. That means I will be forced to use systemd if I want to continue using KDE; which also means I will have to change distributions, assuming Slackware remains systemd free, as well.
First, KDE like all other main DE's are officially committed to supporting non-systemd distros and BSD. The only ones believing otherwise are alarmist systemd-detractors.
Second, the KDE component mentioned in the rather whining blog, isn't a central component, but just a login/display manager. There are other options to use.
Third, the reason why SDDM hasn't got CK support is quite understandable; KDE doesn't have big corporate sponsors, they are volunteers and are stretched to the limit regarding developers. Investing costly developer resources in using a dead and deprecated module like CK is simply insane.
But here is what KDE/Gnome developers and many others have said for years: it is up to the non-systemd distros to support upstream projects, just like the systemd distros does. Don't like systemd software, fine, but develop your own software stack so that upstream projects work on your distro.
Yes it will suck for small non-systemd distros that they just can't leech software development from the big commercial distros anymore. But the answer to that isn't trolling every systemd thread about how bad systemd allegedly is (not so credible to hear from non-users you know), but to get organized! Why is it that you only hear from systemd-dislikers in systemd threads? Why don't you create your own _positive_ community that is about creating cross distro non-systemd software? Why no "New SysVinit alliance created" threads?
The small non-systemd distros will have to cooperate for the first time in Linux history; if they play "every distro for itself", they will sink.
Not trivial. Not easy. Not freedom of choice.
No, things won't be easy for the non-systemd distros. Some of the development needed in order to have even some feature parity with systemd isn't trivial either (cgroups etc). But there is a freedom of choice, the point is that the non-systemd distros and their users are solely responsible for creating such choices.
That is simply a lie.
It is almost tragic so badly the non-systemd users like you are analyzing the situation. I really like systemd, but have no problems with people not using it, and in fact wished that systemd had even a tiny bit of competition.
If the non-systemd crowd don't understand that systemd actually both work, is good, and have compelling features, you will never be able to make an alternative to it. You won't even be able to have status quo. Know your enemy and all that.
The community is not forming around systemd. Systemd is being rammed down our throats by one company.
systemd had hundreds of contributors before it was used in any long term stable Linux distro like RHEL7. So many developers started to drool when they saw the systemd feature list; it presented much of what many people have longed for in a Linux init system. So yes, systemd was quick to gather a community and is now probably one of the largest Open Source projects when it comes to developers.
systemd is simply superior to SysVinit in every way which is why all the major distros adopted so quickly. It simply solve a lot of real world problems and makes life easier for both upstream developers, distro makers and end users.
For those who think SysVinit style init systems is what Linux should be using the next 30 years, there is Slackware. It is a nice general purpose distro that is very traditional.
So nobody is forced to use systemd if they don't want to.
Newer versions of GNOME (3.8 and after?) rely on a DBus API of systemd's logind component, for reasons I've never seen adequately explained.
The talk of forcing all cgroup interactions to go through systemd would in effect make anything that interacts with cgroups or cpusets such as hwloc, TORQUE, and SLURM rely on systemd. I can't imagine that the developers of hwloc, TORQUE, and SLURM are especially happy about that.
That there can only be one cgroup manager at the time is caused by the cgroups developers decision to make a unified hierarchy tree with only one canonical manager instead of exposing cgroups fs directly to end users. systemd is just an example of such a manager. If you don't use systemd, you can just use another cgroups manager instead.
Regarding SLURM, they are of course starting to integrate systemd in their project. I assume most other cgroups projects are doing the same.
> It's not like the journal format is some state secret. It's documented
> and there are already several journal parsers to choose from.
Please explain http://lwn.net/Articles/468049...
> From the FAQ:
That LWN article is 3 years old and very outdated. The systemd developers was still developing the journald in those days, so they didn't want to freeze the API etc. it until they thought it was ready.
The journald log file format have been stable for a very long time now. Here is the developer info and documentation:
http://www.freedesktop.org/wik...
There are already independent journald readers and several log watch programs that query the journald directly.
Most tellingly; rsyslog can now read systemd journals directly. No need to forward syslog messages to it anymore if you use it as a log sink. It can read and write journald log files directly.
Here is a list over stable API's in systemd:
http://www.freedesktop.org/wik...
They are not "options", but field names in the systemd journal.
So journalctl is querying the "database" directly for the values in the "_KERNEL_SUBSYSTEM" field that again contains fields like usb, pci, etc., that again have log entries.
"journalctl -F (tab)" will show you all possible main field names. Selecting eg. "journalctl -F _KERNEL_SUBSYSTEM (tab)" will show the the possible values:
sound
hid
pci_bus
acpi
watchdog
usb
pci
pnp
scsi
vc
clockevents
(snip)
You can basically "tab" your way to every log entry since they are indexed, and every log entry can be selected and shown by exactly which part of the system that generated them. It is an incredible powerful feature. It also allow you to generate on-thefly log entry lists of every PID/GID/Hostname/executable/service name/etc. that have ever written to the log file. Just press tab and all the values appear instantly.
The field names starting with _underscores have Kernel guarantee of not being faked.
At least with journald you can have logging done just binary, just text or both types simultaneousl
False. You cannot log only to text with systemd. And who wants twice the I/O (binary and text) to appease the systemd folks when text logs have been not only the defacto standard, but a rudimentary part of the UNIX philosophy. There are several other reasons I don't like systemd ( try to chroot to a broken system and tell me how much fun that is if the system is a systemd system ) but binary logging with no text only option is arrogant and a show stopper for me as well.
Of course you can have text only log files. Just tell journald not to make any journal files, and forward log messages to rsyslog. It is trivial to do.
Btw, did you know that rsyslog was started because of the inherent limitations of flat text files. These limitations is why all Unix/Linux Enteprise central logging solutions involve some kind of database (Splunk, rsyslog with db-driver modules etc).
Really, systemd's logging solution is seriously cool. It is worth a serious try out.
That is all nice and good until journalctl hangs on you, or you can even reach a command line because systemd has insists that the GUI configuration has priority is more important than setting up virtual terminals early in the boot process.
You got it all backwards; systemd provides outstanding early boot support, including VT's, especially because it starts from initramfs even before the root-filesystem is mounted.
The systemd journal is an open standard with a stable API and many language bindings, so there already exist alternative readers.
There are no realistic scenarios where a systemd log file can't be read. They can be copied just like files to another machine one way or another, or the machine can be booted with a rescue disc
In spite of that, you give a good example of how really cryptic journalctl can be.
journalctl --output short-monotonic --boot -u NetworkManager.service -u chronyd.service
short-monotonic? --boot ? Why not --output snakes-n-oil???
The systemctl syntax is extremely easy to both use and understand. Yes, you will have to read a man page before using it, but then again, the only intuitive interface is the nipple, everything else is learned. It is trivial in comparison to learning regex, but much more efficient.
I see you find "--boot" and "short-monotonic" cryptic. That is probably because they are features that doesn't exist in traditional flat file log files (and more or less impossible to implement). But with systemd, every boot is marked in the journal with an unique ID, so it is trivial to select certain boot sequences. Really hard to do reliable with a regex.
Monotonic timestamps is a meta-data time stamp in every log entry. The monotonic time counter starts from zero at every boot, so that every hardware, kernel and service initialization can be followed with an easy time delta. Here is a short monotonic log snippet; notice how time is incrementing.
[ 1.586450] lhost kernel: hidraw: raw HID events driver (C) Jiri Kosina
[ 1.586648] lhost kernel: usbcore: registered new interface driver usbhid
[ 1.586747] lhost kernel: usbhid: USB HID core driver
[ 1.586867] lhost kernel: drop_monitor: Initializing network drop monitor service
[ 1.587025] lhost kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
[ 1.587148] lhost kernel: TCP: cubic registered
[ 1.587253] lhost kernel: Initializing XFRM netlink socket
[ 1.587456] lhost kernel: NET: Registered protocol family 10
[ 1.587714] lhost kernel: mip6: Mobile IPv6
[ 1.587807] lhost kernel: NET: Registered protocol family 17
[ 1.588196] lhost kernel: Loading compiled-in X.509 certificates
What about 'cat /usr/adm/SYSLOG' which stands for 'conCATenate' /usr/adm/SYSLOG. Or if I want to use grep;
grep /usr/adm/SYSLOG error | mailx -s "Errorlog" youradmin@youremailhere.com
(or /var/log/SYSLOG for that newer variation).
You can still use "grep" and all the other standard Linux tools in conjunction with "systemctl". "systemctl" just act as a powerful log filter so often grep isn't needed.
I like your example for grep'ping for the word "error". That way you would miss both "Error" (no "i" switch") and "Warning" "Critical" "Failure" and what not. For systemd you could just use "systemctl -p err" and you would have found all critical log entries.
And why call everything a 'service'. It's called a 'daemon' in unix. Daemons provide services. Services are windows things. To me systemd is the toy for the noobs and wantabe cool ubuntu-ites that have no experience in the thick of server land. And second, I don't find systemd an elegant solution at all. systemv-init, now that is elegant, with the various run levels, and system states.
Service vs. daemon=bike shedding
You may imagine that syste
You are happy about Red Hat's hostile takeover of Linux?
Red Hat have always been a corner stone of Linux. If it wasn't for Red Hat, Linux wouldn't exist today. They have fueled money and developer time into almost all aspects of Linux over the decades, and their lawyers have fought off so many patent trolls and entities trying to harm Linux. AFAIK, Red Hat have been one of the biggest kernel contributors for decades too, so they have had a huge influence on both its design and features.
So I think the "let's hate Red Hat" fad among systemd haters is puerile, stupid and anti-Linux.
And I think even less about the tin foil hat conspiracy theories about mysterious Red Hat forces, working behind the scenes hell bent on taking over Linux.
The accusation of Red Hat's intention of "hostile takeover of Linux" is always vague. How exactly are RH controlling Linux by being a contributor among many when developing systemd? Is there some kind of mind control in the source code, or is it done by chem trails?
Why is RH Kernel and glibc contributions not a problem, while their systemd contributions are?
All the major distros have changed to systemd simply because it is superior in every way to the existing alternatives. systemd simply solves real world problems for both distro makers, upstream developers and end users in a much better way than anything else.
What a rose tinted look at the past. I was there too, but I don't remember the way you do at all.
The main reason why Linux took of was that it solved real world problems in an efficient way.
So many OS's have been made in order to follow some dogmatic doctrine about microkernels/"everything is a file" etc., instead of focusing on how to solve problems for its users, but not Linux.
So Linux made things possible for admins, developers and ISP's that was otherwise difficult or expensive. In short, Linux made money and increased productivity. That is also why its users fueled developer hours and money back into the Linux community. The LAMP stack wasn't made by a lone hero hacker, but a collective of business' and developers that saw an opportunity for making money or increase efficiency and getting a competitive edge.
The LAMP stack was never designed by the cartoonish Unix design interpretation of "only do one thing", in fact almost no program of any complexity is, yet this was what was driving Linux forward.
systemd is just yet another change in Linux that follows the old Linux philosophy on focusing on solving real world problems for its users instead of riding a "Unix/Posix" hobby horse.
If you are beginning to have problems with how Linux have always evolved, then it is you who are beginning to act old, not Linux.
Keeping Linux in an eternal 1990's time freeze where nothing must be changed will simply kill of Linux just like all the other OS's that forgot both their users and how to adapt to the times.
Wait, so now we aren't setting read/write status in fstab anymore?
Yes, for file systems. Notice this is for a single running daemon. Think of it like a kind of sand boxing that prevents the service and all processes it spawns to e.g. read/write /boot /home /root etc.
Since it is build on "capabilities", those directories will be inaccessible even if the process is exploited. It is seriously cool stuff that systemd makes it easy to use.
Those facilities are not given by systemd. They are given by cgroups and other security features. Systemd just has a way for you to specify them for services, it's not doing all of the heavy lifting.
systemd makes it easy for both end users, upstream developers and distro makers to take advantage of those advanced kernel features; no low level hacking needed, no home made bash scripts, no endless hacking needed to make three dissimilar sub-systems talk together by fragile scripts.
With systemd strong hardening features comes ready to use out of the box. Just add a simple "keyword=value" in a text config files, and everything works.
The reason why kernel features like "capabilities" and "cgroups" have existed with very little or no use on general purpose distros, is exactly because they are very hard to use on systems that aren't designed like systemd.
It is the same with the new Kernel IPC system "kdbus". Systemd will make it easy for upstream projects to use kernel IPC, while SysVinit and similar won't.
You don't have any knowledge about how systemd restarts services. You haven't read the systemd documentation, but instead seem to rely on some random systemd haters wrong info about how systemd restarts services. Think about that.
systemd doesn't restart services unless told so. And it can be quite intelligent about restarts, distinguishing between several different ways the service was terminated and making conditionally restarts depending on the service's exit signal and combining it with rate limiters.
Try reading the "Restart=" section here to get a glimpse of the many options:
http://www.freedesktop.org/sof...
It's not available on OpenBSD.
But it will be. The "systemBSD" and "Uselessd" projects are just a warm up.
Of course all the BSD's will get modern init systems like systemd before this decade is over.
I like the fact that systemd's wholesale acceptance by all major Linux distros means much less fragmentation in both the way the Linux OS is managed and the easy that upstream projects are now able to support advanced features in a distro agnostic way.
I also like the fact that it exposes advanced kernel features like "cgroups" and "Capabilities" and make them easy to use; just add a keyword in a text config file and restart the service.
Add ProtectSystem=full in a service config file, and the service and all processes it makes can only "read" /usr and /etc enforced by capabilities. So even if the service is compromised, the hacker can't modify these directories, even if the hacker are able to execute code with root privileges.
http://www.freedesktop.org/sof...
Also "ProtectHome=" makes the service unable to read /home, so that no information stealing can take place.
Perhaps the best thing about these features and the many other systemd features like those, are that they can be enabled by either upstream or the distro makers, so that the end user doesn't have to anything in order to improve the system security. It will simply mean improved security and "defense-in-depth" as deafault on systemd distros.
systemd's logging system is a huge improvement over old legacy style text logs. It has more early boot logs since it can log while still in initramsfs, and with kdbus it will probably get even earlier and late logging; the goal is "metal-to-metal" logging.
Having structured and indexed logfile (called journal) is a huge improvement in many ways; it allows for rich meta-data like monotonic timestamps, high precision time stamps, UUID's, exe file names and paths, and incredible easy and powerful sorting and filtering with tools like "systemctl".
If you try to add meta-data like monotonic timestamps in flat text files, they become very long and cluttered, making them hard to read for humans.
Another problem with flat text files are the fact that watch scripts depends on the exact wording of the daemon output strings; if the developers changes the wording, third party scripts will fail. In a perverted sense, the exact wording have become a API that cannot easily be changed or extended.
Not so with systemd; it has a stable API and lots of language bindings. It is easy to make a watch script that targets the stable field's.
Some CLI examples: I have used full length options for readability and since systemd have excellent bash completion for everything, it doesn't involve much more typing.
journalctl --boot -1 --priority err
Show all log entries from previous boot only, that have log level "error".
journalctl --since -5m
Show log entries generated the last 5 minutes.
journalctl --follow --unit smartd.service
Follow (tail) the smartd daemons log output.
journalctl _KERNEL_SUBSYSTEM=usb --priority warning
Show only messages generated by the kernel USB subsystem that have log level "warning"
journalctl --field _PID
The "--field" option makes systemctl show all values of the following journal field. In this case it will show a list of all PID's that have ever written to the journal. Want to see every executable that have ever generated log output, substitute _PID with _EXE. Notice the underscore. Field values with underscores have kernel guarantee for being correct.
It is also easy to track two services that you suspect are causing each other problems:
journalctl --output short-monotonic --boot -u NetworkManager.service -u chronyd.service
This will show the log entries for NetworkManager and a sNTP client from the current boot, and show the output with monotonic timestamps. Nice.
As I understand it:
1) If a daemon keeps failing, systemd just keeps restarting it. Admins prefer to be notified so that they can fix the root problem.
systemd doesn't restart crashed daemon unless configured to do. It is also really smart about restarting daemons with rate limiting and timers and what not. systemd can distinguish between manually stopped daemons, and those who have been SIGHUP'ed or those with a unclean exit code.
Look here under the "Restart=" option for more details:
http://www.freedesktop.org/sof...
2) If there is a problem with /etc/fstab, systemd will not allow the system to boot, and gives no reason for the failure. Admins prefer the system boot, and send a message. That way they have a running system, and can fix the problem.
Yes, systemd stops and goes into emergency mode if some hard disk in fstab doesn't show up. This is the right behavior. You can really mess up a system if you allow it to boot with missing mount points. SysVinit and similar init systems may allow booting of a broken system without any notification, but that is simply buggy behavior.
systemd does complain loudly about missing entries in fstab, a quick "journalctl -b -p err" would show that.
Mounting devices with "nofail" in fstab will allow systemd to continue to boot even if the devices are missing, since that implies the admin knows the system will be all right despite missing discs.
Number of executables which can parse systemd journal log files: 1
Number of executables which can parse traditional log files: >10000
Single points of failure are rarely a good idea.
systemd's journal is an open standard with a stable API and many language bindings. There already exist independent journal readers; they are easy to make.
Personally I don't care if there was forty trillions programs that could read legacy style text logs. If they don't provide the same power and ease of use as systemctl, I won't bother using any of them.
And the sad fact is, that old style text logging and parsing has several fundamental problems. They have a chaotic and messy structure where the actual wording of the error messages have become an API, so if a program changes the wording of its logging strings, it will break all kind of watch scripts.
Legacy style text logs don't have any rich meta data like monotonic time stamps etc. And if you try to extend the content of the log files they become more and more unreadable for humans, and it will break watch scripts.
There are many problems with text logs and as time goes by, and systems dump more and more info in the log files, the more these problems will be exposed.
I am fully aware that the systemd-hating techno-Luddites will deny that there are any problems with text logs, just like they will deny there are any problems with SysVinit. Everything is perfect and can't be improved according to them.
So sure, go ahead and use an unmodified SysVinit for the next 30 years too together with syslog text files. But don't complain that somebody else are tackling these problems like systemd does.
I don't. It's a metaphor, you flid.
If I'd said "do I need to resolder my amplifier to connect different speakers in" would that have confused you less, or more?
Ah, so it was a made up story about systemd simply because you don't have the technical insight or knowledge about systemd to give are real example.
systemd requires modifications to many other programs. Or do you deny that?
Like what?
You do know that backwards compatibility was a primary design goal for systemd, so that it worked as a drop in replacement for SysVinit/Upstart. You don't have to modify your programs to work on a systemd distro, it will read SysVinit scripts just fine, and understand syslog style logging too.
That developers are starting to use systemd features, is simply because systemd help upstream projects solve real world problems. systemd is all about making things work better on Linux, for both the end users, distro makers, and developers. This is why it has gained such widespread popularity and adoption.
And you don't have to modify vi to edit their config files. That's one of the things that worries me - systemd needs modifications to all manner of other things..
Why do you think you need to modify vi to edit systemd config files? All systemd config files are just text files.
The basic lack of knowledge about systemd among those who dislike it is simply embarrassing for the Linux community; it is like people have forgot what a "man" page is, that sometimes you actually have to read up on stuff in order to understand it.
Seriously, try reading up on systemd: It is cool new Linux tech with lots of exceptionally fine features:
http://www.freedesktop.org/wik...
As I understand it, it bundles a large number of services into a single process, which takes place of the init daemon.
That is just wrong. Please read up upon the systemd project before having strong opinions on its design. Don't rely on people foaming at their mouth with rage for information on how systemd actually works. In the future, all major Linux distros will use systemd, so it is prudent to actually read and understand it. This is a good starting point:
http://www.freedesktop.org/wik...
What I don't get is why it isn't split up into multiple processes. All the same functionality could be provided by having a simple core init daemon that loads a set (perhaps a small set) of child processes. (...)
What's even more surprising is that someone with some sense hasn't done exactly that:
First, systemd is of course split up in multiple processes each running with their own PID.
Second, in those case where there is e.g. kernel feature integration, systemd follows the most logical way to design a system. The reason why you don't see a systemd re-implementation done in hundreds of little independent modules, is that is a bad design with a huge overhead, when a module needs to talk with 3 other modules, that again needs to talk to 3 other modules every time a daemon request whether it eg. have more cgroup slices available.
So systemd is designed the way it is because it is meant to solve real world problems better than anything else out there, not be a show case of some dogmatic design philosophy.
What about systemd trying to do too much? Ie, someone earlier said it was great that systemd did ntp and dhcp, which seems ridiculous to me; if those services had problems then get better services, don't just wrap them up into systemd. Were those written as examples of systemd services to be emulated, or do the systemd devs really think it's their job to subsume services?
Interesting problem; if systemd had taken existing sNTP and DHCP clients, modified them so they fitted the systemd user case, the systemd developers would have been accused of "subsuming" other projects.
I think it is important to understand why systemd made a sNTPv4 and a DHCP client; in both cases it was user requests, and it was all about OS containers. Most sNTP and DHCP clients are made for stand alone systems, but the OS container density on a system is between 10 to 100 times that of a system running VM's.
That means a server, instead of booting 5 VM's will perhaps boot 250 OS containers. That is 250 instances of Fedora/CentOS/Debian that all wants a DHCP lease and syncing time at the same time.
Reducing the time for getting a DHCP lease means significant time savings. In this case systemd developers improved DHCP connections times by reducing the time spent in getting a lease by a factor of 1000. Very cool.
As it is now, you can now boot an entire Linux OS container from zero in 100ms, including getting a DHCP lease. That again means Linux OS containers on demand.
http://www.phoronix.com/scan.p...
https://plus.google.com/+TomGu...
As you can see the DHCP client and server is implemented as a library, meaning everybody can use their work for their own super fast DHCP implementation.
Of course, no one is forced to use systemd's versions of sNTP or DHCP. Their versions are made for speed, not for features.
I work on servers with systemd as the init system. Yes, it's quite possible to run a server with it. It does things that in fact make much more sense for a desktop. It's not terrible, but it's moving away from the simplicity and modularity we've come to expect.
I would say that out-of-the-box cgroups and kernel capabilities are making extremely much sense on servers. Being able to put hard limits on a service's CPU/IO/networking can only be a good thing, same with having defense in depth, by eg. preventing a service process /or any of its children/ from ever getting any privilege escalation (NoNewPrivileges). Combine it it with PrivateTmp=, and white-listing of what dir's it can read or write and you get some real hardening of the system in a very easy way.
Same with reliable killing processes, having a total supervision chain, including PID1 itself, being able to restart crashed processes, not by simplistic means, but using rate limiting, and perhaps based on exit signals too (only restart on unclean exit signals etc).
Regarding simplicity, then I am the opinion that the old legacy script based init systems where more "crude" and "primitive" rather than simple, and their total lack of features isn't so much a virtue, than a real downside to their use; even basic features had to be hacked and bolted on top of SysVinit.
I do agree though, that systemd is a rather hefty piece of software to understand, doing things in new ways, and lots of documentation to read. It also sucks to discard knowledge about e.g. boot sequences, and relearning everything again. But looking back, there was a lot of new tech that seemed extremely complex to begin with, that these days seem trivial, so I guess some of the seeming complexity of systemd will disappear once people "get it".
Regarding modularity; people may argue all day long that systemd isn't "really modular". But the point is in many ways moot; there is no real substitute for systemd's udev or logind or journald (syslog doesn't do all what journald does and vice versa), so what did it matter if systemd increased its internal complexity by supporting other modules than these; there simply haven't materialized any alternative despite years of warning from upstream projects.
Another thing I like about systemd and its wide acceptance in all major distros, is that it is a long needed reduction in needless fragmentation, being able to share knowledge about doing certain things on so many different distros is a boon.
So it should be a piece of cake to show me the patch, but you failed. Perhaps you have no idea what is what.
Look at the changelog numbers. Each number after the release number points to a specific patch. "2.88dsf-53.4" decodes as upstreams version 2.88. "53.4" the fourth patch set to the version 53 (usually one patch per version). So "2.88dsf-42" or "2.88dsf-53.4" refers to specific patches.
You ARE confused. Please do apt-get source sysvinit and point me to a patch that addresses a bug in the upstream code (hint, there isn't one).
An RFE is in no sense a bug.
What the patches DO show is startpar being added in. That is, the ability for the init to happen in parallel.
But note, I don't advocate staying with the old unimproved sysvinit forever, just until a truly superior solution that doesn't try to own the world is ready to go.
Have a look at the SysVinit changelog. There have been 53 commits since 2.88 was released years ago. Sure some of them are Debian specific, some are startpar, but others are not.
http://metadata.ftp-master.deb...
Dismissing RFE's as "not bugs" may mean dismissing request for making SysVinit work with other programs or take advantage of important new features. Thinking that init can live in its own little time bubble while the rest of the system evolves is wrong.
I am not talking about bugs in SysVinit scripts used by daemons, but bugs in SysVinit itself. As you can see both Debian, RHEL, SUSE etc. all carry bug patches against the 2.88 release of SysVinit, none of them have made it back to upstream SysVinit. Notice how all development on SysVinit and releases stopped when upstream distros like SUSE, Ubuntu and Red Hat changed their init to Upstart.
And lets forget RFE's (request for enhancments) bugs; there simply aren't any work being done in that regard either, so they will languish away in the bug trackers too.
Again, sweep those problems under the carpet if they offend your eyes, but be assured that the reality of things will become apparent as time goes by.
Yes, there are alternative non-systemd distros out there, but if people don't start fixing the backlog of problems facing non-systemd distros, it is a question on how long they will survive. Being in denial of all the problems non-systemd distros are facing will only accelerate this.
Thinking that everything can go on as before without development and coordination is a failure in analyzing the situation.