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.
I don't like the ideal of binary log files, but I can get behind everything else.
Well, just use rsyslog/syslog-ng like you always have. That way you have the usual flat file text logs while having all the other benefits of using systemd.
Anybody having working with computers for a long time tends to be vary of binary formats. I have had a lot of bad experiences with binary formats over the decades. But using systemd's journal made me realize that what I really want is config files that are text based, and having binary data isn't such a big deal as long as it is an open standard and the tools are both standard and of high quality. systemd provides me with exactly that.
All the standard Linux text tools like "grep" and "wc" etc. works perfectly together with systemd's binary journal, by using the standard Linux concept of piping, so nothing is lost, but many new features like having monotonic timestamps are gained.
have nothing against binary log files per sé, but they should not be the primary and only option. Instead of hanging rsyslog after journald, I'd rather see it reversed, first plain-text logging to syslog and eventually piped to binary logging afterwards (or parallel to both, whatever). That way, all the info is still available in case the binary log files get corrupted for one reason or another, and people still have their easily searchable binary logfiles.
Also it'd make it easier for other remote-logging tools to hook in with the already existing syslog infrastructure than hook on to journald.
It doesn't make sense to go from text to binary format as default. Remember that a key point in having a structured and indexed binary log file is that you can keep all kinds of rich meta data info in each log entry, like monotonic timestamps, high precision time markers, system UUID's, etc.. If you put all those meta data fields directly into the flat text file, every log entry line will become insanely long and complex, making it much less human readable.
The present solution with systemd making all the local log entries in binary form, and then use rsyslog for converting it to legacy flat file format, or placing it a database while preserving the rich meta-data is a really good solution with few drawbacks and many great advantages. In this way, systemd is actually enhancing rsyslog's capabilities. Using either journald-gateway or rsyslog to remote logging can now preserve the rich meta data too.
I'm not against also having binary logs, I can see the potential benefits. However, it makes no sense whatsoever to just chuck them into a bunch of loose files anyway. Doing that doesn't solve the organizational problem of having a bunch of files lying around. The same data that goes into the text logs should go into an RDBMS. Then I could really do something with the data. systemd's binary log files actually represent a failure in the form of a missed opportunity, and not a rational evolution.
Further, there's no reason why the logging daemon should be tied to the init daemon at all. If this init daemon is so wonderful, reliable, and good at starting processes in order, then it should be able to kick off any logging daemon, wait until it is running and accepting log messages, and then continue booting, perhaps after delivering the boot time log messages to the logging daemon. Want to argue that we need a new syslogd with binary logging? Fine. But where's the argument that it should be married to init?
Good questions. The reasons are complicated, but I will try as best as I can.
When journald was made it was constrained by several design parameters: it should have total backward compatibility for those needing this, it couldn't require that any userspace program should be rewritten in order to work with it, including syslog implementations like rsyslog. It should simply be a drop in replacement, giving people the opportunity to use its enhanced features if they wanted to, or just use the usual rsyslog setup they always had used. It should also be as simple and fast as possible. In fact, the journal more or less an append text file with other newline delimiters and an added index.
And because journald worked with syslog, people could use rsyslog for all their advanced database logging needs. In short, journald makes it flexible for those who have advanced needs, instead of tying them down to a particular solution. Unlike rsyslog, journald isn't a log sink (and hopefully never will be).
All in all, making sweeping and complex changes like using a real RDBMS as a logging back end wasn't an option. Also, such RDBMS solutions already exist in a mature state in e.g. rsyslog, so there was no need either.
There are other design constrains concerning logging on Linux. At the moment everything goes into
So AFAIK, it isn't easy to make a early-boot-log helper that hands over logging to syslog when it is done, at least not in a lossless way and certainly not if the helper logs are meant to be incorporated into the syslog flat text files (which is why eg. dmesg is a separate log file).
As for logging being "married" to init, the main argument was, that in order to have first class service and process management, you need a matching first class logging system. In order to have early and late boot log messages, the init system have to be aware of a lot of low level system stuff, and cooperate extensively with the logging system. They could have used rsyslog and changed it so it worked like the journald works, but that would have tied all systemd Linux distros to a particular syslog implementation.
Having them working together also makes it trivial to attach log messages to a service check.
Are binary log files a necessity of the systemd design? Absolute not. But then again, people who prefer flat text files for logs can just use rsyslog/syslog-ng as they always have. The binary log files are optional. But the binary, structured and indexed journal log do solve so many limitations of flat text files that I am glad it exist as an option. The systemd journal really is a joy to use.
The distributions should be wary of putting all their eggs in the freedesktop.org basket. Not all systems are desktops, and they shouldn't rely on desktop features at the expense of their own roles.
Dude, freedesktop.org is just a code repo like github, so they also host e.g. an OpenCL compiler. Sure, the site is also used for inter distro discussions and informal work groups, but implying that systemd is a desktop thing only since it hosted on freedesktop.org is just laughable.
When you got the time, please read up on the systemd project to see what it is all about:
This is an excellent starting point: http://www.freedesktop.org/wik...
Or that there are no known bugs to fix and haven't been in ages.
That's what happens when you follow the KISS principle.
Just look at the Debian SysVinit bug tracker. Of course there are bugs. I don't claim that there are serious showstopper bugs, but they are there, and sometimes they are even fixed. Feeding such bug fixes back to the upstream project is normal Linux practice, but for the last several years, such bugfixes haven't been mainlined with upstream SysVinit, making SUSE/RH the de facto Upstream now, and both those distros are about to outphase SysVinit.
I don't say that eg. GNU/SysVinit is understaffed is a unsolvable problem. But what I do say is, that those who will continue to use SysVinit have the responsibility to make and maintain all the necessary code themselves for being able to do so, including helping out SysVinit.
The non-systemd camp can no longer rely on paid developers from commercial distros solving all their problems. There is a long list of stuff that needs to be done, right now and in the near future in order to run a SysVinit distro without it degrading slowly and falling hopelessly behind in features.
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.
New York... when civilization falls apart, remember, we were way ahead of you. - David Letterman
