Yeah, I even found a man page that list all the man pages : "man systemd.index" and a index for all unit directives "man systemd.directives" with cross-references to the relevant man pages. Really useful stuff that shows the developers cares about end users.
I suppose this bias toward old, good documentation is contributing to my dislike of Systemd, I don't see the same docs for Systemd that I saw for System V and BSD init structures.
systemd is a seriously well documented project. At the moment there are around 202 man-pages.
Every man-page I have used is done by the book: good examples, relevant "See also" references, and sometimes even links to further information. I really like the fact that all config files have extensive man pages too (man journald.conf fx), and that they also provide "big picture" documentation like "man bootup".
I have often seen how a question on the systemd devel list resulted in clarification of the documentation, so they take their documentation seriously.
On top of the man pages, there is also a huge amount of information on the projects homepage, spanning from overview videos, to low level developer information.
Those are "the systemd requirements for the filesystem", what systemd needs. It provides no clarity about what goes _in_ those directories, nor why,
Yes, those are the basics for systemd to work. Again, rather simple requirements. It doesn't state what goes into what, because this is something the distros dictate, not systemd. The systemd developers can merely suggest where to put things, but distros won't necessarily follow those suggestions.
systemd is designed with different distro policies in mind, so they provide "Presets" to help facilitate the different policies and needs of different distros:
Compare this checklist with the actual FHS documents, and you'll see the distinction. The result is confusion, such as the systemd migration of "/media" attachable storage to the individual user's owned subdiroectories in "/run".
The FHS is primarily concerned about directory layout, not so much the content of these. And there is nothing in FHS 3.0 that contradict the slightest that user attached storage is mounted in the
All such disc layout reorgs of the distro I have tried, have been discussed on mailing lists etc. before they are implemented. Again, this is something the distros dictate, not systemd.
Allow me to restate your comment:
> Systemd will continue to work for Linux distros that don't care for stateless boot etc
Rather, systemd will continue to re-arrange, and break, stable subsystems without warning to the user communities.
Come on. It is the distros that dictates exactly what features systemd have turned on, and how the FH layout is. There are no systemd developers sneaking into the distro repos at night and secretly turning on features without documenting them.
You may not follow the eg. development mailing list of your distro where such things are discussed, nor care about reading release notes. But Linux distros have always evolved this way, with new ways of doing things, often from release to release.
OTher examples abound. For example, the new replacement for
I fail to see how this in any way breaks any stable subsystem.
1. systemd-resolved is an entirely optional feature. If the distros don't want it, they can just turn it off.
2. Whatever its
I really don't think you can give just a single non-contrieved example of how systemd are breaking stable subsystems for users without warning.
While more documentation is always better, I think the systemd project is way better documented than most other software projects, and certainly much better documented than many people think it is.
I'm not even going to mention what happens if you accidentally follow generations of sytem standard behavior and install NTP alongside an active systemd NTP daemon. It's not a pretty site, and the accumulated clock management confusion if they're not pointed to the same NTP servers can break Kerberos authentication in startlingly short order.
Running two NTP-clients at the same time was an amazingly stupid thing to do even pre-systemd. AFAIK, systemd per default tries to avoid this by using "conflict" statements in the service files, so if one NTP client or daemon is run, the others are suppressed.
I don't think eg. SysVinit or Upstart ever had such measurements against accidentally running two NTP daemons at once.
The bottom line; yes, systemd developers are working towards stateless boot and other similar optional features. Yes, this will require some reorgs of how especially config-files are kept. There are good technical reasons for this (crypto verification, factory reset etc), and the layout changes seem to benefit all user cases, including those that won't be using the new features. Even those who doesn't use systemd would probably benefit from a layout with a clear separation between user, system and distro default config files.
The basic requirements for these new features are sketched out here:
But remember, this is very much a work in progress for the future, when things are are starting to actually work somewhat, I am sure that a more "official" documentation will appear that spells out all the details.
And the there is no dictate to make these features work for either distros nor upstream projects. This work will only be done if people think it is beneficial to their distro/project. systemd will work without being able to perform a factory reset or a crypto verified
The systemd requirements for the file system is documented here:
These are rather simple requirements and probably very close to the old FHS 3.0 proposal, I think
AFAIK, all other changes of the FHS are merely suggestions like getting extra OS container features when using btrfs, and in case of stateless boot, something for the future. Systemd will continue to work for Linux distros that don't care for stateless boot etc.
You mean boot logging? There are numerous ways to solve this which would have made more sense, including a small change to the linux kernel to make it stop throwing away boot logs when they are large.
The kernel ring-buffer size can be user specified, so no need to ever lose such messages. The problem is that during boot, only messages directed at
So use syslog-ng, which can be used in place of syslog without changes to other daemons, unlike journald. Which again, is the reason we're even having this conversation.
Regarding silently dropping messages: AFAIK all syslog daemons does this per design (or lack thereof). The main problem is that calls to syslog() would be blocking if implemented in a safe manner.
Wait, you don't care about human-readability, but you don't want the logs to become unreadably long? Make up your fucking mind. You're just making shit up, I can tell because that shit is contradictory.
You misunderstand; a reason why syslog messages doesn't contain monotonic timestamps etc. is that it makes the log entries extremely long and hard to read for humans. It is a kind of limitation of the "design".
journald doesn't have such limitations since it is field based, and the output format is easily adapted to what view you want. If you only want wall time stamps, you can get that, if you want monotonic time stamps, you get that, and only that.
So with the journal, you can add more fields in the future without making the log entries unwieldy, something impossible with syslog.
Regarding human readable: I only care about that for the subset of information I intend to read, and this is exactly what journalctl does. That way you can have logs that are easy to parse for both humans and machines; each consumer gets exactly the view of the data that they want in a form they can use.
that text logs simply don't scale
Still not an argument against text logs, only an argument for also implementing binary logs. And I wouldn't put them into their own shitty files with their own shitty format, I would put them into an RDBMS. Putting them into crappy, easily-corrupted binary log files is just asking for trouble, and guess what? It's causing trouble.
Yes, the scaling thing is a good argument against using flat file text logs. You really need indexes when analysing such huge amount of data, which is exactly what people are doing at the moment; they invest in often proprietary commercial solutions in order to massage their flat text file log data into something usable.
RDBMS have been tried for a long time and they are not a good general purpose solution for local logging. They are also much more prone to corruption than the journal's simpler binary storage format.
What? So now you don't like flat files or regex? Why don't you just fuck off to Windows and let us have our Linux? You clearly don't like Unix.
While regex is a powerful tool, the old joke about trying to solve a problem using regex, and then discover you now have _two_ problems, is true too. Discounting the many variations of regex that each program like grep
Really, stuff like:
"journalctl --since -5m"
"journalctl -b-1 -p warning"
Is so much easier than trying to construct regexes that does the same.
I assume you are talking about FHS 3.0 here, but remember, that is only a proposal, not a standard. Also note how the FHS 3.0 process has been stalled for years.
The bottom line today is that there is FHS 2.3, and then everybody doing their own thing , perhaps with some cross-distro cooperating. The end result is no common formal standard for the FHS among the distros.
Personally I don't think there will be a FHS 3.0 until the dust has settled regarding the current layout reorg,
The reorg of the FHS that the systemd developer are doing, are caused by good technical reasons. Unix and later Linux have had several of these reorgs over the decades, and it is a process that probably never stops.
So until the FHS reorg to make about OS containers, and stateless boot work in a sensible manner, the Linux FHS will be in a slight flux. Not a big problem really.
I guess at some point somebody will make a FHS 3.X out of what the systemd distros does at some point in the future. Personally I prefer this approach of practise getting formalized into a standard. That way you are sure to have both a good working standard, and a standard that people actually use.
Judging by this thread, it does give at least one advantage, that being the ability to at least partially recover and analyze corrupted logs.
The same is very much true for systemd's journald files. They are just appended text files with another delimiter +index, so in worst case a hex editor or "strings" may read them.
"journalctl" is designed to cope with corrupted journals and read them very well. It should be noted here that corruption of journal files as discovered by the --verify option, mostly are very trivial errors like a monotonic timestamps of the wrong length etc. Such errors only affects a single log entry, and often even that log entry can be read without problems. Despite using journald since it became standard on Fedora (F15) I have never experienced any data loss nor having journal files that I was unable to read.
Plain text log files, like the original syslog(3) interface was simply bad ideas that Linux inherited.
No, that was a brilliant idea that Linux inherited.
Come on, syslog(3) wasn't even signal-safe and designed as dog slow too. It was crap. People have been working ever since to make syslog thread safe (still interim), etc.
What classic syslog problems? I haven't had a problem with log rotation, really the last remaining issue, in approximately forever.
That syslogd can't log until rootfs is started and most of the machine is up, that it is dog slow and silently drops messages under load, that there is no common API for accessing the content of the data, that the data is basically free form, deviating from machine to machine (an industry exist dedicated to this problem alone) also making it impossible to make a distro agnostic GUI log viewer, that meta-data like monotonic timestamps are basically impossible to add without the log entries becoming unreadable long, that text logs simply don't scale (again, an industry exist to solve this problem, see Splunk etc.), that using regex becomes intolerable and unwieldy above a certain point, that in order to grep for something in the log file, you basically already have to know the name of the function and what the problem is, this makes syslog log files basically impossible to use for newbies, so they have to resort to trawling through the logs like reading a book.
Really, flat file, un-indexed log files meant to be read by a human SA is something that belongs to another era. What the present and the future needs are binary, structured and indexed logs with a stable API that can be parsed by machines and that works even at mega-scales.
And systemd's journald is designed to be 100% backwards compatible with syslog, so if your setup have legacy need, it is trivial to get a systemd distro to use legacy syslog text logs.
And syslog gets the messages late, and may not get them at all.
Well, these are know problems with syslogd implementations; they silently drop messages under even moderate load. It is their ancient design, so using pure syslog you will never know whether something was logged or dropped. With journald you will at least be informed if log messages are dropped. The latter should be a rare occurrence since journald is so much faster than syslogd.
journald goes to great lengths by using per app log rate limiting in order not saturate syslogd, but the inherent limitations in syslog means that this will always be an best effort. Still, it probably isn't worse than using syslogd alone.
I'm curious: why not just make an indexed database logging system on top of, rather than instead of, text logs? i.e. write out log entries in some structured but still text-only format in one file, and then maintain an efficient binary index of entries in a separate file. That way you get all the nice search etc, while still being able to grep the raw text if you really need to.
There are several problems with solution: it isn't backwards compatible with syslog (journald strives for 100% backwards compatibility).
It doesn't solve the problems that combining meta-data with log entries in flat text files, makes the text logs hard to read for humans since the log lines become far too long and complex.
It doesn't really gives any advantage of pure binary data. Remember grep, sed, tee and every other standard Linux text tool works with systemd's journal through the standard Linux/Unix concept of piping, so there is nothing lost by going pure binary.
The reorg of the FHS is quite needed in these days of OS containers, sandboxing and virtualization, so while placing stuff under "/run" is something new (part of the proposed FHS 3.0 standard btw), there are good technical reasons for it, including that
I believe this re-org even predates systemd.
Thanks for the links. Last time I looked into this, the remote features were still a feature request.
Maybe I'm not understanding you, but I thought journal was meant to be superior to syslog and eventually supplant it.
Well, yes and no. journald was meant as a total overhaul of _local_ Linux logging. It provides "metal-to-metal" logging by being able to operate in initramsfs before rootfs is mounted, and pivot back to initramfs (Dracut) after rootfs has been unmounted. It collates all logs into a single view, instead of the myriad of scattered legacy log files (including binary logs like utmp etc).
It also vastly improve the way programmers can use logging, since syslog(3) etc. have so many limitations regarding speed, messages per seconds etc.
It also provide structured logs with plenty of metadata like monotonic timestamps that are troublesome in syslog text logs.
Rsyslog and similar syslog implementation works both as a _local_ logging system _and_ as a remote log sink.
journald doesn't work as a general log sink for remote logging, nor does it provide DB interfaces and various other similar plug-ins. So for general log-sinks, Rsyslog was always meant to be choice.
journald was also designed to be 100% compatible with syslog since it was obvious that legacy requirements would make that a necessity. So again, for legacy setups, syslog was always the designed choice to run on top of journald.
The issue is not with systemd corrupting the binary logs, or with the filesystem corrupting the binary logs, but with the fact that they are -binary- logs. A log file should be an ordinary text file. Nothing more, nothing less.
The glaring problems with flat file, unstructured text logs have been discussed for decades now. Plain text log files, like the original syslog(3) interface was simply bad ideas that Linux inherited. The main commercial selling point with any syslog implementation today is exactly that you can avoid several of these problems by using a DB.
An overhaul of the creaking legacy Linux logging system have been needed for a decade at least. Remember, the Rsyslog project was started exactly to fix such problems. They failed partly because distros and developers don't care about working together for a common goal and because there was no other central developer hub who would take the initiative.
systemd have finally fixed so many of the classic syslog problems. I don't care if you think syslog is perfect and never can be improved, and Rsyslog should be avoided for providing binary DB storing option, but please don't think that other people agree to this postulate.
And systemd's journald is designed to be 100% backwards compatible with syslog, so if your setup have legacy need, it is trivial to get a systemd distro to use legacy syslog text logs.
Bug report: Logs keep getting corrupted and cannot read them at all
Rejected with reason: Delete the corrupted logs and move on
I doubt that you can provide a link for that. Perhaps you are hinting to the RFE about "pruning" journal logs containing "corrupted" field values?
SystemD - works well when it works, fails spectacularly when it fails.
That is part of the Unix philosophy: (Rule of Repair : http://en.wikipedia.org/wiki/U...), or "if you have to fail, fail early and fail noisily". systemd is build around that; so if disks specified in fstab doesn't show up, it won't boot but give a rescue shell instead. This prevents silent data loss; a classic example of "Rule of Repair".
Been using systemd on Fedora for several years now; it has been rock solid. systemd is just so much better than any alternative out there, and for every release it just keeps on getting better. I love its logging system and the easy and natural way it handles OS containers and system service management.
Stateless boot is nothing new in Linux. What the systemd developers want is to make Linux generic enough to make stateless boot work for those who needs it, instead of each and every developer group making their own proprietary tools. Stateless boot are mostly for embedded but also allow for some interesting network booted options.
There is a lot of work to be done before it is possible, but with systemd people are at least working on it.
Regarding the FHS and where to put things like using
systemd is only doing the sensible thing here. The FHS 2.0 is ancient, so the systemd way of doing things is likely to become FHS 3.0, and then it will be a Linux standard.
SysD's binary logs have another, serious flaw: they are not designed to be sent over a network. This has been an intrinsic part of syslog for a looong time.
Of course you can push journald logs over the network in several different ways, and you can also receive them using the journald. But the systemd journald isn't substitute for syslog, but meant to complement it. Just use rsyslog when it is relevant, or just systemd's journald when that suffices.
Here is the document info for "journal export format"
Here is how to receive or pull systemd journals across the network: It can either pull log requests or passively wait for a connection:
Here is how to serve journald log entries across the network: