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:
http://freedesktop.org/wiki/So...

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 /run hierarchy.
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.

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.

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 /etc /run requirements is, this is a new feature, not a change of something old and stable. So it doesn't break anything at all.

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.

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:
http://0pointer.net/blog/proje...
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 /usr.

The systemd requirements for the file system is documented here:
http://www.freedesktop.org/wik...
These are rather simple requirements and probably very close to the old FHS 3.0 proposal, I think /run is the only new thing here compared to FHS 2.3

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.

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 /dev/kmsg is recorded until rootfs is mounted and syslogd is running. This is hard to do something about since it is a kernel limitation that only one device at the time can own /dev/log. journald catches all messages, including those to /dev/kmsg and /dev/log, and it does this from early boot. So a journal based system will always contain more info than a pure syslog system.

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.

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.

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.

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 /egrep uses, it simply becomes unwieldy when you are using regex epressions that are +120 characters long. Making ad hoc queries with regex really is painful when the complexity rises beyond the basics. The systemd journal is so much better regarding this since it is field based. It is so trivial to make complex ad hoc queries without any need of using regex.

Really, stuff like:
"journalctl --since -5m"
"journalctl -b-1 -p warning"
"journalctl /usr/sbin/smartd --since 2015-05-10"

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.

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.

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.

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 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.

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 /run is guaranteed to available from early boot (initramfs).

I believe this re-org even predates systemd.

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 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.

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?

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 /run.
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.

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"
http://www.freedesktop.org/wik...

Here is how to receive or pull systemd journals across the network: It can either pull log requests or passively wait for a connection:
http://www.freedesktop.org/sof...

Here is how to serve journald log entries across the network:
http://www.freedesktop.org/sof...

Yes I do. It is great that you can use exactly the program you need, even if their usage normally are orthogonal. Please note that PA doesn't disable itself, it just automatically suspend until needed again. PA and jackd where made for different reasons and solves different problems.

Well, some people thought they could stop the systemd progress by waging a negative campaign against it and its developers. That of course was a predictable failure.

Personally I don't care whatever init system people run. Even if I find e.g. SysVinit inferior to systemd I have no problem with people using it, and they owe me no explanation for doing so.

Systemd-opponents don't agree upon what they do like, they can only agree on what they don't like. This make their tactics so rabid and aggressive when attacking systemd, its developers, the distros that uses it and even its users. They simply don't have a positive alternative they can agree upon, so they are left with negative attacks.

journald has excellent export capacity, it is trivial to convert everything into JSON or similar industry standards without tedious data massaging. Unlike the many slightly varying syslog implementation with deviating output, journald output is always predictable since has a stable API and is structured around fields. This is a massive win for everybody, especially those who needs to put their logs into full DB's (for legal or whatever reasons).

Adding full microsecond precision and monotonic timestamps and wall time timestamps + all the other interesting meta-data and the log message itself, are making the text log entries extremely long and unfriendly to read for humans. With journald you only see such meta-data info if you ask for it. Much better solution. And if you are concerned about log sizes, journald has transparent compression. With text logs you need to unpack or use specialised tools to manipulate them if compressed.

Plain text logs sucks for so many reasons, their only redeeming feature seems to be you don't need to pipe them through a tool in order to read them.
I have much respect for the Rsyslog developers, and I remember how I hoped they would fix the most of the glaring syslog problems when they started out a decade ago and in their own way tried to solve the problems that journald does. They partially failed, not because they weren't good, but because changing certain stuff in Linux userland is extremely hard.