The Natural Philosopher <tnp@invalid.invalid> writes:
I have an errant service spewing out pages of errors.
It appears that journalctl is not able to clear a single service from
its log files.
Anyone know different?
https://serverfault.com/questions/1053748/how-can-i-ask-journalctl-to-show-records-for-all-units-except-one
On 10/03/2025 18:12, Dan Espen wrote:
The Natural Philosopher <tnp@invalid.invalid> writes:What has that got to do with the question?
I have an errant service spewing out pages of errors.
It appears that journalctl is not able to clear a single service from
its log files.
Anyone know different?
https://serverfault.com/questions/1053748/how-can-i-ask-journalctl-to-
show-records-for-all-units-except-one
The Natural Philosopher <tnp@invalid.invalid> writes:
On 10/03/2025 18:12, Dan Espen wrote:
The Natural Philosopher <tnp@invalid.invalid> writes:What has that got to do with the question?
I have an errant service spewing out pages of errors.https://serverfault.com/questions/1053748/how-can-i-ask-journalctl-to-show-records-for-all-units-except-one
It appears that journalctl is not able to clear a single service from
its log files.
Anyone know different?
Ask better questions.
https://serverfault.com/questions/858843/how-to-disable-logging-for-a-particular-systemd-unit
On 2025-03-10 19:40, The Natural Philosopher wrote:
On 10/03/2025 18:12, Dan Espen wrote:
The Natural Philosopher <tnp@invalid.invalid> writes:What has that got to do with the question?
I have an errant service spewing out pages of errors.
It appears that journalctl is not able to clear a single service from
its log files.
Anyone know different?
https://serverfault.com/questions/1053748/how-can-i-ask-journalctl-to- show-records-for-all-units-except-one
Systemd by intentional design can not clear anything from its log files.
You should know this.
On 10/03/2025 18:45, Carlos E.R. wrote:
On 2025-03-10 19:40, The Natural Philosopher wrote:Of course it can.
On 10/03/2025 18:12, Dan Espen wrote:
The Natural Philosopher <tnp@invalid.invalid> writes:What has that got to do with the question?
I have an errant service spewing out pages of errors.
It appears that journalctl is not able to clear a single service from >>>>> its log files.
Anyone know different?
https://serverfault.com/questions/1053748/how-can-i-ask-journalctl-
to- show-records-for-all-units-except-one
Systemd by intentional design can not clear anything from its log
files. You should know this.
The problem is it doesn't do it selectively by service, only globally
by time or by size.
IN short journalctl is fundamentally broken.
On 10/03/2025 20:37, Dan Espen wrote:
The Natural Philosopher <tnp@invalid.invalid> writes:Don't want not to log. Want to look at the logs, clear the problem and
On 10/03/2025 18:12, Dan Espen wrote:
The Natural Philosopher <tnp@invalid.invalid> writes:What has that got to do with the question?
I have an errant service spewing out pages of errors.https://serverfault.com/questions/1053748/how-can-i-ask-journalctl-
It appears that journalctl is not able to clear a single service from >>>>> its log files.
Anyone know different?
to-show-records-for-all-units-except-one
Ask better questions.
https://serverfault.com/questions/858843/how-to-disable-logging-for-a-
particular-systemd-unit
delete the debug log as its now enormous
Why should I have to go to enormous lengths to do something perfectly
routine just because systemd was written by a cunt who said 'my way or
the highway'...
On 2025-03-10 21:53, The Natural Philosopher wrote:
Don't want not to log. Want to look at the logs, clear the problem and
delete the debug log as its now enormous
That's impossible to do, by intentional design.
On 2025-03-10 21:50, The Natural Philosopher wrote:
On 10/03/2025 18:45, Carlos E.R. wrote:
On 2025-03-10 19:40, The Natural Philosopher wrote:Of course it can.
On 10/03/2025 18:12, Dan Espen wrote:
The Natural Philosopher <tnp@invalid.invalid> writes:What has that got to do with the question?
I have an errant service spewing out pages of errors.
It appears that journalctl is not able to clear a single service from >>>>>> its log files.
Anyone know different?
https://serverfault.com/questions/1053748/how-can-i-ask-journalctl-
to- show-records-for-all-units-except-one
Systemd by intentional design can not clear anything from its log
files. You should know this.
The problem is it doesn't do it selectively by service, only globally
by time or by size.
IN short journalctl is fundamentally broken.
No, it can not do. The journal contains everything, nothing can be
removed. This is intentional by design. At display time, you can choose
what to show, which is different.
Obviously it can delete old entries, that's different. Either by date,
or by choosing what total size to keep.
Nothing is broken, it has been intentionally designed this way, looking
at integrity of the recorded data, which can be, I heard,
cryptographically signed.
On 2025-03-10 21:53, The Natural Philosopher wrote:
On 10/03/2025 20:37, Dan Espen wrote:
The Natural Philosopher <tnp@invalid.invalid> writes:Don't want not to log. Want to look at the logs, clear the problem and
On 10/03/2025 18:12, Dan Espen wrote:
The Natural Philosopher <tnp@invalid.invalid> writes:What has that got to do with the question?
I have an errant service spewing out pages of errors.https://serverfault.com/questions/1053748/how-can-i-ask-journalctl-
It appears that journalctl is not able to clear a single service from >>>>>> its log files.
Anyone know different?
to-show-records-for-all-units-except-one
Ask better questions.
https://serverfault.com/questions/858843/how-to-disable-logging-for-a- particular-systemd-unit
delete the debug log as its now enormous
That's impossible to do, by intentional design.
Why should I have to go to enormous lengths to do something perfectly
routine just because systemd was written by a cunt who said 'my way or
the highway'...
It is a free system, you can choose not to use it if you don't like it.
And yes, I would also like to remove some facilities from the journal
after some days. Not possible.
On Mon, 10 Mar 2025 23:14:19 +0100
"Carlos E.R." <robin_listas@es.invalid> wrote:
Nothing is broken, it has been intentionally designed this way
Okay, sure - but that design is stupid.
The Natural Philosopher <tnp@invalid.invalid> wrote:
<snip>
It would be very easy to scan the file and copy to a new one deleting
specific instances to remove certain classes of logs, but the
programmers were too lazy and arrogant to be bothered to do it
IIRC, from articles I read, this journal is a binary file
with some form of database type keys. So I would think if
it has keys, a function would exist where one can delete a
group of entries similar to what you can do via SQL or in
the old Berkeley D/B.
But based upon this thread, that cannot be done. So I see
it as a "miss" on the systemd people. I would think such a
function would be kind of easy to do.
This looks like some kind of key to me :)
https://wiki.archlinux.org/title/Systemd/Journal#Facility
<snip>
It would be very easy to scan the file and copy to a new one deleting specific instances to remove certain classes of logs, but the
programmers were too lazy and arrogant to be bothered to do it
On 10/03/2025 22:28, John Ames wrote:
On Mon, 10 Mar 2025 23:14:19 +0100Exactly.
"Carlos E.R." <robin_listas@es.invalid> wrote:
Nothing is broken, it has been intentionally designed this way
Okay, sure - but that design is stupid.
Journalctl should be able to take the One True Logfile and scan it,
rewriting items to be retained and discarding items to be deleted .
On Mon, 10 Mar 2025 23:17:40 +0100, Carlos E.R. wrote:
On 2025-03-10 21:53, The Natural Philosopher wrote:
Don't want not to log. Want to look at the logs, clear the problem and
delete the debug log as its now enormous
That's impossible to do, by intentional design.
<https://manpages.debian.org/journalctl(1)>:
--rotate
On 10/03/2025 22:17, Carlos E.R. wrote:
It is a free system, you can choose not to use it if you don't like it.Completely possible if you are a competent programmer.
And yes, I would also like to remove some facilities from the journal
after some days. Not possible.
If you can display only a single service you can delete only a single service.
Its just *harder* and we know systemd is all about needless complexity,
not user friendly well written code.
On 3/11/25 11:28, John McCue wrote:
The Natural Philosopher <tnp@invalid.invalid> wrote:
<snip>
It would be very easy to scan the file and copy to a new one deleting
specific instances to remove certain classes of logs, but the
programmers were too lazy and arrogant to be bothered to do it
IIRC, from articles I read, this journal is a binary file
with some form of database type keys. So I would think if
it has keys, a function would exist where one can delete a
group of entries similar to what you can do via SQL or in
the old Berkeley D/B.
But based upon this thread, that cannot be done. So I see
it as a "miss" on the systemd people. I would think such a
function would be kind of easy to do.
This looks like some kind of key to me :)
https://wiki.archlinux.org/title/Systemd/Journal#Facility
<snip>
It is not clear to me if this is a flaw or an advantage. Where the OS is
used for important/critical processing, it is clearly an advantage to
have a reliable audit trail. No updates or deletions, if you want to
alter the way it looks you make additional entries, corrections. This
pattern works fine for accounting systems.
I guess the only real downside for OS logging is additional log space required. It should be possible to achieve virtual deletions with
persistent filtering entries. Maybe they intend to do this, or maybe
they feel people should be happy with filtering as is, and it is an unnecessary complexity.
It is also worth mentioning that supporting one type of logging for mission-critical systems and another type for TNP's heating system, by default, may introduce additional complexity in itself.
I quite like systemd, not because it is good, but because it is
standard, good enough.
On 10/03/2025 22:28, John Ames wrote:
On Mon, 10 Mar 2025 23:14:19 +0100Exactly.
"Carlos E.R." <robin_listas@es.invalid> wrote:
Nothing is broken, it has been intentionally designed this way
Okay, sure - but that design is stupid.
Journalctl should be able to take the One True Logfile and scan it,
rewriting items to be retained and discarding items to be deleted .
t is also worth mentioning that supporting one type of logging for mission-critical systems and another type for TNP's heating system, by default, may introduce additional complexity in itself.
Bye, a-hole.
On 2025-03-11 08:49, The Natural Philosopher wrote:
On 10/03/2025 22:17, Carlos E.R. wrote:
...
It is a free system, you can choose not to use it if you don't like it.Completely possible if you are a competent programmer.
And yes, I would also like to remove some facilities from the journal
after some days. Not possible.
If you can display only a single service you can delete only a single
service.
Its just *harder* and we know systemd is all about needless
complexity, not user friendly well written code.
Get it into your head that they refuse to do it. Intentionally. They
have said so. Integrity of data reasons, for auditability.
If you are a competent programmer you can study the structure of the
files and create a program to erase entries from inside the files.
Nobody has created that software, to my knowledge. Why?
On 2025-03-11 08:58, The Natural Philosopher wrote:
On 10/03/2025 22:28, John Ames wrote:Nope.
On Mon, 10 Mar 2025 23:14:19 +0100Exactly.
"Carlos E.R." <robin_listas@es.invalid> wrote:
Nothing is broken, it has been intentionally designed this way
Okay, sure - but that design is stupid.
Journalctl should be able to take the One True Logfile and scan it,
rewriting items to be retained and discarding items to be deleted .
That's manipulating information and has legal implications. Yes, that's
the intentional reason why systemd refuses to do it.
On Tue, 11 Mar 2025 03:58:44 -0400, The Natural Philosopher <tnp@invalid.invalid> wrote:
On 10/03/2025 22:28, John Ames wrote:
On Mon, 10 Mar 2025 23:14:19 +0100Exactly.
"Carlos E.R." <robin_listas@es.invalid> wrote:
Nothing is broken, it has been intentionally designed this way
Okay, sure - but that design is stupid.
Journalctl should be able to take the One True Logfile and scan it,
rewriting items to be retained and discarding items to be deleted .
In other words make it as easy as possible for an inttruder to cover any trace of their
activities.
Great log that would be for determining what an intruder did.
Regards, Dave Hodgins
In <vqpgt8$20t6v$1@dont-email.me> Dan Espen:
[Snip...]
Bye, a-hole.
+1
On 11/03/2025 12:17, Carlos E.R. wrote:
On 2025-03-11 08:58, The Natural Philosopher wrote:So is truncating it to the last day, or the last 25Mbyte. Which it quite happily does.
On 10/03/2025 22:28, John Ames wrote:Nope.
On Mon, 10 Mar 2025 23:14:19 +0100Exactly.
"Carlos E.R." <robin_listas@es.invalid> wrote:
Nothing is broken, it has been intentionally designed this way
Okay, sure - but that design is stupid.
Journalctl should be able to take the One True Logfile and scan it,
rewriting items to be retained and discarding items to be deleted .
That's manipulating information and has legal implications. Yes,
that's the intentional reason why systemd refuses to do it.
And this isn't just truncating it, if it is a flat file it has to be rewritten to exclude the front. If its a database, it has to delete
certain records
And I am sure the first thing any hacker would do would be to write a
decent journalctl that would erase his presence selectively
So I am sorry, your arguments are as full of holes as Eliza's bucket
On 10/03/2025 22:28, John Ames wrote:
On Mon, 10 Mar 2025 23:14:19 +0100Exactly.
"Carlos E.R." <robin_listas@es.invalid> wrote:
Nothing is broken, it has been intentionally designed this way
Okay, sure - but that design is stupid.
Journalctl should be able to take the One True Logfile and scan it,
rewriting items to be retained and discarding items to be deleted .
All its creator could be bothered to do was to simply enable it to
truncate the One True Logfile thus losing potentially important log
entries.
It seems to have no inherent concept of important versus less important logs.
On 2025-03-11 15:50, The Natural Philosopher wrote:
On 11/03/2025 12:17, Carlos E.R. wrote:
On 2025-03-11 08:58, The Natural Philosopher wrote:So is truncating it to the last day, or the last 25Mbyte. Which it
On 10/03/2025 22:28, John Ames wrote:Nope.
On Mon, 10 Mar 2025 23:14:19 +0100Exactly.
"Carlos E.R." <robin_listas@es.invalid> wrote:
Nothing is broken, it has been intentionally designed this way
Okay, sure - but that design is stupid.
Journalctl should be able to take the One True Logfile and scan it,
rewriting items to be retained and discarding items to be deleted .
That's manipulating information and has legal implications. Yes,
that's the intentional reason why systemd refuses to do it.
quite happily does.
And this isn't just truncating it, if it is a flat file it has to be
rewritten to exclude the front. If its a database, it has to delete
certain records
And I am sure the first thing any hacker would do would be to write a
decent journalctl that would erase his presence selectively
So I am sorry, your arguments are as full of holes as Eliza's bucket
Sure.
Why don't you google around to find a tool that lets you do it? It
should be easy, according to you.
On Tue, 11 Mar 2025 15:50:25 +0000
Pancho <Pancho.Jones@protonmail.com> wrote:
Carlos has already suggested that there might be a method to
cryptographically sign the logs, making alterations very difficult,
even to a privileged user.
Perhaps there is - but, as has already been pointed out, if journalctl
can delete records by date, it is certainly *possible* to delete
records by source. Any encryption that does not prevent the former
cannot prevent the latter.
On 11/03/2025 12:33, David W. Hodgins wrote:
On Tue, 11 Mar 2025 03:58:44 -0400, The Natural PhilosopherDont you think any intruder would not already have written a journalctl
<tnp@invalid.invalid> wrote:
On 10/03/2025 22:28, John Ames wrote:
On Mon, 10 Mar 2025 23:14:19 +0100Exactly.
"Carlos E.R." <robin_listas@es.invalid> wrote:
Nothing is broken, it has been intentionally designed this way
Okay, sure - but that design is stupid.
Journalctl should be able to take the One True Logfile and scan it,
rewriting items to be retained and discarding items to be deleted .
In other words make it as easy as possible for an inttruder to cover
any trace of their
activities.
Great log that would be for determining what an intruder did.
to do exactly that?
Sheesh
Regards, Dave Hodgins
On Tue, 11 Mar 2025 16:12:43 +0000
Pancho <Pancho.Jones@protonmail.com> wrote:
Yes cryptography doesn't stop you deleting records, it does allow
people to see when records have been deleted. When there is data
missing, data they would expect to see.
True - which further undermines the argument that purge-by-source
cannot be added without completely compromising audit accountability.
On 2025-03-11 08:58, The Natural Philosopher wrote:
On 10/03/2025 22:28, John Ames wrote:Nope.
On Mon, 10 Mar 2025 23:14:19 +0100Exactly.
"Carlos E.R." <robin_listas@es.invalid> wrote:
Nothing is broken, it has been intentionally designed this way
Okay, sure - but that design is stupid.
Journalctl should be able to take the One True Logfile and scan it,
rewriting items to be retained and discarding items to be deleted .
That's manipulating information and has legal implications. Yes,
that's the intentional reason why systemd refuses to do it.
On 3/11/25 14:52, The Natural Philosopher wrote:
On 11/03/2025 12:33, David W. Hodgins wrote:
On Tue, 11 Mar 2025 03:58:44 -0400, The Natural PhilosopherDont you think any intruder would not already have written a
<tnp@invalid.invalid> wrote:
On 10/03/2025 22:28, John Ames wrote:
On Mon, 10 Mar 2025 23:14:19 +0100Exactly.
"Carlos E.R." <robin_listas@es.invalid> wrote:
Nothing is broken, it has been intentionally designed this way
Okay, sure - but that design is stupid.
Journalctl should be able to take the One True Logfile and scan it,
rewriting items to be retained and discarding items to be deleted .
In other words make it as easy as possible for an inttruder to cover
any trace of their
activities.
Great log that would be for determining what an intruder did.
journalctl to do exactly that?
Sheesh
Carlos has already suggested that there might be a method to cryptographically sign the logs, making alterations very difficult, even
to a privileged user.
The basic pattern for immutable audit logs is mature due to the
requirements of financial systems. Whether systemd have implemented a reliable system or not, I don't know, but they could.
Regards, Dave Hodgins
On Tue, 11 Mar 2025 16:12:43 +0000
Pancho <Pancho.Jones@protonmail.com> wrote:
Yes cryptography doesn't stop you deleting records, it does allow
people to see when records have been deleted. When there is data
missing, data they would expect to see.
True - which further undermines the argument that purge-by-source
cannot be added without completely compromising audit accountability.
What you can not do is remove content from the middle of the files. Specifically remove some content and leave intact other content.
This is forbidden in the design of the systemd journal, the developers
refuse to do it.
Completely possible if you are a competent programmer.
On Tue, 11 Mar 2025 15:29:02 +0000
The Natural Philosopher <tnp@invalid.invalid> wrote:
Really I would in a younger self simply rewrite it and put the code
on Github. But I am too old and tired to piss around wiping
Poettering's bottom for him.
It's a little tempting to do it anyway, just out of spite.
On 3/11/25 14:52, The Natural Philosopher wrote:
On 11/03/2025 12:33, David W. Hodgins wrote:
On Tue, 11 Mar 2025 03:58:44 -0400, The Natural PhilosopherDont you think any intruder would not already have written a journalctl to >> do exactly that?
<tnp@invalid.invalid> wrote:
On 10/03/2025 22:28, John Ames wrote:
On Mon, 10 Mar 2025 23:14:19 +0100Exactly.
"Carlos E.R." <robin_listas@es.invalid> wrote:
Nothing is broken, it has been intentionally designed this way
Okay, sure - but that design is stupid.
Journalctl should be able to take the One True Logfile and scan it,
rewriting items to be retained and discarding items to be deleted .
In other words make it as easy as possible for an inttruder to cover any >>> trace of their
activities.
Great log that would be for determining what an intruder did.
Sheesh
Carlos has already suggested that there might be a method to cryptographically sign the logs, making alterations very difficult, even to a privileged user.
The basic pattern for immutable audit logs is mature due to the requirements of financial systems. Whether systemd have implemented a reliable system or not, I don't know, but they could.
Regards, Dave Hodgins
On Tue, 11 Mar 2025 15:50:25 +0000
Pancho <Pancho.Jones@protonmail.com> wrote:
Carlos has already suggested that there might be a method to
cryptographically sign the logs, making alterations very difficult,
even to a privileged user.
Perhaps there is - but, as has already been pointed out, if journalctl
can delete records by date, it is certainly *possible* to delete
records by source. Any encryption that does not prevent the former
cannot prevent the latter.
Dont you think any intruder would not already have written a journalctl
to do exactly that?
... they decided to not implement deletion or filtering of the contents inside the files.
I remember people asked for this with journald and the response was to somehow pipe the data from journald into syslogd and that would mirror
it.
Also if entries are removed from the journal, a log on the remote system could be added stating "this entry was deleted by ? on ?". But maybe
the design makes this too hard.
And I am sure the first thing any hacker would do would be to write a
decent journalctl that would erase his presence selectively
It's a little tempting to do it anyway, just out of spite.
But I am too old and tired to piss around wiping Poettering's bottom
for him.
On Tue, 11 Mar 2025 15:50:25 +0000
Pancho <Pancho.Jones@protonmail.com> wrote:
Carlos has already suggested that there might be a method to
cryptographically sign the logs, making alterations very difficult,
even to a privileged user.
Perhaps there is - but, as has already been pointed out, if journalctl
can delete records by date, it is certainly *possible* to delete
records by source. Any encryption that does not prevent the former
cannot prevent the latter.
On Tue, 11 Mar 2025 17:37:33 -0000 (UTC), John McCue wrote:
I remember people asked for this with journald and the response was to
somehow pipe the data from journald into syslogd and that would mirror
it.
The journald config file already has options to mirror things to
syslog, and even not to write anything to the systemd journal files at
all <https://www.freedesktop.org/software/systemd/man/latest/journald.conf.html>.
Also if entries are removed from the journal, a log on the remote system
could be added stating "this entry was deleted by ? on ?". But maybe
the design makes this too hard.
The file format is designed to be append-only, for obvious reasons.
But it’s easy enough to extract records and save them to a new journal-format file <https://www.freedesktop.org/software/systemd/man/latest/systemd-journal-remote.html>
(or some other format if you prefer).
On 2025-03-12 00:42, Lawrence D'Oliveiro wrote:
The file format is designed to be append-only, for obvious reasons.
But it’s easy enough to extract records and save them to a new
journal-format file
<https://www.freedesktop.org/software/systemd/man/latest/systemd-journal-remote.html>
(or some other format if you prefer).
On another computer.
Note that the systemd journal is not just one logfile, it can be split out into multiple separate files.
Kind of like syslog, really.
On Tue, 11 Mar 2025, John Ames wrote:
On Tue, 11 Mar 2025 15:50:25 +0000
Pancho <Pancho.Jones@protonmail.com> wrote:
Carlos has already suggested that there might be a method to
cryptographically sign the logs, making alterations very difficult,
even to a privileged user.
Perhaps there is - but, as has already been pointed out, if journalctl
can delete records by date, it is certainly *possible* to delete
records by source. Any encryption that does not prevent the former
cannot prevent the latter.
It is software. Anything in software living on media that is not write protected can be changed. It just takes kung fu... skill and effort.
On Tue, 11 Mar 2025 23:44:41 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
And I am sure the first thing any hacker would do would be to write a
decent journalctl that would erase his presence selectively
But they cannot digitally sign the result with the right key, can they?
Which, again, undermines the argument that adding purge-by-source would irreparably compromise auditability.
On Wed, 12 Mar 2025 22:10:35 +0100, Carlos E.R. wrote:
On 2025-03-12 00:42, Lawrence D'Oliveiro wrote:
The file format is designed to be append-only, for obvious reasons.
But it’s easy enough to extract records and save them to a new
journal-format file
<https://www.freedesktop.org/software/systemd/man/latest/systemd-journal-remote.html>
(or some other format if you prefer).
On another computer.
Or do it on the same computer, why not.
On Wed, 12 Mar 2025 22:12:28 +0100
"Carlos E.R." <robin_listas@es.invalid> wrote:
Perhaps there is - but, as has already been pointed out, if
journalctl can delete records by date, it is certainly *possible*
to delete records by source. Any encryption that does not prevent
the former cannot prevent the latter.
It can delete by date, but only from the distant end of the log, not
on the middle.
Because they refuse to allow it in the official utilties, yes. Not
because it's technically impossible.
But the resulting file is not the one that "journalctl" reads, right?
On Wed, 12 Mar 2025 23:42:15 +0100, Carlos E.R. wrote:
But the resulting file is not the one that "journalctl" reads, right?
You can specify any filename you like. See the docs.
I have an errant service spewing out pages of errors.
It appears that journalctl is not able to clear a single service from
its log files.
Anyone know different?
On 2025-03-13 01:12, Lawrence D'Oliveiro wrote:
You can specify any filename you like. See the docs.
Certainly, but that's a problem. You can no longer run
journalctl --boot=-1
and get the expected modified results as the OP wants.
The Natural Philosopher <tnp@invalid.invalid> writes:
I have an errant service spewing out pages of errors.
It appears that journalctl is not able to clear a single service from
its log files.
Anyone know different?
Pass.
An approach that might suit you better:
* Send all the logs to syslog.
* Read/filter/delete the syslog files in the traditional way, instead of
using journalctl.
* Optionally, set the journal size to something small since you won’t be
using it much.
This used to be a standard configuration in Debian but I think they’ve changed the default now.
There’s two ways to do it:
1) Have journald forward to syslog.
2) Have syslog read from the journal.
The paragraph at the bottom of https://www.freedesktop.org/software/systemd/man/latest/journald.conf.html discusses the differences. I think option #2 would usually be the better choice, since it reduces the chance of missed messages.
https://www.loggly.com/ultimate-guide/centralizing-with-syslog/
describes how to set up both approaches. “Using imjournal” corresponds
to option #2.
I restart both services, I send a message with logger... everything
seems correct.
On Thu, 13 Mar 2025 09:37:10 +0100, Carlos E.R. wrote:
I restart both services, I send a message with logger... everything
seems correct.
Moral: much simpler to do it the systemd way to begin with.
On 2025-03-11 12:42, Pancho wrote:
It is not clear to me if this is a flaw or an advantage. Where the OS is
used for important/critical processing, it is clearly an advantage to
have a reliable audit trail. No updates or deletions, if you want to
alter the way it looks you make additional entries, corrections. This
pattern works fine for accounting systems.
Exactly.
Huh, no. I actually prefer syslog.
The other day I had to report a bug in the kernel. To do so I wanted to produce a journal log without private information: mail, and authpriv.
Also news because it is too big.
On Fri, 14 Mar 2025 12:57:19 +0100, Carlos E.R. wrote:
Huh, no. I actually prefer syslog.
The other day I had to report a bug in the kernel. To do so I wanted to
produce a journal log without private information: mail, and authpriv.
Also news because it is too big.
How would you have done it with syslog?
Le 11-03-2025, Carlos E.R. <robin_listas@es.invalid> a écrit :
On 2025-03-11 12:42, Pancho wrote:
It is not clear to me if this is a flaw or an advantage. Where the OS is >>> used for important/critical processing, it is clearly an advantage to
have a reliable audit trail. No updates or deletions, if you want to
alter the way it looks you make additional entries, corrections. This
pattern works fine for accounting systems.
Exactly.
And even for normal people. If you have been pawned and your computer is
used to attack a bank, the day the police come in your home, you are
happy the hacker couldn't hide his doing. For example.
On Fri, 14 Mar 2025 12:57:19 +0100, Carlos E.R. wrote:
Huh, no. I actually prefer syslog.
The other day I had to report a bug in the kernel. To do so I wanted to
produce a journal log without private information: mail, and authpriv.
Also news because it is too big.
How would you have done it with syslog?
On 2025-03-14 22:30, Lawrence D'Oliveiro wrote:
How would you have done it with syslog?
I just copy the /var/log/messages file. It already has that information filtered out.
On Sun, 16 Mar 2025 14:48:04 +0100, Carlos E.R. wrote:
On 2025-03-14 22:30, Lawrence D'Oliveiro wrote:
How would you have done it with syslog?
I just copy the /var/log/messages file. It already has that information
filtered out.
How was that filtered out?
I thought you wanted to exclude mail and authpriv facilities, yet you included them in your selection criteria.
On 2025-03-18 22:20, Lawrence D'Oliveiro wrote:
On Tue, 18 Mar 2025 20:03:34 +0100, Carlos E.R. wrote:
There is no mail in the /var/log/messages file at all, since ever.
Then why did you include “mail” in your list of facilities?
Because I copypasted the wrong line.
There is no mail in the /var/log/messages file at all, since ever.
On Tue, 18 Mar 2025 20:03:34 +0100, Carlos E.R. wrote:
There is no mail in the /var/log/messages file at all, since ever.
Then why did you include “mail” in your list of facilities?
On Tue, 18 Mar 2025 22:51:36 +0100, Carlos E.R. wrote:
On 2025-03-18 22:20, Lawrence D'Oliveiro wrote:
On Tue, 18 Mar 2025 20:03:34 +0100, Carlos E.R. wrote:
There is no mail in the /var/log/messages file at all, since ever.
Then why did you include “mail” in your list of facilities?
Because I copypasted the wrong line.
Anyway, to answer the question of how to extract the same information on
an older version of systemd, it could be done by exporting the journal in JSON format, and filtering it through a tool like jq.
By the way, the ability for journalctl to do the filtering by facility
itself was added in version 245, which came out five years ago. So I’m not sure why you’re still stuck with an older version.
On 2025-03-18 22:20, Lawrence D'Oliveiro wrote:
On Tue, 18 Mar 2025 20:03:34 +0100, Carlos E.R. wrote:
There is no mail in the /var/log/messages file at all, since ever.
Then why did you include “mail” in your list of facilities?
Because I copypasted the wrong line.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 493 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 156:45:35 |
| Calls: | 9,700 |
| Files: | 13,732 |
| Messages: | 6,179,576 |