IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The MESSAGE_ID=... stanza will appear in countless number of places.
It is just too long to write it out in full each time.
Incidentally, this also fixes a typo of MESSSAGE is three places.
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.
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.
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.
The mmap cache doesn't guarantee that we can look at two files at the
same time. Hence make sure to look at the entries to compare one
after the other, instead of at the same time when comparing them, and
reposition the window in between.
