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/
Among other cleanups this introduces a threshold for the size of binary
blobs we serialize as integer arrays in the JSON output. THis can be
disabled via --all.
It is no longer possible to manually enable systemd-udev-settle.service,
so its only use is by legacy services explicitly pulling it in. It makes
sense for these services to also explicitly order themselves after
udev-settle.service, which makes After=basic.target redundant.
This should reduce the negative effect on boot-time of having to enable
legacy services such as lvm.service.
The old code used a timestamp to print a timespan for unsealed journalfiles,
incorrectly showing things like 2230 days of unsealed entries. Print the timespan
between the first and last entry instead.
This requires a little bit of tip-toeing around to explicitly avoid
touching the environment from a sig handler. Instead, simply create a
function to reset the var to its "unset" state, allowing the next call
to columns() to recalculate and cache the new value.
Turns out cpuset needs explicit initialization before we could make use
of it. Thus mounting cpuset with cpu/cpuacct would make it impossible to
just create a group in "cpu" and start it.
Instead of doing hand optimized fd bisect arrays just use plain old
hashmaps. Now I can understand my own code again. Yay!
As a side effect this should fix some bad memory accesses caused by
accesses after mmap(), introduced in 189.
Lennart Poettering