Binary logs are also far more secure, but I guess that doesn't matter to you.
Oh horseshit, what you speak of is security by obscurity. By the same token you could say gzipped logs are more secure than non-compressed logs. When reading a binary format is well understood it's not an increase in security it's merely pig-headed obfuscation for the sake of itself, a sentence that describes the intentions and outcome of the entire systemd project perfectly.
You seems to misunderstand how the signed logs works in systemd: the logs are perfectly readable by anyone with the right permissions. There is no encryption going on, only secure signing. (striclty speaking it isn't signing, or hash' chaining)
There is no signing key on the computer that can be extracted. The key is only used once to sign the first log segment, then removed from the system, the next signing key is generated on the basis of the first and so on. systemd makes cryptographically secure sealing called "Forward secure sealing". The concept is old in the crypto world, here is an introduction to how it is done: http://lwn.net/Articles/512895...
If you're reliant on trusting the logs of a system that you think might have been compromised you're already shafted. If an intruder can edit your plain text logs then they can edit everything else on the system as well, including binary ones; hacking is generally more sophisticated than vim/var/log/daemon.log dd dd dd:wq. There's nothing inherently unhackable about binary logs and if your box is rooted your only real option is to burn the hard drives to the ground and reinstall.
That simply isn't true. If a hacker gets access to gpg encrypted mails, he can't read or alter them undetected if he doesn't have the key. Same with systemd journal logs with "Forward secure sealing". This isn't hash'es but strong crypto security like gpg. The concept is quite old in the crypto world: Here is an introduction to FSS: http://lwn.net/Articles/512895...
Binary logs are also far more secure, but I guess that doesn't matter to you.
That has to be most bizarre justification I've yet read. How exactly is a binary log more secure?
The systemd logs have better security in a number of ways; there is "Forward Secure Sealing" (FFS) that allows for cryptographically ensured verification, even if root is compromised on the host. It also have a integrated logfile verification, much less strong, but "free" and default.
Also, journald have kernel guarantees that log entries are made by the exact binary/program the log entry claims. On syslog, any program can claim anything in the text log file. Of course, the kernel guarantee is only truly secure with FFS turned on, but it is an improvement never the less; on a syslog system, the hacker only have to alter a text file. On a systemd machine, he has to have exploit booth root and journald, and then alter the logfiles in such a way that the internal log verification still works. Not trivial at all.
is for me that it isn't interoperable. Please correct me when I'm wrong, but AFAIK systemd never did anything to create standards their new functionality is compatible with. Instead they only support linux APIs. I recognize that their needs exceed POSIX, but their current approach "lets make everything a hard dependency" is -to be polite- hacky. It doesn't have to be an official ISO standard, a simple document that ensures exchangeability of components inside systemd, and perhaps even makes systemd cross-platform.
The systemd developer have explained, and explained why they did what they did; they have made stable interfaces; http://www.freedesktop.org/wik...
They have explained what interfaces that can easily be made on non-systemd distros or even other OS's: http://www.freedesktop.org/wik...
There are systemd libraries and what not, and lots of documentation.
That systemd is a Linux only thing, is because it uses kernel features that are only available to Linux like cgroups, "namespaces" and "kernel capabilities" and soon, kdbus. If eg. Hurd or OpenBSD or Mac OSX implemented such features, systemd could be ported. Of course, *BSD would never allow LGPL licensed software to become a critical part of their core OS, so the point is rather moot though.
Seriously, what do people want? That nothing must be using Linux specific kernel features ever, because that is unfair to other OS's?
It is trivial to read systemd journal files from a boot media. They can also just be copied to a USB stick or whatever and moved to another system for analyzing.
Every log entry line has rich meta-data, including machine name, UUID etc, so you will never be in doubt on which machine the log was generated on
You can forward journald messages directly to syslog-ng just by adding a line to/etc/systemd/journal.conf
rsyslog can now natively read (and write) systemd journal files, and make the usual text logs if that is what you want (or use forwarding). http://www.rsyslog.com/doc/imj...
the journald daemon listen to/dev/log where all log messages from all programs are directed to, and the journald then forward these messages to another syslog. It will strip them of meta data first. Since the journald can get log messages from early boot before even the root filesystem is mounted, this is actually an enhancement of just using syslog.
The journald journal is primarily an append based system, so it is quite resistant to file corruption. The journald files are basically text files with another line delimiter and an index. journald has integrated logfile-verification and can therefore discover if something is wrong (it will then log-rotate etc).
What if I want a straight text log file that requires no other tools? Why would anyone even have a binary log on a *nix system?
If you want binary log files that require tools to dump them to text, use Windows.
I want systemd's binary logfiles because they are so much better than old style text log files. Having rich meta data with every log entry is simply too good a thing to have. Small things like monotonic time stamps are really handy, the ability to filter messages based on field values is simply awesome.
systemd's journal is really cool stuff. Don't be prejudiced against it and try it out in earnest.
I'm a Linux noob, but Wikipedia says systemd's logfile is binary. I know one of the big complaints has been that it doesn't use plain text files the way Unix systems traditionally have.
If you are new to Linux, the systemd bianry logfiles are great; they are much easier to deal with than learning and memorizing a lot of "grep" switches.". Not that you can't use all the standard Linux text tools with the systemd logfiles, but you don't _have_ to.
Since the systemd journal has a stable API to accessing log file information, it is now actually possible to make a GUI log viewer that works properly.
I was skeptical about binary log files too, until I actually tried systemd properly and read up upon how systemd's journal functions. I am totally converted now, and will never go back to simple text log-files. Systemd's log implementation is simply so much better.
Only showing binary logs with systemd tools is a misfeature of the type "exposing the implementation". Userland requires a UI, and it's bad UI, and frankly bad Unix.
You don't have to use systemd tools to read systemd journal files. There already exist alternative readers, and systemd provides both a journal library and Python/Ruby/etc bindings for accessing the logs.
Now then, I hear you can somehow configure systemd to echo a copy of its logs to rsyslog. But, and maybe I'm just a fool with poor GoogleFu, but I tried for a couple hours to get this working and only found company for misery on the mailing lists.
If any systemd fans can point us to a quick-n-easy HOWTO on getting text [r]syslog working under systemd, then by all means shut a few of us up. Tell us how there's plenty of documentation too, we'll all hang our heads and wander away.
There are two ways of doing it: having rsyslog reading(and writing directly to the systemd journal: http://www.rsyslog.com/doc/imj... I think this is the default behavior these days with modern versions. More info here:
Else check : "/etc/systemd/journald.conf" And set: "ForwardToSyslog=yes"
(only for syslog-ng or rsyslog versions that can't read the journal directly)
It is trivially easy to read systemd journal logs on remote machines. Also, there already exist several journal readers since the log format is defined and have an API. So it is easy to have many different log readers installed for the "belt and suspender" types. Even rsyslog reads journal files these days.
That is of course wrong. If you have a POSIX compliant system, you have binary logs in/var/log. On Linux they are usually called "utmp" and "wtmp" and they keep track of logins and logoffs. You use the "last" tool to read these binary logfiles. utmpx is actually a formal part of Unix.
I don't agree about logging. I think the systemd journal is a great improvment over legacy style old text dumps. Stuff like "journalctl -b -p err" (show only messages from this boot at log level "error"). So useful, so simple. Or "journalctl --since -15m" that shows the last 15 minutes of logging. Or "journalctl -f -u firewalld.service" that just tails the firewall service. There is bash completion of everything, from parameters to servicenames. There is kernel guarantee the entries aren't faked (all those field starting with underscore), meaning that if cups is writing "lpt0 on fire" in the journal, you can see if its a fake or real. (on syslog anything can pretend to be cups). systemd is also able to gain logging info from when the system is only in the "initramfs" stage (systemd lives in initramfs during boot and then jumps to rootfs), before the root system is even mounted, something rsyslog can only dream of.
The journal is primarily an append only system (basically a text file with another newline separator + index), so it is quite robust against RW corruptions.
systemd's primary design goal is simplicity; it isn't a log sink like rsyslog, and won't have db drivers. It is however easy to export its content in e.g. JSON format by the journald-gateway, or let rsyslog, who can natively read journal files, convert it into any supported format etc. So using Splunk is trivial these days.
Monit and systemd aren't completely overlapping, so you can still run Monit on top of systemd, that way systemd can restart Monit if it fails:-). But it is a major selling point for systemd, that it comes with integrated service supervision "out-of-the-box" and in easy way too. Just add some keywords to a textfile, and away you go. Because systemd uses cgroups, it can track all processes and their child processes with ease, so its supervision abilities are quite awesome. To simplify both projects; systemd has the technological superiority when it comes to the low level supervision stuff, while Monit has all the high level monitoring stuff, like graphs etc.
OS containers predates systemd deployment. But systemd intend to make them much better: systemd intend to make OS containers that runs unmodified on top of the host OS. As it is now, there isn't much security, but that is the next round: unmodified, secure OS containers; run a standard Ubuntu and a standard Fedora on top of CentOS (and make them socket activated too). Nobody else have such high ambitions.
Regarding RH. They hardly need to make themselves "relevant" since their revenue actually keeps on growing despite the international crisis. Not many other Linux distro vendors experience that. No slant intended against Canonical, but AFAIK they still loose money every year.
Besides, while Lennart Poettering is employed by RH, systemd have long been a multi-distro collaboration, with half a dozen developers from different distros and companies that have git commit access. There has been more than 600 independent contributors too. So it is a huge open source project, not a Red Hat solo show.
I know the pain of changing systems and workflow. It is understandable that people working close to systems have an aversion against changing stuff that works for them. Few people get paid for the luxury of learning new technology.
But systemd is actually a very rare watershed moment in Linux where some old fundamentals are being changed, and IMHO, systemd is an improvement in every area it touches; it is a better init system, provides awesome logging, exposes hard to use kernel features like cgroups, "capabilities(7)" and "namespaces", and make them a breeze to use: just ad a single keyword in a text config file, restart the service and you can enable cgroups features or prevent privilege escalation etc.
Total service supervision, including systemd itself. Really advanced rate limiting and service restart features, like "don't restart the service if manually shut down", or "don't try to restart the service more than 3 times within 10 minutes".
You can drop hard to maintain code if your service needs to drop privileges after startup, and just use systemd's inbuilt features.
start a new OS container in seconds to play around with, etc.
I can only encourage you to start learning systemd properly; at the moment all the commercial and non-commercial LTS distros will switch to systemd. I think even Slackware will change to systemd down the road, since there is practically zero development going on in the non-systemd camp at the moment.
Take it a bit at the time; there is so much new to learn. Try a systemd distro like Fedora 20's KDE spin, or Debian "Jessie" (should be in beta by now), perhaps in a VM. systemd really is the future, and it really have a lot to offer.
I can see what you mean, but it wasn't intended as such.
I've been developing software on Linux for years and using it for longer. There is no need for the console terminal emulator to be part of systemd; none whatsoever
Well, it is the opinion of David Hermann that it exactly belongs in systemd. Since he is the author of kmscon and consoled, I doubt that anybody knows more about VT's than he does at the moment. Since the vast majority of Linux distros are going to be systemd based in the future, it makes so much sense to make systemd optimized VT's. Just the fact that systemd is the only game in town when it comes to multi-seat is justification alone.
- you say as much yourself. Systemd is becoming a single package that does everything but your windowing system, this is a terrible state of affairs. No matter how much they claim that it's modular it's really not, everything ends up coupled together for no good reason that it's easier for Lennart to think about when it is.
Really, what is the problem with systemd gaining features like consoled? It takes nothing away for the tiny minority of non-systemd distros; they can still use kernel VT's if they want, or use kmscon if they care about features and bug fixing. Why are non-systemd user so obsessed and possessive about the systemd code? Use it if you want, fork it and use it they way you want, or make an alternative.
I can't really take your comment seriously about systemd features being coupled together with no good reason. I have yet to see a systemd-opponent that have any real experience with systemd or even have read all the documentation and man pages.
The systemd developers give good and detailed reasons for why they do what they do, but systemd-opponents seemingly prefer to get their systemd information from the many tin foil hat, swivel eyed, systemd-hating, loony blogs, instead of actually reading up on the subject.
Don't like systemd? Fine by me, just remember that it is all up to you to make the non-systemd distro working. So don't whine about what systemd developers does or doesn't, but concentrate on making your own alternative. Just attacking systemd gets you nowhere.
Why do you like systemD? What's so great about it?
I could probably write pages on how great systemd is, but the bottom line is, that systemd is "Linux-done-right!" in all aspects it covers: It is by far the most advanced, feature rich init-system available for Linux (and probably Unix too).
There are several reasons that make systemd a great project; Its developers (Poettering et al) have really studied all parts extremely well before they started coding, so all the systemd functionality is really well thought out, and implemented in a superb way; everything is an improvement, often by a huge distance. They have dealt with all the hard problems like backwards compatibility, no flag day, service dependencies etc, by solving them in the most correct manner instead of just patching things up, so systemd pc's have a fast boot, not because systemd is optimized for speed, but because by doing system and service initialization in the most predictable and correct way, leads to a boot speedups as a side effect.
Ubuntu's Upstart was an important, well coded, pioneering effort for improving Linux init systems and a serious improvement over SysVinit, but it also demonstrated, that by staying too close to traditional init systems, you didn't get rid of their inherit problems.
Just the logging alone is worth everything; it provides superb and powerful log filter capabilities that enhances the standard Linux text tools like "grep", but since it is structured, indexed and have a programmatic API, it will also mean that GUI developer now can make a functional GUI for viewing logs on Linux. So there is great stuff for the hardcore sysadmin, and the new Linux user at the same time.
systemd makes using advanced kernel feature like cgroup a breeze; no need to read advanced tutorials or cooking up bash scripts, just ad a single keyword like "CPUShares=20%" in the service config file, and systemd will use cgroup to ensure that that process will never get more than 20% CPU time on one CPU. It is so easy, and no coding required.
I could go on, but I recommend that you study systemd yourself: http://www.freedesktop.org/wik... Lots of great documentation there, that will make you think; this is great stuff!
I guess you don't know much about systemd and kernel VT's. The explanation is quite long and technical, but the bottom line is that systemd provides needed infrastructure to allow eg. user switching in user space for VT's, and nothing else really does, so of course all the advanced features are going to be systemd only; nothing else provides what it does.
Furthermore, what some distros want is to turn off kernel space VT's completly, so something else in user space need to manage such VT's, whether the init system is SysVinit or systemd. What this is all about, is that systemd is adding support for this so you can use user space consoles in early boot for logging in or having en emergency shell and what not.
Hermann has made all the necessary tools for the non-systemd distros, so they can enjoy most of the benefits. I have a hard time imagining that ultra-conservative distros like Slackware are going to use it though, so they can just continue to use kernel VT's.
The good news for those distros is that the systemd developer, David Hermann, have provided full support for user space VT/console support for non-systemd distros, by using ksmcon and other software pieces he have developed. Whether they will use it is another thing.
It is pretty sad to see, that after so many comments nobody really has a clue about what the story is about, and what is happening in the Linux kernel. The kernel VT system has been considered a monstrosity by kernel developers the last decade and everyone is of the opinion that it should be used to user space.
The finally a really smart guy actually attacks and solve the problem. His name is David Herrmann, and he has tirelessly worked on this for years. Systemd distros will get the full support of his research, simply because almost all Linux distros are using, or a going to use systemd. But don't worry, he has provided rich support user space VT's on non-systemd Linux distros, by eg. "ksmcon" https://github.com/dvdhrm/kmsc...
In short, no need for the systemd opponents to get their panties in a bunch; they can either use Hermanns user space tools, or pretend there isn't a problem and use the present kernel system.
For the rest of us who really likes systemd, this is great news. Thanks to Hermann's work, there will be much better console support for early boot debugging, better security, better keyboard and language handling etc.
And this is why every sysadmin hates your cabal: It feels like the evil empire taking over. "Don't resist, and it will hurt less."
But we will resist. Go to hell.
If you don't like systemd, don't work with Linux as a professional SA. Like or not, systemd is the new way of dealing with Linux for all the major commercial Linux distros. This is just stating the basic facts, not a threat, not gloating; people will just have to deal with the reality of things, and systemd have been a reality coming for a long time.
Yes, some are getting frustrated by eg. CentOS. But that sad fact is, that so many Linux SA's doesn't even have a basic grasp of systemd, having made no serious study of it, or even worked with it on early systemd distros like Fedora. So SA's are deploying systemd Linux distros now without any real experience with systemd, nor having spend eg. at least +20 hours with the extensive documentation, despite the obvious fact that systemd was coming to town. SA experience is a help, but it is no substitute for actually studying how systemd works and how to debug with it.
It is so easy to blame systemd for all new problems, and no one seems to blame themselves for not doing their homework properly before using it. It is so convenient not having to study systemd because it is "bad"/made by the evil empire/the cause of all problems/is just like windows/not the Unix way/ and what not.
Resist all you want, I and the rest of the world don't care about your heroic abstaining of using a new init system; Just deal with the consequences of your choices if you are ejected out of the IT industry for lacking needed skills; I have seen it so many times during the last 3 decades; every time the IT industry shifted, some blamed the progress for being bad and refused to learn anything new. They all had mighty principles for why new stuff was bad, and they would all rant endlessly about old ways were better than the new ways, and when forced to deal with new stuff, they would blame the technology, not their lacking skills for all the problems they encountered. Don't be one of them.
Everything that exists to deal with things that happen because an inexperienced GUI user might do something stupid (like manually change the system time).
Last I used systemd (Fedora), the dependency tree for packages is such that packages like NetworkManager are required by systemd. Do a minimal CentOS 7 install and see just how many packages you can remove from the system without having systemd be removed because of dependencies. Then, look at the list of remaining packages and you'd have to be a complete liar to tell us that none of them are GUI-centric.
That has nothing to do with systemd, but is about how Fedora or CentOS choose to make their distro. And you are right that they often make too many things interdependent, even Fedora have been aware of this for some time. This is what Fedora.next is all about; being able to have a really small core, and then add blocks as needed, with different designs and dependencies for Workstation and Server editions. That work will carry over in RHEL and CentOS in the future.
But it is trivial to let systemd be a part of the really small base core of the OS, so it is not to blame for pulling in many packages, and it certainly doesn't have any inherent need for pulling in GUI packages.
But, with systemd dragging in a bunch of packages that many would consider to be only truly useful when a GUI is installed, the actual footprint is probably larger.
On that same note, perhaps there is a "systemd way" to do what you are trying to do with ifconfig or lspci?
What packages are you talking about? Are you sure you don't just speculate that it must be so because you don't know anything about systemd?
systemd has superb CLI functionality with everything having bash-completion. Try "systemctl --(tab)" and all CLI options will appear. systemctl stat(tab) kd(tab) (systemctl status kdm.service). There is tab completion for every service running.
Or "journalctl _T(tab)k(tab)" (journalctl _TRANSPORT=kernel). There is tab completion for every field in the journal.
The systemd tools are simply pure joy to use from the command line.
Remember, that systemd can replace several other programs like cron, at, syslog, sNTP, dhcp-cleints, etc. so its foot print is quite small, even with all features included.
And since systemd is made to run on embedded devices, it can be configured at compile time to be extremely small. It is trivial for the distro maintainers to exactly control all the systemd defaults and all options it provides, so they can tailor it exactly for their need, including to remove most of its features.
Yeah, more functionality that I don't want or need. A binary log system is beyond stupid. It is Microsoft registry levels of stupid.
What a lame non-technical argument. Well, the truth probably is that you actually haven't studied journald's logging features, and are relying on some ranting anti-linux hate blog on how someone _thinks_ it work.
The brutal technical truth is, that systemd's way of logging is always an improvement over the old legacy syslog way of doing things.
There is nothing that can be with unstructured text dumps that can't be done with journald's structured and indexed journal. But here are a huge amount of things that can be done with the journal, that are outright impossible to do with syslog text logs.
You obviously do care. Tell me, what are you getting for your shilling? It must be doing something for you else you wouldn't be doing it.
I represent the new default way of doing things in Linux, since systemd will be used by almost all Linux distros in the near future. systemd has won a wholesale victory everywhere, so who would pay for "shilling" against a tiny minority of techno-reactionary Linux users who are unable to even get developers enough to maintain the necessary infrastructure for non-systemd distros?
So what you are saying, to get the original functionality back you have to add more complexity?
Do you systemd fanboys ever stop and listen to yourselves?
I thought I had made it easy to understand, but let me repeat and rephrase; if you for some reason have a user case for using text logs and therefore use rsyslog or similar, you get a slightly more complicated system since journald is now part of the logging process; but, you also get extra functionality, since journald can provide logging info that stand alone syslog systems can't.
Or to rephrase yet another time; you don't just get the old functionality back by combining systemd and syslog, you get more functionality.
But please, don't use systemd if you don't want to, I don't care at all, as long as you systemd haters fixes your own problems like ConsoleKit and udev, instead of attacking everyone else for not doing the work you ought to do.
journald delivers ascii logs in real time, you just have to use a syslog daemon like you always have anyway.
Sure. So now I get an additional log daemon which doesn't feed logs back upstream. Explain how this is simplifying my system.
I don't understand what you mean by "doesn't feed logs back upstream". Rsyslog or similar behave just as they always have.
You get a more complex system in order to get new features, in this case; journald+syslog=more logging info than syslog alone.
The above solution is only necessary for crazy legacy setups and log sinks, and people who doesn't yet know how good the journal actually is.
I don't think there are real user cases beyond that. Text logs are simply obsolete on Linux now, since the journal is so superior and can do everything that old text logs do, and much, much more on top of that.
journald=heaps more logging info than old stand alone syslog. journald=still more logging info than journald+syslog.
Thinking that text logs was the best solution, turned out just to be a wrong concept. The gains of choosing a slightly more complex binary format, turned out to vastly more than the tiny problem of needing a special reader.
So drop your worries and try out systemd; give it a good workout, I think you end up liking it.
The awesome structured and indexed log file format has a stable API and structure
Odd, so does a syslog. And you can still use tools to read it. Indexed files could be built from it if you had that much logging done. And since systemd has no option to output the ascii log in realtime, you have to use the tools. If you want to use the body of existing tools which do things with normal log files, you'll now need a FUSE filesystem to treat the binary logs like real logs, or you'll simply be out of date as you read the ascii logs from journald.
journald delivers ascii logs in real time, you just have to use a syslog daemon like you always have anyway.
It would be a stupid function duplication if systemd's journald also could partially act as syslog daemon. While outputting text is easy enough, you would also have to have rate-limiting, log-rotation etc. And it still wouldn't replace a classic syslog daemon because it couldn't be used as a log sink, and once you start to add log sink features, you end up with database drivers in the code and all sorts of filters.
The number one design goal for "journald" was "simplicity". Adding syslog features like text output is contrary to this. (unfortunately many people request such features, but the systemd developers have said no every time).
journald is made to be used in conjunction with syslog and actually enhances it because of its features, the journald simply works as a helper process for syslog if desired. Nothing is taken away as things were before systemd, real time text logs is possible. Nobody is forced to use the binary log files when using systemd.
Those who don't need text log files for legacy reasons, or a log sink, can skip the syslog daemon and rejoice in the power of a structured and indexed log file and just use journald. I think over time, this is what most people will, once they "get" the journal: IMHO, it really is logging done right on Linux, something people have tried to improve with only limited success the last decades.
I don't think it is really possible to make a good hybrid log-file, where some parts are a classic text dump, while the meta data and index is in binary. I think it would a complex and fragile solution. It would be much easier let the classic text tools like "grep" learn to read to binary journal directly (jgrep?). But it really isn't needed; a journal reader like "journalctl" combined with piping solves all such problems, so using the classic text tools on the binary journald is quite possible to do in real time.
Here is an example below: lets assume it is a bash script run by cron every 1 hour: it searches the journal for messages of log level "error" that contains the string "softreset". "journalctl -p err | grep softreset"
As you can see, it isn't a problem using "grep" or "tee" or "sed" or any other classic text GNU tool together with the journal, to do real time inquiries or using them in bash scripts etc.
You have fallen into my trap: So then why did it have to be part of systemd at all? Why couldn't it just be improvements to one of the existing syslog daemons? Answer, NIH.
Because if you want first class service and process management, you need first class logging, and this is exactly what journald does.
You could never do what journald does with classic rsyslog, like living and logging while in initramfs, and then jump over to the main system when the root-fs was mounted, and continue logging while the system booted.
Anyway, that would also restrict systemd logging to a certain syslog daemon. The present solution is a general solution that works with all syslog implementation like syslog-ng and rsyslog etc.
The awesome structured and indexed log file format has a stable API and structure, so it is quite easy for other syslog implementations to read and write in that format. I believe rsyslog have already implemented a reader and some other journald features. So if they want, they too can have all the advantages of rich metadata.
Slashdot Mirror
Binary logs are also far more secure, but I guess that doesn't matter to you.
Oh horseshit, what you speak of is security by obscurity. By the same token you could say gzipped logs are more secure than non-compressed logs. When reading a binary format is well understood it's not an increase in security it's merely pig-headed obfuscation for the sake of itself, a sentence that describes the intentions and outcome of the entire systemd project perfectly.
You seems to misunderstand how the signed logs works in systemd: the logs are perfectly readable by anyone with the right permissions. There is no encryption going on, only secure signing. (striclty speaking it isn't signing, or hash' chaining)
There is no signing key on the computer that can be extracted. The key is only used once to sign the first log segment, then removed from the system, the next signing key is generated on the basis of the first and so on. systemd makes cryptographically secure sealing called "Forward secure sealing". The concept is old in the crypto world, here is an introduction to how it is done:
http://lwn.net/Articles/512895...
If you're reliant on trusting the logs of a system that you think might have been compromised you're already shafted. If an intruder can edit your plain text logs then they can edit everything else on the system as well, including binary ones; hacking is generally more sophisticated than vim /var/log/daemon.log dd dd dd :wq. There's nothing inherently unhackable about binary logs and if your box is rooted your only real option is to burn the hard drives to the ground and reinstall.
That simply isn't true. If a hacker gets access to gpg encrypted mails, he can't read or alter them undetected if he doesn't have the key. Same with systemd journal logs with "Forward secure sealing". This isn't hash'es but strong crypto security like gpg. The concept is quite old in the crypto world:
Here is an introduction to FSS:
http://lwn.net/Articles/512895...
That has to be most bizarre justification I've yet read. How exactly is a binary log more secure?
The systemd logs have better security in a number of ways; there is "Forward Secure Sealing" (FFS) that allows for cryptographically ensured verification, even if root is compromised on the host. It also have a integrated logfile verification, much less strong, but "free" and default.
Also, journald have kernel guarantees that log entries are made by the exact binary/program the log entry claims. On syslog, any program can claim anything in the text log file. Of course, the kernel guarantee is only truly secure with FFS turned on, but it is an improvement never the less; on a syslog system, the hacker only have to alter a text file. On a systemd machine, he has to have exploit booth root and journald, and then alter the logfiles in such a way that the internal log verification still works. Not trivial at all.
is for me that it isn't interoperable. Please correct me when I'm wrong, but AFAIK systemd never did anything to create standards their new functionality is compatible with. Instead they only support linux APIs. I recognize that their needs exceed POSIX, but their current approach "lets make everything a hard dependency" is -to be polite- hacky. It doesn't have to be an official ISO standard, a simple document that ensures exchangeability of components inside systemd, and perhaps even makes systemd cross-platform.
The systemd developer have explained, and explained why they did what they did; they have made stable interfaces;
http://www.freedesktop.org/wik...
They have explained what interfaces that can easily be made on non-systemd distros or even other OS's:
http://www.freedesktop.org/wik...
There are systemd libraries and what not, and lots of documentation.
That systemd is a Linux only thing, is because it uses kernel features that are only available to Linux like cgroups, "namespaces" and "kernel capabilities" and soon, kdbus. If eg. Hurd or OpenBSD or Mac OSX implemented such features, systemd could be ported. Of course, *BSD would never allow LGPL licensed software to become a critical part of their core OS, so the point is rather moot though.
Seriously, what do people want? That nothing must be using Linux specific kernel features ever, because that is unfair to other OS's?
It is trivial to read systemd journal files from a boot media. They can also just be copied to a USB stick or whatever and moved to another system for analyzing.
Every log entry line has rich meta-data, including machine name, UUID etc, so you will never be in doubt on which machine the log was generated on
You can forward journald messages directly to syslog-ng just by adding a line to /etc/systemd/journal.conf
rsyslog can now natively read (and write) systemd journal files, and make the usual text logs if that is what you want (or use forwarding). http://www.rsyslog.com/doc/imj...
the journald daemon listen to /dev/log where all log messages from all programs are directed to, and the journald then forward these messages to another syslog. It will strip them of meta data first.
Since the journald can get log messages from early boot before even the root filesystem is mounted, this is actually an enhancement of just using syslog.
The journald journal is primarily an append based system, so it is quite resistant to file corruption. The journald files are basically text files with another line delimiter and an index. journald has integrated logfile-verification and can therefore discover if something is wrong (it will then log-rotate etc).
What if I want a straight text log file that requires no other tools? Why would anyone even have a binary log on a *nix system?
If you want binary log files that require tools to dump them to text, use Windows.
I want systemd's binary logfiles because they are so much better than old style text log files. Having rich meta data with every log entry is simply too good a thing to have. Small things like monotonic time stamps are really handy, the ability to filter messages based on field values is simply awesome.
systemd's journal is really cool stuff. Don't be prejudiced against it and try it out in earnest.
I'm a Linux noob, but Wikipedia says systemd's logfile is binary. I know one of the big complaints has been that it doesn't use plain text files the way Unix systems traditionally have.
If you are new to Linux, the systemd bianry logfiles are great; they are much easier to deal with than learning and memorizing a lot of "grep" switches.". Not that you can't use all the standard Linux text tools with the systemd logfiles, but you don't _have_ to.
Since the systemd journal has a stable API to accessing log file information, it is now actually possible to make a GUI log viewer that works properly.
I was skeptical about binary log files too, until I actually tried systemd properly and read up upon how systemd's journal functions. I am totally converted now, and will never go back to simple text log-files. Systemd's log implementation is simply so much better.
Only showing binary logs with systemd tools is a misfeature of the type "exposing the implementation". Userland requires a UI, and it's bad UI, and frankly bad Unix.
You don't have to use systemd tools to read systemd journal files. There already exist alternative readers, and systemd provides both a journal library and Python/Ruby/etc bindings for accessing the logs.
Now then, I hear you can somehow configure systemd to echo a copy of its logs to rsyslog. But, and maybe I'm just a fool with poor GoogleFu, but I tried for a couple hours to get this working and only found company for misery on the mailing lists.
If any systemd fans can point us to a quick-n-easy HOWTO on getting text [r]syslog working under systemd, then by all means shut a few of us up. Tell us how there's plenty of documentation too, we'll all hang our heads and wander away.
There are two ways of doing it: having rsyslog reading(and writing directly to the systemd journal:
http://www.rsyslog.com/doc/imj...
I think this is the default behavior these days with modern versions. More info here:
Else check :
"/etc/systemd/journald.conf"
And set:
"ForwardToSyslog=yes"
(only for syslog-ng or rsyslog versions that can't read the journal directly)
Great, so what happens when journald breaks>?
It is trivially easy to read systemd journal logs on remote machines.
Also, there already exist several journal readers since the log format is defined and have an API. So it is easy to have many different log readers installed for the "belt and suspender" types.
Even rsyslog reads journal files these days.
Binary logs are anti-*nix. Rebut that.
That is of course wrong. If you have a POSIX compliant system, you have binary logs in /var/log. On Linux they are usually called "utmp" and "wtmp" and they keep track of logins and logoffs. You use the "last" tool to read these binary logfiles. utmpx is actually a formal part of Unix.
I don't agree about logging. I think the systemd journal is a great improvment over legacy style old text dumps. Stuff like "journalctl -b -p err" (show only messages from this boot at log level "error"). So useful, so simple. Or "journalctl --since -15m" that shows the last 15 minutes of logging. Or "journalctl -f -u firewalld.service" that just tails the firewall service. There is bash completion of everything, from parameters to servicenames. There is kernel guarantee the entries aren't faked (all those field starting with underscore), meaning that if cups is writing "lpt0 on fire" in the journal, you can see if its a fake or real. (on syslog anything can pretend to be cups).
systemd is also able to gain logging info from when the system is only in the "initramfs" stage (systemd lives in initramfs during boot and then jumps to rootfs), before the root system is even mounted, something rsyslog can only dream of.
The journal is primarily an append only system (basically a text file with another newline separator + index), so it is quite robust against RW corruptions.
systemd's primary design goal is simplicity; it isn't a log sink like rsyslog, and won't have db drivers. It is however easy to export its content in e.g. JSON format by the journald-gateway, or let rsyslog, who can natively read journal files, convert it into any supported format etc. So using Splunk is trivial these days.
Monit and systemd aren't completely overlapping, so you can still run Monit on top of systemd, that way systemd can restart Monit if it fails :-). But it is a major selling point for systemd, that it comes with integrated service supervision "out-of-the-box" and in easy way too. Just add some keywords to a textfile, and away you go. Because systemd uses cgroups, it can track all processes and their child processes with ease, so its supervision abilities are quite awesome.
To simplify both projects; systemd has the technological superiority when it comes to the low level supervision stuff, while Monit has all the high level monitoring stuff, like graphs etc.
OS containers predates systemd deployment. But systemd intend to make them much better: systemd intend to make OS containers that runs unmodified on top of the host OS. As it is now, there isn't much security, but that is the next round: unmodified, secure OS containers; run a standard Ubuntu and a standard Fedora on top of CentOS (and make them socket activated too). Nobody else have such high ambitions.
Regarding RH. They hardly need to make themselves "relevant" since their revenue actually keeps on growing despite the international crisis. Not many other Linux distro vendors experience that. No slant intended against Canonical, but AFAIK they still loose money every year.
Besides, while Lennart Poettering is employed by RH, systemd have long been a multi-distro collaboration, with half a dozen developers from different distros and companies that have git commit access. There has been more than 600 independent contributors too. So it is a huge open source project, not a Red Hat solo show.
I know the pain of changing systems and workflow. It is understandable that people working close to systems have an aversion against changing stuff that works for them. Few people get paid for the luxury of learning new technology.
But systemd is actually a very rare watershed moment in Linux where some old fundamentals are being changed, and IMHO, systemd is an improvement in every area it touches; it is a better init system, provides awesome logging, exposes hard to use kernel features like cgroups, "capabilities(7)" and "namespaces", and make them a breeze to use: just ad a single keyword in a text config file, restart the service and you can enable cgroups features or prevent privilege escalation etc.
Total service supervision, including systemd itself. Really advanced rate limiting and service restart features, like "don't restart the service if manually shut down", or "don't try to restart the service more than 3 times within 10 minutes".
You can drop hard to maintain code if your service needs to drop privileges after startup, and just use systemd's inbuilt features.
start a new OS container in seconds to play around with, etc.
I can only encourage you to start learning systemd properly; at the moment all the commercial and non-commercial LTS distros will switch to systemd. I think even Slackware will change to systemd down the road, since there is practically zero development going on in the non-systemd camp at the moment.
Take it a bit at the time; there is so much new to learn. Try a systemd distro like Fedora 20's KDE spin, or Debian "Jessie" (should be in beta by now), perhaps in a VM.
systemd really is the future, and it really have a lot to offer.
Is condescension your default response?
I can see what you mean, but it wasn't intended as such.
I've been developing software on Linux for years and using it for longer. There is no need for the console terminal emulator to be part of systemd; none whatsoever
Well, it is the opinion of David Hermann that it exactly belongs in systemd. Since he is the author of kmscon and consoled, I doubt that anybody knows more about VT's than he does at the moment. Since the vast majority of Linux distros are going to be systemd based in the future, it makes so much sense to make systemd optimized VT's. Just the fact that systemd is the only game in town when it comes to multi-seat is justification alone.
- you say as much yourself. Systemd is becoming a single package that does everything but your windowing system, this is a terrible state of affairs. No matter how much they claim that it's modular it's really not, everything ends up coupled together for no good reason that it's easier for Lennart to think about when it is.
Really, what is the problem with systemd gaining features like consoled? It takes nothing away for the tiny minority of non-systemd distros; they can still use kernel VT's if they want, or use kmscon if they care about features and bug fixing. Why are non-systemd user so obsessed and possessive about the systemd code? Use it if you want, fork it and use it they way you want, or make an alternative.
I can't really take your comment seriously about systemd features being coupled together with no good reason. I have yet to see a systemd-opponent that have any real experience with systemd or even have read all the documentation and man pages.
The systemd developers give good and detailed reasons for why they do what they do, but systemd-opponents seemingly prefer to get their systemd information from the many tin foil hat, swivel eyed, systemd-hating, loony blogs, instead of actually reading up on the subject.
Don't like systemd? Fine by me, just remember that it is all up to you to make the non-systemd distro working. So don't whine about what systemd developers does or doesn't, but concentrate on making your own alternative. Just attacking systemd gets you nowhere.
Why do you like systemD? What's so great about it?
I could probably write pages on how great systemd is, but the bottom line is, that systemd is "Linux-done-right!" in all aspects it covers:
It is by far the most advanced, feature rich init-system available for Linux (and probably Unix too).
There are several reasons that make systemd a great project;
Its developers (Poettering et al) have really studied all parts extremely well before they started coding, so all the systemd functionality is really well thought out, and implemented in a superb way; everything is an improvement, often by a huge distance. They have dealt with all the hard problems like backwards compatibility, no flag day, service dependencies etc, by solving them in the most correct manner instead of just patching things up, so systemd pc's have a fast boot, not because systemd is optimized for speed, but because by doing system and service initialization in the most predictable and correct way, leads to a boot speedups as a side effect.
Ubuntu's Upstart was an important, well coded, pioneering effort for improving Linux init systems and a serious improvement over SysVinit, but it also demonstrated, that by staying too close to traditional init systems, you didn't get rid of their inherit problems.
Just the logging alone is worth everything; it provides superb and powerful log filter capabilities that enhances the standard Linux text tools like "grep", but since it is structured, indexed and have a programmatic API, it will also mean that GUI developer now can make a functional GUI for viewing logs on Linux. So there is great stuff for the hardcore sysadmin, and the new Linux user at the same time.
systemd makes using advanced kernel feature like cgroup a breeze; no need to read advanced tutorials or cooking up bash scripts, just ad a single keyword like "CPUShares=20%" in the service config file, and systemd will use cgroup to ensure that that process will never get more than 20% CPU time on one CPU. It is so easy, and no coding required.
I could go on, but I recommend that you study systemd yourself:
http://www.freedesktop.org/wik...
Lots of great documentation there, that will make you think; this is great stuff!
I guess you don't know much about systemd and kernel VT's. The explanation is quite long and technical, but the bottom line is that systemd provides needed infrastructure to allow eg. user switching in user space for VT's, and nothing else really does, so of course all the advanced features are going to be systemd only; nothing else provides what it does.
Furthermore, what some distros want is to turn off kernel space VT's completly, so something else in user space need to manage such VT's, whether the init system is SysVinit or systemd. What this is all about, is that systemd is adding support for this so you can use user space consoles in early boot for logging in or having en emergency shell and what not.
Hermann has made all the necessary tools for the non-systemd distros, so they can enjoy most of the benefits. I have a hard time imagining that ultra-conservative distros like Slackware are going to use it though, so they can just continue to use kernel VT's.
The good news for those distros is that the systemd developer, David Hermann, have provided full support for user space VT/console support for non-systemd distros, by using ksmcon and other software pieces he have developed. Whether they will use it is another thing.
It is pretty sad to see, that after so many comments nobody really has a clue about what the story is about, and what is happening in the Linux kernel.
The kernel VT system has been considered a monstrosity by kernel developers the last decade and everyone is of the opinion that it should be used to user space.
The finally a really smart guy actually attacks and solve the problem. His name is David Herrmann, and he has tirelessly worked on this for years. Systemd distros will get the full support of his research, simply because almost all Linux distros are using, or a going to use systemd. But don't worry, he has provided rich support user space VT's on non-systemd Linux distros, by eg. "ksmcon"
https://github.com/dvdhrm/kmsc...
Here is his fosdem talk:
https://archive.fosdem.org/201...
Here is his blog that will tell you more about VT's than you ever knew:
http://dvdhrm.wordpress.com/
Here is a wiki link about VT:
http://en.wikipedia.org/wiki/L...
Here is an old blog post about the problems with the old kernel VT:
http://dvdhrm.wordpress.com/20...
In short, no need for the systemd opponents to get their panties in a bunch; they can either use Hermanns user space tools, or pretend there isn't a problem and use the present kernel system.
For the rest of us who really likes systemd, this is great news. Thanks to Hermann's work, there will be much better console support for early boot debugging, better security, better keyboard and language handling etc.
And this is why every sysadmin hates your cabal: It feels like the evil empire taking over. "Don't resist, and it will hurt less."
But we will resist. Go to hell.
If you don't like systemd, don't work with Linux as a professional SA. Like or not, systemd is the new way of dealing with Linux for all the major commercial Linux distros. This is just stating the basic facts, not a threat, not gloating; people will just have to deal with the reality of things, and systemd have been a reality coming for a long time.
Yes, some are getting frustrated by eg. CentOS. But that sad fact is, that so many Linux SA's doesn't even have a basic grasp of systemd, having made no serious study of it, or even worked with it on early systemd distros like Fedora. So SA's are deploying systemd Linux distros now without any real experience with systemd, nor having spend eg. at least +20 hours with the extensive documentation, despite the obvious fact that systemd was coming to town.
SA experience is a help, but it is no substitute for actually studying how systemd works and how to debug with it.
It is so easy to blame systemd for all new problems, and no one seems to blame themselves for not doing their homework properly before using it.
It is so convenient not having to study systemd because it is "bad"/made by the evil empire/the cause of all problems/is just like windows/not the Unix way/ and what not.
Resist all you want, I and the rest of the world don't care about your heroic abstaining of using a new init system; Just deal with the consequences of your choices if you are ejected out of the IT industry for lacking needed skills; I have seen it so many times during the last 3 decades; every time the IT industry shifted, some blamed the progress for being bad and refused to learn anything new. They all had mighty principles for why new stuff was bad, and they would all rant endlessly about old ways were better than the new ways, and when forced to deal with new stuff, they would blame the technology, not their lacking skills for all the problems they encountered. Don't be one of them.
Everything that exists to deal with things that happen because an inexperienced GUI user might do something stupid (like manually change the system time).
Last I used systemd (Fedora), the dependency tree for packages is such that packages like NetworkManager are required by systemd. Do a minimal CentOS 7 install and see just how many packages you can remove from the system without having systemd be removed because of dependencies. Then, look at the list of remaining packages and you'd have to be a complete liar to tell us that none of them are GUI-centric.
That has nothing to do with systemd, but is about how Fedora or CentOS choose to make their distro. And you are right that they often make too many things interdependent, even Fedora have been aware of this for some time. This is what Fedora.next is all about; being able to have a really small core, and then add blocks as needed, with different designs and dependencies for Workstation and Server editions. That work will carry over in RHEL and CentOS in the future.
But it is trivial to let systemd be a part of the really small base core of the OS, so it is not to blame for pulling in many packages, and it certainly doesn't have any inherent need for pulling in GUI packages.
But, with systemd dragging in a bunch of packages that many would consider to be only truly useful when a GUI is installed, the actual footprint is probably larger.
On that same note, perhaps there is a "systemd way" to do what you are trying to do with ifconfig or lspci?
What packages are you talking about? Are you sure you don't just speculate that it must be so because you don't know anything about systemd?
systemd has superb CLI functionality with everything having bash-completion. Try "systemctl --(tab)" and all CLI options will appear. systemctl stat(tab) kd(tab) (systemctl status kdm.service). There is tab completion for every service running.
Or "journalctl _T(tab)k(tab)" (journalctl _TRANSPORT=kernel). There is tab completion for every field in the journal.
The systemd tools are simply pure joy to use from the command line.
Remember, that systemd can replace several other programs like cron, at, syslog, sNTP, dhcp-cleints, etc. so its foot print is quite small, even with all features included.
And since systemd is made to run on embedded devices, it can be configured at compile time to be extremely small. It is trivial for the distro maintainers to exactly control all the systemd defaults and all options it provides, so they can tailor it exactly for their need, including to remove most of its features.
Yeah, more functionality that I don't want or need. A binary log system is beyond stupid. It is Microsoft registry levels of stupid.
What a lame non-technical argument. Well, the truth probably is that you actually haven't studied journald's logging features, and are relying on some ranting anti-linux hate blog on how someone _thinks_ it work.
The brutal technical truth is, that systemd's way of logging is always an improvement over the old legacy syslog way of doing things.
There is nothing that can be with unstructured text dumps that can't be done with journald's structured and indexed journal. But here are a huge amount of things that can be done with the journal, that are outright impossible to do with syslog text logs.
You obviously do care. Tell me, what are you getting for your shilling? It must be doing something for you else you wouldn't be doing it.
I represent the new default way of doing things in Linux, since systemd will be used by almost all Linux distros in the near future. systemd has won a wholesale victory everywhere, so who would pay for "shilling" against a tiny minority of techno-reactionary Linux users who are unable to even get developers enough to maintain the necessary infrastructure for non-systemd distros?
So what you are saying, to get the original functionality back you have to add more complexity?
Do you systemd fanboys ever stop and listen to yourselves?
I thought I had made it easy to understand, but let me repeat and rephrase; if you for some reason have a user case for using text logs and therefore use rsyslog or similar, you get a slightly more complicated system since journald is now part of the logging process; but, you also get extra functionality, since journald can provide logging info that stand alone syslog systems can't.
Or to rephrase yet another time; you don't just get the old functionality back by combining systemd and syslog, you get more functionality.
But please, don't use systemd if you don't want to, I don't care at all, as long as you systemd haters fixes your own problems like ConsoleKit and udev, instead of attacking everyone else for not doing the work you ought to do.
journald delivers ascii logs in real time, you just have to use a syslog daemon like you always have anyway.
Sure. So now I get an additional log daemon which doesn't feed logs back upstream. Explain how this is simplifying my system.
I don't understand what you mean by "doesn't feed logs back upstream". Rsyslog or similar behave just as they always have.
You get a more complex system in order to get new features, in this case; journald+syslog=more logging info than syslog alone.
The above solution is only necessary for crazy legacy setups and log sinks, and people who doesn't yet know how good the journal actually is.
I don't think there are real user cases beyond that. Text logs are simply obsolete on Linux now, since the journal is so superior and can do everything that old text logs do, and much, much more on top of that.
journald=heaps more logging info than old stand alone syslog.
journald=still more logging info than journald+syslog.
Thinking that text logs was the best solution, turned out just to be a wrong concept. The gains of choosing a slightly more complex binary format, turned out to vastly more than the tiny problem of needing a special reader.
So drop your worries and try out systemd; give it a good workout, I think you end up liking it.
The awesome structured and indexed log file format has a stable API and structure
Odd, so does a syslog. And you can still use tools to read it. Indexed files could be built from it if you had that much logging done. And since systemd has no option to output the ascii log in realtime, you have to use the tools. If you want to use the body of existing tools which do things with normal log files, you'll now need a FUSE filesystem to treat the binary logs like real logs, or you'll simply be out of date as you read the ascii logs from journald.
journald delivers ascii logs in real time, you just have to use a syslog daemon like you always have anyway.
It would be a stupid function duplication if systemd's journald also could partially act as syslog daemon. While outputting text is easy enough, you would also have to have rate-limiting, log-rotation etc. And it still wouldn't replace a classic syslog daemon because it couldn't be used as a log sink, and once you start to add log sink features, you end up with database drivers in the code and all sorts of filters.
The number one design goal for "journald" was "simplicity". Adding syslog features like text output is contrary to this. (unfortunately many people request such features, but the systemd developers have said no every time).
journald is made to be used in conjunction with syslog and actually enhances it because of its features, the journald simply works as a helper process for syslog if desired. Nothing is taken away as things were before systemd, real time text logs is possible. Nobody is forced to use the binary log files when using systemd.
Those who don't need text log files for legacy reasons, or a log sink, can skip the syslog daemon and rejoice in the power of a structured and indexed log file and just use journald. I think over time, this is what most people will, once they "get" the journal: IMHO, it really is logging done right on Linux, something people have tried to improve with only limited success the last decades.
I don't think it is really possible to make a good hybrid log-file, where some parts are a classic text dump, while the meta data and index is in binary. I think it would a complex and fragile solution. It would be much easier let the classic text tools like "grep" learn to read to binary journal directly (jgrep?). But it really isn't needed; a journal reader like "journalctl" combined with piping solves all such problems, so using the classic text tools on the binary journald is quite possible to do in real time.
Here is an example below: lets assume it is a bash script run by cron every 1 hour: it searches the journal for messages of log level "error" that contains the string "softreset".
"journalctl -p err | grep softreset"
As you can see, it isn't a problem using "grep" or "tee" or "sed" or any other classic text GNU tool together with the journal, to do real time inquiries or using them in bash scripts etc.
Logging isn't done by or in PID1.
You have fallen into my trap: So then why did it have to be part of systemd at all? Why couldn't it just be improvements to one of the existing syslog daemons? Answer, NIH.
Because if you want first class service and process management, you need first class logging, and this is exactly what journald does.
You could never do what journald does with classic rsyslog, like living and logging while in initramfs, and then jump over to the main system when the root-fs was mounted, and continue logging while the system booted.
Anyway, that would also restrict systemd logging to a certain syslog daemon. The present solution is a general solution that works with all syslog implementation like syslog-ng and rsyslog etc.
The awesome structured and indexed log file format has a stable API and structure, so it is quite easy for other syslog implementations to read and write in that format. I believe rsyslog have already implemented a reader and some other journald features. So if they want, they too can have all the advantages of rich metadata.