This minimal HTTP server can serve journal data via HTTP. Its primary
purpose is synchronization of journal data across the network. It serves
journal data in three formats:
text/plain: the text format known from /var/log/messages
application/json: the journal entries formatted as JSON
application/vnd.fdo.journal: the binary export format of the journal
The HTTP server also serves a small HTML5 app that makes use of the JSON
serialization to present the journal data to the user.
Examples:
This downloads the journal in text format:
# systemctl start systemd-journal-gatewayd.service
# wget http://localhost:19531/entries
Same for JSON:
# curl -H"Accept: application/json" http://localhost:19531/entries
Access via web browser:
$ firefox http://localhost:19531/
The old automatism that the flushing of the journal from /run to /var
was triggered by the appearance of /var/log/journal is broken if that
directory is mounted from another host and hence always available to be
useful as mount point. To avoid probelsm with this, introduce a new unit
that is explicitly orderer after all mounte files systems and triggers
the flushing.
This naming convention is more inline with other systemd daemon
unit names (systemd-logind.service, systemd-localed.service etc)
The companion .socket units have also been renamed, however the
-trigger and -settle units keep their current name as these are
not directly related to daemon process itself.
The rule is that units that encapsulate our own code are prefixed with
"systemd-". Since the fsck units invoke our own code, hence add the
missing prefix. Since a long long time the fsck units didn't invoke the
naked fsck binaries anymore, and it is unlikely that this well ever
change. On the opposite: the code in systemd-fsck will probably get more
complex over time to handle fsck progress to plymouth forwarding.
Same for quotacheck (but not quotaon!)
Especially in the case of --enable-split-usr, several units will point
to the wrong location for systemctl. Use @SYSTEMCTL@ which will always
contain the proper path.
remote-fs.target is ordered after the {auto,}mount units. In case of automount
we do not want to wait for the network to come up before proceeding. In case
of a regular mount unit, the unit will be ordered after network.target
so the behavior is unchanged.
This speeds up boot quite a bit for me when having some services needing
NetworkManager-wait-online.service, and having my home partition on nfs
under an automountpoint.
Lennart Poettering