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, >>>> just phrased differently.
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.
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: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,096 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 399:12:48 |
| Calls: | 14,036 |
| Calls today: | 2 |
| Files: | 187,082 |
| D/L today: |
2,669 files (1,652M bytes) |
| Messages: | 2,479,108 |