Open imrehg opened 5 years ago
So far these seem good candidates for me:
-S --since=DATE Show entries not older than the specified date
-U --until=DATE Show entries not newer than the specified date
-c --cursor=CURSOR Show entries starting at the specified cursor
--after-cursor=CURSOR Show entries after the specified cursor
--show-cursor Print the cursor after all the entries
-b --boot[=ID] Show current boot or the specified boot
--list-boots Show terse information about recorded boots
-k --dmesg Show kernel message log from the current boot
-u --unit=UNIT Show logs from the specified unit
-t --identifier=STRING Show entries with the specified syslog identifier
-p --priority=RANGE Show entries with the specified priority
-g --grep=PATTERN Show entries with MESSAGE matching PATTERN
--case-sensitive[=BOOL] Force case sensitive or insenstive matching
-f --follow Follow the journal
-n --lines[=INTEGER] Number of journal entries to show
-r --reverse Show the newest entries first
-o --output=STRING Change journal output mode (short, short-precise,
short-iso, short-iso-precise, short-full,
short-monotonic, short-unix, verbose, export,
json, json-pretty, json-sse, json-seq, cat,
with-unit)
--output-fields=LIST Select fields to print in verbose/export/json modes
--utc Express time in Coordinated Universal Time (UTC)
-x --catalog Add message explanations where available
--no-full Ellipsize fields
-a --all Show all fields, including long and unprintable
-q --quiet Do not show info messages and privilege warning
--no-hostname Suppress output of hostname field
with some caveats:
--no-pager
--reverse
and --follow
, for example). Or just bubble up the errors correctly.Just some thoughts, to make it more usable for both simple and advanced use cases. cc @shaunmulligan ?
@imrehg isn't this achievable if you pipe it through a journalctl
in the container? I think we just follow the rsyslog standard for the API. I'm of two minds if we should put this complexity in the supervisor as well? Would be interested to hear @CameronDiver view on how much extra work it is. I think it definitely would be useful, but might be better to have some other component do the filtering, etc.
I think the most compelling flag to support for me would be changing the output format (for example to JSON, which can be parsed easily by many frameworks/languages). In addition time-based ones might be helpful, for example since
and until
. The others can be easily worked around with an external program, whether that's journalctl
or something custom.
[zvin] This issue has attached support thread https://jel.ly.fish/99fc7f01-c43d-4aa4-abe1-f0bab32878ee
This also include support of flags being specified multiple times (like
-u
) in a natural, REST-y way, I guess?Here are all the option flags from the help, should select and cut it down to the ones that should be included, and document the choices.