On Tue, 13 Jan 2026 11:22:55 +0100, Carlos E.R. wrote:
For example, in my machine I use leafnode as an nntp proxy server to
Usenet. It is very verbose, and floods the logs. With syslog, I put
them in a different file and rotate them faster, keeping only
warning or emergency level for longer.
With systemd I can do nothing. The entire verborrea of nntp is kept,
and the total is either rotated faster, or grow huge faster.
<https://www.freedesktop.org/software/systemd/man/latest/journald.conf.html>
See the options for overall rate-limiting and log size limits,
rotation control, retention time, filtering by log level ... and of
course forwarding to syslog and other legacy places.
I want to purge from the journal all messages from facility=news, level>Warning, age> 7 days. Only those messages. Leave all the rest
intact.
On Wed, 14 Jan 2026 14:42:44 +0100, Carlos E.R. wrote:
I want to purge from the journal all messages from facility=news,
level>Warning, age> 7 days. Only those messages. Leave all the rest
intact.
You can?t purge selected lines from a logfile with syslog, either.
You
would have to copy the log to a new file, and leave out the lines you
don?t want.
On 2026-01-14 21:54, Lawrence D?Oliveiro wrote:
You can?t purge selected lines from a logfile with syslog, either.
Yes, I can and I do.
With config lines in /etc/rsyslog.conf and in logrotate.
On Wed, 14 Jan 2026 23:14:31 +0100, Carlos E.R. wrote:--vacuum-size=, --vacuum-time=, --vacuum-files=
On 2026-01-14 21:54, Lawrence D?Oliveiro wrote:
You can?t purge selected lines from a logfile with syslog, either.
Yes, I can and I do.
With config lines in /etc/rsyslog.conf and in logrotate.
Try the journalctl --vacuum-xxx options, then.
On 2026-01-14 23:36, Lawrence D?Oliveiro wrote:
On Wed, 14 Jan 2026 23:14:31 +0100, Carlos E.R. wrote:ÿÿÿÿÿÿ --vacuum-size=, --vacuum-time=, --vacuum-files=
On 2026-01-14 21:54, Lawrence D?Oliveiro wrote:
You can?t purge selected lines from a logfile with syslog, either.
Yes, I can and I do.
With config lines in /etc/rsyslog.conf and in logrotate.
Try the journalctl --vacuum-xxx options, then.
ÿÿÿÿÿÿÿÿÿÿ --vacuum-size= removes the oldest archived
ÿÿÿÿÿÿÿÿÿÿ journal files until the disk space they use
ÿÿÿÿÿÿÿÿÿÿ falls below the specified size. Accepts the
ÿÿÿÿÿÿÿÿÿÿ usual "K", "M", "G" and "T" suffixes (to
ÿÿÿÿÿÿÿÿÿÿ the base of 1024).
ÿÿÿÿÿÿÿÿÿÿ --vacuum-time= removes archived journal
ÿÿÿÿÿÿÿÿÿÿ files older than the specified timespan.
ÿÿÿÿÿÿÿÿÿÿ Accepts the usual "s" (default), "m", "h",
ÿÿÿÿÿÿÿÿÿÿ "days", "months", "weeks" and "years"
ÿÿÿÿÿÿÿÿÿÿ suffixes, see systemd.time(7) for details.
ÿÿÿÿÿÿÿÿÿÿ --vacuum-files= leaves only the specified
ÿÿÿÿÿÿÿÿÿÿ number of separate journal files.
ÿÿÿÿÿÿÿÿÿÿ Note that running --vacuum-size= has only
ÿÿÿÿÿÿÿÿÿÿ an indirect effect on the output shown by
ÿÿÿÿÿÿÿÿÿÿ --disk-usage, as the latter includes active
ÿÿÿÿÿÿÿÿÿÿ journal files, while the vacuuming
ÿÿÿÿÿÿÿÿÿÿ operation only operates on archived journal
ÿÿÿÿÿÿÿÿÿÿ files. Similarly, --vacuum-files= might not
ÿÿÿÿÿÿÿÿÿÿ actually reduce the number of journal files
ÿÿÿÿÿÿÿÿÿÿ to below the specified number, as it will
ÿÿÿÿÿÿÿÿÿÿ not remove active journal files.
ÿÿÿÿÿÿÿÿÿÿ --vacuum-size=, --vacuum-time= and
ÿÿÿÿÿÿÿÿÿÿ --vacuum-files= may be combined in a single
ÿÿÿÿÿÿÿÿÿÿ invocation to enforce any combination of a
ÿÿÿÿÿÿÿÿÿÿ size, a time and a number of files limit on
ÿÿÿÿÿÿÿÿÿÿ the archived journal files. Specifying any
ÿÿÿÿÿÿÿÿÿÿ of these three parameters as zero is
ÿÿÿÿÿÿÿÿÿÿ equivalent to not enforcing the specific
ÿÿÿÿÿÿÿÿÿÿ limit, and is thus redundant.
ÿÿÿÿÿÿÿÿÿÿ These three switches may also be combined
ÿÿÿÿÿÿÿÿÿÿ with --rotate into one command. If so, all
ÿÿÿÿÿÿÿÿÿÿ active files are rotated first, and the
ÿÿÿÿÿÿÿÿÿÿ requested vacuuming operation is executed
ÿÿÿÿÿÿÿÿÿÿ right after. The rotation has the effect
ÿÿÿÿÿÿÿÿÿÿ that all currently active files are
ÿÿÿÿÿÿÿÿÿÿ archived (and potentially new, empty
ÿÿÿÿÿÿÿÿÿÿ journal files opened as replacement), and
ÿÿÿÿÿÿÿÿÿÿ hence the vacuuming operation has the
ÿÿÿÿÿÿÿÿÿÿ greatest effect as it can take all log data
ÿÿÿÿÿÿÿÿÿÿ written so far into account.
Nope. These options remove entire files, when what I want to do is purge messages of certain age belonging to a certain facility and certain severity, regardless of what file they reside in.
I repeat: this feature is intentionally not implemented by the journal.
They want to make a photograph of the system messages, all of them,
intact and secure, never edited or changed to ensure integrity.
Nope. These options remove entire files, when what I want to do is
purge messages of certain age belonging to a certain facility and
certain severity, regardless of what file they reside in.
I repeat: this feature is intentionally not implemented by the
journal.
On Thu, 15 Jan 2026 14:40:36 +0100, Carlos E.R. wrote:
Nope. These options remove entire files, when what I want to do is
purge messages of certain age belonging to a certain facility and
certain severity, regardless of what file they reside in.
I repeat: this feature is intentionally not implemented by the
journal.
With Open Source, there is always a way.
Looks like the way to do it is to use the export format from
journalctl, and do your custom filtering on that. If you want to put
the result back into systemd journal format, you can use this <https://www.freedesktop.org/software/systemd/man/latest/systemd-journal-remote.html>.
Way too complicated.
On Fri, 16 Jan 2026 21:40:30 +0100, Carlos E.R. wrote:
Way too complicated.
First you said it couldn?t be done at all -- that it was
?intentionally impossible?, and ?intentionally not implemented by the journal?. Now when I point out it can be done quite easily,
potentially with just a few lines of script, you claim that?s ?way too complicated?.
What I think is, it?s your existing way of laboriously copying and
filtering text-format logfiles with your own (likely regexp-heavy)
custom scripting, that is ?way too complicated?, and you are suffering
from something called the ?sunk-cost fallacy?, where you don?t want to
throw away all the effort you have put into your existing ways of
doing things, even if the new way is simpler.
I am using no scripting at all. I use the default toolset for
handling syslog messages for decades of *nix.
/etc/rsyslog.conf: (this configuration came with the system,
commented out, so I just had to uncoment it)
news.crit -/var/log/news/news.crit
news.err -/var/log/news/news.err
news.notice -/var/log/news/news.notice
news.debug -/var/log/news/news.debug
/etc/logrotate.d/syslog: (this configuration is the same as default for other files)
[etc]
I want tools provided by the systemd people, not hacks.
On Fri, 16 Jan 2026 22:23:08 +0100, Carlos E.R. wrote:
I am using no scripting at all. I use the default toolset for
handling syslog messages for decades of *nix.
/etc/rsyslog.conf: (this configuration came with the system,
commented out, so I just had to uncoment it)
news.crit -/var/log/news/news.crit
news.err -/var/log/news/news.err
news.notice -/var/log/news/news.notice
news.debug -/var/log/news/news.debug
This involves splitting out the messages into categories upfront, at collection time, not analysis time.
/etc/logrotate.d/syslog: (this configuration is the same as default for other files)
[etc]
Same applies here.
I want tools provided by the systemd people, not hacks.
Most data-collection philosophy is ?collect everything first, split it
out for analysis later?. That seems to me more flexible than having to
decide up front how you want to divide up the raw data for analysis.
Because what happens if you change your mind about how you want to
analyze data you?ve already collected?
And it?s how the systemd tools work.
On Fri, 16 Jan 2026 21:40:30 +0100, Carlos E.R. wrote:
Way too complicated.
First you said it couldn?t be done at all -- that it was
?intentionally impossible?, and ?intentionally not implemented by the journal?. Now when I point out it can be done quite easily,
potentially with just a few lines of script, you claim that?s ?way too complicated?.
What I think is, it?s your existing way of laboriously copying and
filtering text-format logfiles with your own (likely regexp-heavy)
custom scripting, that is ?way too complicated?, and you are suffering
from something called the ?sunk-cost fallacy?, where you don?t want to
throw away all the effort you have put into your existing ways of
doing things, even if the new way is simpler.
On Fri, 16 Jan 2026 22:23:08 +0100, Carlos E.R. wrote:
I am using no scripting at all. I use the default toolset for
handling syslog messages for decades of *nix.
/etc/rsyslog.conf: (this configuration came with the system,
commented out, so I just had to uncoment it)
news.crit -/var/log/news/news.crit
news.err -/var/log/news/news.err
news.notice -/var/log/news/news.notice
news.debug -/var/log/news/news.debug
This involves splitting out the messages into categories upfront, at collection time, not analysis time.
/etc/logrotate.d/syslog: (this configuration is the same as default
for other files)
[etc]
Same applies here.
I want tools provided by the systemd people, not hacks.
Most data-collection philosophy is ?collect everything first, split it
out for analysis later?. That seems to me more flexible than having to
decide up front how you want to divide up the raw data for analysis.
Because what happens if you change your mind about how you want to
analyze data you?ve already collected?
And it?s how the systemd tools work.
On 2026-01-16, Lawrence D?Oliveiro wrote:
On Fri, 16 Jan 2026 22:23:08 +0100, Carlos E.R. wrote:
I am using no scripting at all. I use the default toolset for
handling syslog messages for decades of *nix.
/etc/rsyslog.conf: (this configuration came with the system,
commented out, so I just had to uncoment it)
news.crit -/var/log/news/news.crit
news.err -/var/log/news/news.err
news.notice -/var/log/news/news.notice
news.debug -/var/log/news/news.debug
This involves splitting out the messages into categories upfront, at
collection time, not analysis time.
/etc/logrotate.d/syslog: (this configuration is the same as default
for other files)
[etc]
Same applies here.
I want tools provided by the systemd people, not hacks.
Most data-collection philosophy is ?collect everything first, split it
out for analysis later?. That seems to me more flexible than having to
decide up front how you want to divide up the raw data for analysis.
Because what happens if you change your mind about how you want to
analyze data you?ve already collected?
And it?s how the systemd tools work.
If you change your mind later, you do with the files the same thing
you're suggesting Carlos do with systemd: write something to undo the splitting.
On 2026-01-16, Lawrence D?Oliveiro wrote:
On Fri, 16 Jan 2026 21:40:30 +0100, Carlos E.R. wrote:
Way too complicated.
First you said it couldn?t be done at all -- that it was
?intentionally impossible?, and ?intentionally not implemented by the
journal?. Now when I point out it can be done quite easily,
potentially with just a few lines of script, you claim that?s ?way too
complicated?.
What I think is, it?s your existing way of laboriously copying and
filtering text-format logfiles with your own (likely regexp-heavy)
custom scripting, that is ?way too complicated?, and you are suffering
from something called the ?sunk-cost fallacy?, where you don?t want to
throw away all the effort you have put into your existing ways of
doing things, even if the new way is simpler.
No, you're again LDO-ing the conversation. You effectively said this
can't be done within systemd's journal. That may be ok, and it may well
be possible to do it externaly, easily or less so, but the point stands
that someone pointed a use case for which that journal apparently (from
what you said) isn't a suitable replacement.
As usual, you try to sweep this under the rug of "it's FLOSS so you can change it [or make it part of a larger workflow]".
(If you really insist in going in that direction, there's not much to be discussed, because, as far as the missing bits can be implemented in a Turing-complete language, it has to be possible to do so; the only
limitation is going to be licensing. That part you got right. But
derailing the train of thought this way really appears like you're
making extensive efforts to avoid conceding that the tool you prefer
does not have this feature.)
No, you're again LDO-ing the conversation.
On 2026-01-17 00:30, Nuno Silva wrote:
On 2026-01-16, Lawrence D?Oliveiro wrote:
On Fri, 16 Jan 2026 21:40:30 +0100, Carlos E.R. wrote:
Way too complicated.
First you said it couldn?t be done at all -- that it was
?intentionally impossible?, and ?intentionally not implemented by the
journal?. Now when I point out it can be done quite easily,
potentially with just a few lines of script, you claim that?s ?way too
complicated?.
What I think is, it?s your existing way of laboriously copying and
filtering text-format logfiles with your own (likely regexp-heavy)
custom scripting, that is ?way too complicated?, and you are suffering
from something called the ?sunk-cost fallacy?, where you don?t want to
throw away all the effort you have put into your existing ways of
doing things, even if the new way is simpler.
No, you're again LDO-ing the conversation. You effectively said this
can't be done within systemd's journal. That may be ok, and it may well
be possible to do it externaly, easily or less so, but the point stands
that someone pointed a use case for which that journal apparently (from
what you said) isn't a suitable replacement.
As usual, you try to sweep this under the rug of "it's FLOSS so you can
change it [or make it part of a larger workflow]".
(If you really insist in going in that direction, there's not much to be
discussed, because, as far as the missing bits can be implemented in a
Turing-complete language, it has to be possible to do so; the only
limitation is going to be licensing. That part you got right. But
derailing the train of thought this way really appears like you're
making extensive efforts to avoid conceding that the tool you prefer
does not have this feature.)
In some machines, the journal is cryptographically signed. Thus any
later manipulation is impossible, it invalidates the signature.
In some machines, the journal is cryptographically signed. Thus any
later manipulation is impossible, it invalidates the signature.
On 2026-01-16 22:41, Lawrence D?Oliveiro wrote:
This involves splitting out the messages into categories upfront, at
collection time, not analysis time.
Certainly. That's the syslog way.
systemd collects all data, and does not provide any means to purge selectively some data.
syslog daemons are very versatile, after decades of usage.
On Fri, 16 Jan 2026 22:53:47 +0100, Carlos E.R. wrote:
On 2026-01-16 22:41, Lawrence D?Oliveiro wrote:
This involves splitting out the messages into categories upfront, at
collection time, not analysis time.
Certainly. That's the syslog way.
That?s not a very scientific way.
systemd collects all data, and does not provide any means to purge
selectively some data.
I already explained to you how you can do exactly that.
On Sat, 17 Jan 2026 14:33:32 +0100, Carlos E.R. wrote:
syslog daemons are very versatile, after decades of usage.
But they still don?t make it easy to view messages with times
displayed according to different time zones.
On 2026-01-17 21:35, Lawrence D?Oliveiro wrote:
On Sat, 17 Jan 2026 14:33:32 +0100, Carlos E.R. wrote:
syslog daemons are very versatile, after decades of usage.
But they still don?t make it easy to view messages with times
displayed according to different time zones.
LOL. Why would I want that?
On 2026-01-17 21:34, Lawrence D?Oliveiro wrote:
On Fri, 16 Jan 2026 22:53:47 +0100, Carlos E.R. wrote:
On 2026-01-16 22:41, Lawrence D?Oliveiro wrote:
This involves splitting out the messages into categories upfront, at
collection time, not analysis time.
Certainly. That's the syslog way.
That?s not a very scientific way.
systemd collects all data, and does not provide any means to purge
selectively some data.
I already explained to you how you can do exactly that.
Not with tools officially provided by the systemd people. Fully
compliant. A hack.
I want to purge from the journal all messages from facility=news, level>Warning, age> 7 days. Only those messages. Leave all the rest
intact.
Doing this goes against the philosophy of the journal, so it is
intentionally imposible.
"Carlos E.R." <robin_listas@es.invalid> wrote:
On 2026-01-17 21:34, Lawrence D?Oliveiro wrote:
On Fri, 16 Jan 2026 22:53:47 +0100, Carlos E.R. wrote:
On 2026-01-16 22:41, Lawrence D?Oliveiro wrote:
This involves splitting out the messages into categories upfront, at >>>>> collection time, not analysis time.
Certainly. That's the syslog way.
That?s not a very scientific way.
systemd collects all data, and does not provide any means to purge
selectively some data.
I already explained to you how you can do exactly that.
Not with tools officially provided by the systemd people. Fully
compliant. A hack.
You can have systemd-journald forward data to a classic syslog daemon.
In some machines, the journal is cryptographically signed. Thus any
later manipulation is impossible, it invalidates the signature.
"Carlos E.R." <robin_listas@es.invalid> wrote:
On 2026-01-17 21:34, Lawrence D?Oliveiro wrote:
On Fri, 16 Jan 2026 22:53:47 +0100, Carlos E.R. wrote:
On 2026-01-16 22:41, Lawrence D?Oliveiro wrote:
This involves splitting out the messages into categories upfront, at >>>>> collection time, not analysis time.
Certainly. That's the syslog way.
That?s not a very scientific way.
systemd collects all data, and does not provide any means to purge
selectively some data.
I already explained to you how you can do exactly that.
Not with tools officially provided by the systemd people. Fully
compliant. A hack.
You can have systemd-journald forward data to a classic syslog daemon.
On Sat, 17 Jan 2026 22:56:47 +0100, Carlos E.R. wrote:
On 2026-01-17 21:35, Lawrence D?Oliveiro wrote:
On Sat, 17 Jan 2026 14:33:32 +0100, Carlos E.R. wrote:
syslog daemons are very versatile, after decades of usage.
But they still don?t make it easy to view messages with times
displayed according to different time zones.
LOL. Why would I want that?
Because of the way Linux servers are commonly used.
The machine may be located in a remote colo facility in one time zone.
A customer may call up with a problem from a different time zone. The sysadmin tasked with fixing the problem may be operating from yet
another time zone.
In this situation, it is helpful to be able to connect to the server
and view log messages with times shown in the customer?s time zone, to
make it easier to match up messages close to the time the customer
reported the problem.
You?ve never worked across different time zones? I have.
"Carlos E.R." <robin_listas@es.invalid> writes:
I want to purge from the journal all messages from facility=news,
level>Warning, age> 7 days. Only those messages. Leave all the rest
intact.
Doing this goes against the philosophy of the journal, so it is
intentionally imposible.
It?s a long-standing TODO[1]. There is also support for multiple
namespaces with different expiry policies, but I suspect it?s not
flexible enought to meet your requirements in a sensible way.
Anyway, this is not consistent with ?intentionally impossible?. It just hasn?t been implemented yet.
[1] from https://github.com/systemd/systemd/blob/main/TODO#L2454:
- journald: allow per-priority and per-service retention times when
rotating/vacuuming
On 2026-01-17 21:34, Lawrence D?Oliveiro wrote:
On Fri, 16 Jan 2026 22:53:47 +0100, Carlos E.R. wrote:
On 2026-01-16 22:41, Lawrence D?Oliveiro wrote:
This involves splitting out the messages into categories upfront, at
collection time, not analysis time.
Certainly. That's the syslog way.
That?s not a very scientific way.
systemd collects all data, and does not provide any means to purge
selectively some data.
I already explained to you how you can do exactly that.
Not with tools officially provided by the systemd people.
However, you can have syslog generate the entries in the UTC "time
zone", and convert the logs to another set in whatever other time zone
you wish.
By the way, syslog doesn't get all the boot messages.
I was told it was ?intentionally impossible? by people in the know
back then.
On Sat, 17 Jan 2026 22:57:44 +0100, Carlos E.R. wrote:
On 2026-01-17 21:34, Lawrence D?Oliveiro wrote:
On Fri, 16 Jan 2026 22:53:47 +0100, Carlos E.R. wrote:
On 2026-01-16 22:41, Lawrence D?Oliveiro wrote:
This involves splitting out the messages into categories upfront, at >>>>> collection time, not analysis time.
Certainly. That's the syslog way.
That?s not a very scientific way.
systemd collects all data, and does not provide any means to purge
selectively some data.
I already explained to you how you can do exactly that.
Not with tools officially provided by the systemd people.
Yes they were. I gave you man page references and everything.
On Sun, 18 Jan 2026 12:50:13 +0100, Carlos E.R. wrote:
By the way, syslog doesn't get all the boot messages.
That?s one of the goals of systemd, to be able to capture messages
from as early as possible.
On Sun, 18 Jan 2026 12:59:03 +0100, Carlos E.R. wrote:
I was told it was ?intentionally impossible? by people in the know
back then.
Obviously, whatever it was they were ?in the know? about, it wasn?t
systemd.
Shouldn?t it have been obvious to you, even back then if not now, that
you *cannot* design Open Source software to make anything (short of
violating the laws of mathematics or physics) ?intentionally
impossible??
On Sun, 18 Jan 2026 12:55:40 +0100, Carlos E.R. wrote:
However, you can have syslog generate the entries in the UTC "time
zone", and convert the logs to another set in whatever other time zone
you wish.
But you can?t do that with tools provided with syslog.
On 2026-01-18 22:04, Lawrence D?Oliveiro wrote:
On Sun, 18 Jan 2026 12:50:13 +0100, Carlos E.R. wrote:
By the way, syslog doesn't get all the boot messages.
That?s one of the goals of systemd, to be able to capture messages
from as early as possible.
Syslog, before systemd intervened, managed to capture all messages
just fine.
On 2026-01-18 22:02, Lawrence D?Oliveiro wrote:
On Sun, 18 Jan 2026 12:55:40 +0100, Carlos E.R. wrote:
... and convert the logs to another set in whatever other time zone
you wish.
But you can?t do that with tools provided with syslog.
Certainly it can.
On 2026-01-18 22:06, Lawrence D?Oliveiro wrote:
On Sun, 18 Jan 2026 12:59:03 +0100, Carlos E.R. wrote:
I was told it was ?intentionally impossible? by people in the know
back then.
Obviously, whatever it was they were ?in the know? about, it wasn?t
systemd.
Oh, yes they were. Systemd devs.
Syslog, before systemd intervened, managed to capture all messages just >fine.
I am saying that systemd is not passing all the messages to syslog.
On Sun, 18 Jan 2026 23:04:33 +0100, Carlos E.R. wrote:
On 2026-01-18 22:04, Lawrence D?Oliveiro wrote:
On Sun, 18 Jan 2026 12:50:13 +0100, Carlos E.R. wrote:
By the way, syslog doesn't get all the boot messages.
That?s one of the goals of systemd, to be able to capture messages
from as early as possible.
Syslog, before systemd intervened, managed to capture all messages
just fine.
It was never able to capture the dmesg stuff, as far as I know.
On Sun, 18 Jan 2026 23:06:36 +0100, Carlos E.R. wrote:
On 2026-01-18 22:06, Lawrence D?Oliveiro wrote:
On Sun, 18 Jan 2026 12:59:03 +0100, Carlos E.R. wrote:
I was told it was ?intentionally impossible? by people in the know
back then.
Obviously, whatever it was they were ?in the know? about, it wasn?t
systemd.
Oh, yes they were. Systemd devs.
All I can say is, either they misinterpreted your question, or you misinterpreted their reply. Because the tools provided do indeed allow
you to filter the logs in exactly the way you have described.
"Carlos E.R." <robin_listas@es.invalid> wrote:
Syslog, before systemd intervened, managed to capture all messages just
fine.
That was usually done by piping dmesg's output (the kernel ring
buffer) to syslog later during system startup once syslog is running.
I am saying that systemd is not passing all the messages to syslog.
It surely can be configured to do so. File a bug with your
Distribution. The kernel ring buffer still exists.
On 2026-01-19 09:56, Marc Haber wrote:
"Carlos E.R." <robin_listas@es.invalid> wrote:
Syslog, before systemd intervened, managed to capture all messages just
fine.
That was usually done by piping dmesg's output (the kernel ring
buffer) to syslog later during system startup once syslog is running.
I am saying that systemd is not passing all the messages to syslog.
It surely can be configured to do so. File a bug with your
Distribution. The kernel ring buffer still exists.
I will have to investigate one day what is going on.
"Carlos E.R." <robin_listas@es.invalid> wrote:
On 2026-01-19 09:56, Marc Haber wrote:
"Carlos E.R." <robin_listas@es.invalid> wrote:
Syslog, before systemd intervened, managed to capture all messages just >>>> fine.
That was usually done by piping dmesg's output (the kernel ring
buffer) to syslog later during system startup once syslog is running.
I am saying that systemd is not passing all the messages to syslog.
It surely can be configured to do so. File a bug with your
Distribution. The kernel ring buffer still exists.
I will have to investigate one day what is going on.
I bought a new notebook in late 2024 and deliberately didn't install
syslog. Just to force myself to get more acquainted with journalctl
since there will be a day when I'll have to fix a server that doesn't
have syslog. THEN I won't have time to read up on journalctl.
Oh, I can use fine journalctl.
When I report on bugzilla I use that.
However, I do have problems with eliminating from the log the hugely
verbose news facility, mail facility, and authpriv. With the
concoction I have, some parts disappear, because they are not assigned
any facility.
From one of my bugzillas:
journalctl --boot=-2 --facility=kern,user,daemon,auth,syslog,lpr,uucp,cron,authpriv,ftp,12,13,14,15,local0,local1,local2,local3,local4,local5,local6,local7 > journal_purged
However, notice that several megabytes of messages like this:
Feb 18 12:17:58 Telcontar sddm[2599]: Initializing...
are also missing. They are facility 1, should not be removed. I know they are fac 1 by comparison with syslog:
<1.4> 2025-02-24T01:03:30.963177+01:00 Telcontar sddm 2599 - - Signal received: SIGTERM
*..... I print the <fac.prio> numbers.
If you need those messages in the log, please advise how to remove
mail and news messages from the journal. Grep doesn't work because
news messages are multiline.
However, I do have problems with eliminating from the log the hugely
verbose news facility, mail facility, and authpriv. With the
concoction I have, some parts disappear, because they are not
assigned any facility.
"Carlos E.R." <robin_listas@es.invalid> writes:
Oh, I can use fine journalctl.
When I report on bugzilla I use that.
However, I do have problems with eliminating from the log the hugely
verbose news facility, mail facility, and authpriv. With the
concoction I have, some parts disappear, because they are not assigned
any facility.
From one of my bugzillas:
journalctl --boot=-2 --facility=kern,user,daemon,auth,syslog,lpr,uucp,cron,authpriv,ftp,12,13,14,15,local0,local1,local2,local3,local4,local5,local6,local7 > journal_purged
However, notice that several megabytes of messages like this:
Feb 18 12:17:58 Telcontar sddm[2599]: Initializing...
are also missing. They are facility 1, should not be removed. I know they are fac 1 by comparison with syslog:
<1.4> 2025-02-24T01:03:30.963177+01:00 Telcontar sddm 2599 - - Signal received: SIGTERM
*..... I print the <fac.prio> numbers.
If you need those messages in the log, please advise how to remove
mail and news messages from the journal. Grep doesn't work because
news messages are multiline.
Not 100% clear what you?re asking but wouldn?t journalctl --unit= with
the unit(s) you care about be sufficient?
On Mon, 19 Jan 2026 22:46:49 +0100, Carlos E.R. wrote:
However, I do have problems with eliminating from the log the hugely
verbose news facility, mail facility, and authpriv. With the
concoction I have, some parts disappear, because they are not
assigned any facility.
Is that really such a big deal, collecting a few gigabytes of extra
messages that you don?t want? They shouldn?t slow down journal access,
and can be easily filtered out on queries.
On 2026-01-20 00:05, Richard Kettlewell wrote:
Not 100% clear what you?re asking but wouldn?t journalctl --unit=
with the unit(s) you care about be sufficient?
No. I have to provide all units for a report. I remove those that
are private or irrelevant, like news.
On 2026-01-20 00:05, Richard Kettlewell wrote:
Not 100% clear what you?re asking but wouldn?t journalctl --unit=
with the unit(s) you care about be sufficient?
No. I have to provide all units for a report. I remove those that are
private or irrelevant, like news.
"Carlos E.R." <robin_listas@es.invalid> writes:
On 2026-01-20 00:05, Richard Kettlewell wrote:
Not 100% clear what you?re asking but wouldn?t journalctl --unit=
with the unit(s) you care about be sufficient?
No. I have to provide all units for a report. I remove those that are
private or irrelevant, like news.
Right, so all units except the ones you don?t care about. Same thing,
just phrased differently.
On 2026-01-20 09:37, Richard Kettlewell wrote:
"Carlos E.R." <robin_listas@es.invalid> writes:
On 2026-01-20 00:05, Richard Kettlewell wrote:Right, so all units except the ones you don?t care about. Same thing,
Not 100% clear what you?re asking but wouldn?t journalctl --unit=
with the unit(s) you care about be sufficient?
No. I have to provide all units for a report. I remove those that are
private or irrelevant, like news.
just phrased differently.
Using units is impossible.
cer@Telcontar:~> journalctl --field=_SYSTEMD_UNIT | wc -l
5433
cer@Telcontar:~>
Imagine the command line listing all those five thousand units.
We tried several concoctions, and the command that worked best was this:
journalctl --boot=-2 --facility=kern,user,daemon,auth,syslog,lpr,uucp,cron,authpriv,ftp,12,13,14,15,local0,local1,local2,local3,local4,local5,local6,local7
journal_purged
Not units, but facilities. Problem is, there is no command to say "all except...", instead you have to explicitly list all of them except
those you do not want to include.
And then there is another problem, that some entries do not have a
facility assigned, it got lost somewhere. They do have a facility when
seen on syslog. It is a systemd bug.
"Carlos E.R." <robin_listas@es.invalid> writes:
On 2026-01-20 09:37, Richard Kettlewell wrote:
"Carlos E.R." <robin_listas@es.invalid> writes:
On 2026-01-20 00:05, Richard Kettlewell wrote:Right, so all units except the ones you don?t care about. Same thing,
Not 100% clear what you?re asking but wouldn?t journalctl --unit=
with the unit(s) you care about be sufficient?
No. I have to provide all units for a report. I remove those that are
private or irrelevant, like news.
just phrased differently.
Using units is impossible.
cer@Telcontar:~> journalctl --field=_SYSTEMD_UNIT | wc -l
5433
cer@Telcontar:~>
Imagine the command line listing all those five thousand units.
I don?t have any trouble imagining it and nor does journalctl, which empirically accepts command lines with 5000 -u options without
complaint. So I don?t see any justification for calling it impossible.
We tried several concoctions, and the command that worked best was this:
journalctl --boot=-2
--facility=kern,user,daemon,auth,syslog,lpr,uucp,cron,authpriv,ftp,12,13,14,15,local0,local1,local2,local3,local4,local5,local6,local7
journal_purged
Not units, but facilities. Problem is, there is no command to say "all
except...", instead you have to explicitly list all of them except
those you do not want to include.
The lack of ?all except? is unfortunate, agreed.
The sd_journal_... API looks fairly simple, you could probably write
your own program to filter entries in whatever way you like in just a
few lines.
And then there is another problem, that some entries do not have a
facility assigned, it got lost somewhere. They do have a facility when
seen on syslog. It is a systemd bug.
Syslog facilities are an optional backward compatibility feature in
journald. Lots of messages won?t have one. That?s not a bug, that?s just
a difference between the syslog and journal data models.
If you forward all messages to a syslogd then I assume it?ll look like they?ve gained a facility even if they didn?t have one originally,
because syslogd?s data model makes the facility non-optional.
That I have to find those thousand of units and type them.
Not units, but facilities. Problem is, there is no command to say
"all except...", instead you have to explicitly list all of them
except those you do not want to include.
And then there is another problem, that some entries do not have a
facility assigned, it got lost somewhere. They do have a facility
when seen on syslog. It is a systemd bug.
On 2026-01-20 18:37, Richard Kettlewell wrote:
"Carlos E.R." <robin_listas@es.invalid> writes:
On 2026-01-20 09:37, Richard Kettlewell wrote:I don?t have any trouble imagining it and nor does journalctl, which
"Carlos E.R." <robin_listas@es.invalid> writes:
On 2026-01-20 00:05, Richard Kettlewell wrote:Right, so all units except the ones you don?t care about. Same thing,
Not 100% clear what you?re asking but wouldn?t journalctl --unit=
with the unit(s) you care about be sufficient?
No. I have to provide all units for a report. I remove those that are >>>>> private or irrelevant, like news.
just phrased differently.
Using units is impossible.
cer@Telcontar:~> journalctl --field=_SYSTEMD_UNIT | wc -l
5433
cer@Telcontar:~>
Imagine the command line listing all those five thousand units.
empirically accepts command lines with 5000 -u options without
complaint. So I don?t see any justification for calling it impossible.
That I have to find those thousand of units and type them.
The sd_journal_... API looks fairly simple, you could probably write
your own program to filter entries in whatever way you like in just a
few lines.
On Tue, 20 Jan 2026 14:04:04 +0100, Carlos E.R. wrote:
Not units, but facilities. Problem is, there is no command to say
"all except...", instead you have to explicitly list all of them
except those you do not want to include.
journalctl $(for u in $(journalctl --field=_SYSTEMD_UNIT); do if [[ "$u" == *.service ]]; then echo _SYSTEMD_UNIT="$u"; fi; done)
And then there is another problem, that some entries do not have a
facility assigned, it got lost somewhere. They do have a facility
when seen on syslog. It is a systemd bug.
But if you have systemd capturing the messages and then passing them
on to syslog, then the information must be reaching systemd, and be
perserved by it.
On 2026-01-20 00:24, Lawrence D?Oliveiro wrote:
On Mon, 19 Jan 2026 22:46:49 +0100, Carlos E.R. wrote:
However, I do have problems with eliminating from the log the hugely
verbose news facility, mail facility, and authpriv. With the
concoction I have, some parts disappear, because they are not
assigned any facility.
Is that really such a big deal, collecting a few gigabytes of extra
messages that you don?t want? They shouldn?t slow down journal access,
and can be easily filtered out on queries.
You miss the context. I was reporting a bugzilla. The attachment to
bugzilla have limited size, a few megabytes ...
On Tue, 20 Jan 2026 02:39:11 +0100, Carlos E.R. wrote:
On 2026-01-20 00:24, Lawrence D?Oliveiro wrote:
On Mon, 19 Jan 2026 22:46:49 +0100, Carlos E.R. wrote:
However, I do have problems with eliminating from the log the hugely
verbose news facility, mail facility, and authpriv. With the
concoction I have, some parts disappear, because they are not
assigned any facility.
Is that really such a big deal, collecting a few gigabytes of extra
messages that you don?t want? They shouldn?t slow down journal access,
and can be easily filtered out on queries.
You miss the context. I was reporting a bugzilla. The attachment to
bugzilla have limited size, a few megabytes ...
That?s what the filtering options in journalctl are for.
On 2026-01-23 06:48, Lawrence D?Oliveiro wrote:
That?s what the filtering options in journalctl are for.
You are deflecting.
On Fri, 23 Jan 2026 14:07:39 +0100, Carlos E.R. wrote:
On 2026-01-23 06:48, Lawrence D?Oliveiro wrote:
That?s what the filtering options in journalctl are for.
You are deflecting.
You are the one who keeps ducking and dodging. First you complained
about filtering. When this was explained to you,
you then complained
about data collection and retention. When hints were offered as to how
to trim this (as if it was really important), you are now back to
complaining about filtering.
On 2026-01-23 22:19, Lawrence D?Oliveiro wrote:
On Fri, 23 Jan 2026 14:07:39 +0100, Carlos E.R. wrote:
On 2026-01-23 06:48, Lawrence D?Oliveiro wrote:
That?s what the filtering options in journalctl are for.
You are deflecting.
You are the one who keeps ducking and dodging. First you complained
about filtering. When this was explained to you,
You did not, and I proved it you that your filters do not work.
you then complained
about data collection and retention. When hints were offered as to how
to trim this (as if it was really important), you are now back to
complaining about filtering.
You did not, and I proved it you that your advice does not work.
On 1/23/26 13:26, Carlos E.R. wrote:
On 2026-01-23 22:19, Lawrence D?Oliveiro wrote:
Filter this Troll.
| Sysop: | Jacob Catayoc |
|---|---|
| Location: | Pasay City, Metro Manila, Philippines |
| Users: | 5 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 19:03:59 |
| Calls: | 117 |
| Calls today: | 117 |
| Files: | 367 |
| D/L today: |
540 files (253M bytes) |
| Messages: | 70,845 |
| Posted today: | 26 |