• More systemdCrap

    From The Natural Philosopher@21:1/5 to All on Mon Mar 10 16:29:41 2025
    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?

    --
    Climate Change: Socialism wearing a lab coat.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From The Natural Philosopher@21:1/5 to Dan Espen on Mon Mar 10 18:40:07 2025
    On 10/03/2025 18:12, Dan Espen wrote:
    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

    What has that got to do with the question?
    --
    "It was a lot more fun being 20 in the 70's that it is being 70 in the 20's" Joew Walsh

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carlos E.R.@21:1/5 to The Natural Philosopher on Mon Mar 10 19:45:36 2025
    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:

    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

    What has that got to do with the question?

    Systemd by intentional design can not clear anything from its log files.
    You should know this.

    --
    Cheers, Carlos.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From The Natural Philosopher@21:1/5 to Dan Espen on Mon Mar 10 20:53:08 2025
    On 10/03/2025 20:37, Dan Espen wrote:
    The Natural Philosopher <tnp@invalid.invalid> writes:

    On 10/03/2025 18:12, Dan Espen wrote:
    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

    What has that got to do with the question?

    Ask better questions.

    https://serverfault.com/questions/858843/how-to-disable-logging-for-a-particular-systemd-unit


    Don't want not to log. Want to look at the logs, clear the problem and
    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'...



    --
    Labour - a bunch of rich people convincing poor people to vote for rich
    people by telling poor people that "other" rich people are the reason
    they are poor.

    Peter Thompson

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From The Natural Philosopher@21:1/5 to Carlos E.R. on Mon Mar 10 20:50:09 2025
    On 10/03/2025 18:45, Carlos E.R. wrote:
    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:

    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

    What has that got to do with the question?

    Systemd by intentional design can not clear anything from its log files.
    You should know this.

    Of course it can.

    The problem is it doesn't do it selectively by service, only globally
    by time or by size.
    IN short journalctl is fundamentally broken.


    --
    Climate Change: Socialism wearing a lab coat.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carlos E.R.@21:1/5 to The Natural Philosopher on Mon Mar 10 23:14:19 2025
    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:
    On 10/03/2025 18:12, Dan Espen wrote:
    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

    What has that got to do with the question?

    Systemd by intentional design can not clear anything from its log
    files. You should know this.

    Of course it can.

    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.

    --
    Cheers, Carlos.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carlos E.R.@21:1/5 to The Natural Philosopher on Mon Mar 10 23:17:40 2025
    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:

    On 10/03/2025 18:12, Dan Espen wrote:
    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

    What has that got to do with the question?

    Ask better questions.

    https://serverfault.com/questions/858843/how-to-disable-logging-for-a-
    particular-systemd-unit


    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.

    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.

    --
    Cheers, Carlos.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Carlos E.R. on Mon Mar 10 23:33:40 2025
    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
    Asks the journal daemon to rotate journal files. This call
    does not return until the rotation operation is complete.
    Journal file rotation has the effect that all currently active
    journal files are marked as archived and renamed, so that they
    are never written to in future. New (empty) journal files are
    then created in their place. This operation may be combined
    with --vacuum-size=, --vacuum-time= and --vacuum-file= into a
    single command, see above.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From The Natural Philosopher@21:1/5 to Carlos E.R. on Tue Mar 11 07:45:12 2025
    On 10/03/2025 22:14, Carlos E.R. wrote:
    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:
    On 10/03/2025 18:12, Dan Espen wrote:
    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

    What has that got to do with the question?

    Systemd by intentional design can not clear anything from its log
    files. You should know this.

    Of course it can.

    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.

    Exactly. It's fundamentally broken

    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
    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.

    As I said designed to a stupid specification by a total wanker

    All logs are not created equal.

    --
    The lifetime of any political organisation is about three years before
    its been subverted by the people it tried to warn you about.

    Anon.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From The Natural Philosopher@21:1/5 to Carlos E.R. on Tue Mar 11 07:49:31 2025
    On 10/03/2025 22:17, Carlos E.R. wrote:
    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:

    On 10/03/2025 18:12, Dan Espen wrote:
    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

    What has that got to do with the question?

    Ask better questions.

    https://serverfault.com/questions/858843/how-to-disable-logging-for-a- particular-systemd-unit


    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.

    Of course its possible, even with the shit 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.

    Completely possible if you are a competent programmer.
    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.



    --
    Any fool can believe in principles - and most of them do!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From The Natural Philosopher@21:1/5 to John Ames on Tue Mar 11 07:58:44 2025
    On 10/03/2025 22:28, John Ames wrote:
    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.

    Exactly.

    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.

    Something built into syslog

    I cant believe anyone could defend that decision

    Turning up the gain on logging to debug with extreme prejudice is one of
    the most important uses of logs. To be unable to delete the mess left
    over after so doing without deleting other information that really needs
    to be retained is simply an indicator of an inexperienced programmer who
    has never maintained anything more than a smart watch in his entire life.



    --
    Any fool can believe in principles - and most of them do!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Pancho@21:1/5 to John McCue on Tue Mar 11 11:42:08 2025
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John McCue@21:1/5 to The Natural Philosopher on Tue Mar 11 11:28:27 2025
    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>

    --
    [t]csh(1) - "An elegant shell, for a more... civilized age."
    - Paraphrasing Star Wars

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carlos E.R.@21:1/5 to The Natural Philosopher on Tue Mar 11 13:17:53 2025
    On 2025-03-11 08:58, The Natural Philosopher wrote:
    On 10/03/2025 22:28, John Ames wrote:
    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.

    Exactly.

    Journalctl should be able to take the One True Logfile and scan it,
    rewriting items to be retained and discarding items to be deleted .

    Nope.

    That's manipulating information and has legal implications. Yes, that's
    the intentional reason why systemd refuses to do it.



    --
    Cheers, Carlos.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carlos E.R.@21:1/5 to Lawrence D'Oliveiro on Tue Mar 11 13:23:39 2025
    On 2025-03-11 00:33, Lawrence D'Oliveiro wrote:
    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

    Yes. This remove content from the end of the files. 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.


    --
    Cheers, Carlos.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carlos E.R.@21:1/5 to The Natural Philosopher on Tue Mar 11 13:27:22 2025
    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.

    And yes, I would also like to remove some facilities from the journal
    after some days. Not possible.

    Completely possible if you are a competent programmer.
    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?

    --
    Cheers, Carlos.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carlos E.R.@21:1/5 to Pancho on Tue Mar 11 13:21:25 2025
    On 2025-03-11 12:42, Pancho wrote:
    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.

    Exactly.


    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.

    No, they decided to not implement deletion or filtering of the contents
    inside the files. You may not agree with that, but that's their choice.
    It is free software, you are free to take up the code and implement the "missing" features. It is some sort of database. But perhaps that breaks structural integrity and doesn't work.


    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.





    --
    Cheers, Carlos.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David W. Hodgins@21:1/5 to The Natural Philosopher on Tue Mar 11 08:33:39 2025
    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 +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.

    Exactly.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From The Natural Philosopher@21:1/5 to Pancho on Tue Mar 11 14:45:52 2025
    On 11/03/2025 11:42, Pancho wrote:
    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.

    This wasn't on the heating system. This is the house server to be.

    The heating system logs to a ram log if it logs at all. Just put
    volatile in the systemd config and it goes to /var/run/log. I have it
    limited at 25M

    So it's (systemd) fine if you don't want to keep any logs at all and
    certainly not on an SD card.

    It's the server where I need decent control of logging.

    There are a lot of broken DNS servers out there it seems....


    --
    When plunder becomes a way of life for a group of men in a society, over
    the course of time they create for themselves a legal system that
    authorizes it and a moral code that glorifies it.

    Frédéric Bastiat

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Harold Stevens@21:1/5 to All on Tue Mar 11 09:47:09 2025
    In <vqpgt8$20t6v$1@dont-email.me> Dan Espen:

    [Snip...]

    Bye, a-hole.

    +1

    --
    Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
    Pardon any bogus email addresses (wookie) in place for spambots.
    Really, it's (wyrd) at att, dotted with net. * DO NOT SPAM IT. *
    I toss GoogleGroup (http://twovoyagers.com/improve-usenet.org/).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From The Natural Philosopher@21:1/5 to Carlos E.R. on Tue Mar 11 14:51:44 2025
    On 11/03/2025 12:27, Carlos E.R. wrote:
    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.

    And yes, I would also like to remove some facilities from the journal
    after some days. Not possible.

    Completely possible if you are a competent programmer.
    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?

    Cos they are arrogant lazy shits

    --
    "In our post-modern world, climate science is not powerful because it is
    true: it is true because it is powerful."

    Lucas Bergkamp

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From The Natural Philosopher@21:1/5 to Carlos E.R. on Tue Mar 11 14:50:27 2025
    On 11/03/2025 12:17, Carlos E.R. wrote:
    On 2025-03-11 08:58, The Natural Philosopher wrote:
    On 10/03/2025 22:28, John Ames wrote:
    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.

    Exactly.

    Journalctl should be able to take the One True Logfile and scan it,
    rewriting items to be retained and discarding items to be deleted .

    Nope.

    That's manipulating information and has legal implications. Yes, that's
    the intentional reason why systemd refuses to do it.

    So is truncating it to the last day, or the last 25Mbyte. Which 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







    --
    “Politics is the art of looking for trouble, finding it everywhere, diagnosing it incorrectly and applying the wrong remedies.”
    ― Groucho Marx

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From The Natural Philosopher@21:1/5 to David W. Hodgins on Tue Mar 11 14:52:41 2025
    On 11/03/2025 12:33, David W. Hodgins wrote:
    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 +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.

    Exactly.

    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.

    Dont you think any intruder would not already have written a journalctl
    to do exactly that?
    Sheesh

    Regards, Dave Hodgins

    --
    "In our post-modern world, climate science is not powerful because it is
    true: it is true because it is powerful."

    Lucas Bergkamp

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From The Natural Philosopher@21:1/5 to Harold Stevens on Tue Mar 11 14:53:41 2025
    On 11/03/2025 14:47, Harold Stevens wrote:
    In <vqpgt8$20t6v$1@dont-email.me> Dan Espen:

    [Snip...]

    Bye, a-hole.

    +1

    The post of the day...

    --
    "In our post-modern world, climate science is not powerful because it is
    true: it is true because it is powerful."

    Lucas Bergkamp

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carlos E.R.@21:1/5 to The Natural Philosopher on Tue Mar 11 15:59:05 2025
    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:
    On 10/03/2025 22:28, John Ames wrote:
    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.

    Exactly.

    Journalctl should be able to take the One True Logfile and scan it,
    rewriting items to be retained and discarding items to be deleted .

    Nope.

    That's manipulating information and has legal implications. Yes,
    that's the intentional reason why systemd refuses to do it.

    So is truncating it to the last day, or the last 25Mbyte. Which 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.

    --
    Cheers, Carlos.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From TJ@21:1/5 to The Natural Philosopher on Tue Mar 11 11:32:08 2025
    On 2025-03-11 03:58, The Natural Philosopher wrote:
    On 10/03/2025 22:28, John Ames wrote:
    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.

    Exactly.

    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.

    Oh, I dunno. I'm no Linux expert, by any measure, but I have kept logs
    in other areas of my life for many years.

    I have discovered over time that what is important to me today might not
    be so in the future, and equally, what seems unimportant now can become
    very important later.

    The information you don't want today should be retained in case you need
    it at some future date. If you delete it, it's gone.

    TJ

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From The Natural Philosopher@21:1/5 to Carlos E.R. on Tue Mar 11 15:29:02 2025
    On 11/03/2025 14:59, Carlos E.R. wrote:
    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:
    On 10/03/2025 22:28, John Ames wrote:
    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.

    Exactly.

    Journalctl should be able to take the One True Logfile and scan it,
    rewriting items to be retained and discarding items to be deleted .

    Nope.

    That's manipulating information and has legal implications. Yes,
    that's the intentional reason why systemd refuses to do it.

    So is truncating it to the last day, or the last 25Mbyte. Which 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.

    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 is hard to imagine a more stupid decision or more dangerous way of
    making decisions than by putting those decisions in the hands of people
    who pay no price for being wrong.”

    Thomas Sowell

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Pancho@21:1/5 to John Ames on Tue Mar 11 16:12:43 2025
    On 3/11/25 15:59, 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.


    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.

    Throwing a hand grenade in the server would "delete" records, but it
    would leave traces of evidence that something suspicious had occurred.
    Evidence that the server should no longer be relied upon.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Pancho@21:1/5 to The Natural Philosopher on Tue Mar 11 15:50:25 2025
    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 Philosopher
    <tnp@invalid.invalid> wrote:

    On 10/03/2025 22:28, John Ames wrote:
    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.

    Exactly.

    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.

    Dont you think any intruder would not already have written a 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


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Pancho@21:1/5 to John Ames on Tue Mar 11 16:25:40 2025
    On 3/11/25 16:19, John Ames wrote:
    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.


    I don't think anyone is saying it couldn't be done. However, deleting
    stuff clearly does compromise accountability. Developing a system that
    enables it, while also allowing good practice, is probably more complex.

    I won't say any more, because security, reliability is way outside my knowledge. I'm just a dodgy programmer that you want to defend a system
    from, I'm not an arch villain/hacker.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John McCue@21:1/5 to Carlos E.R. on Tue Mar 11 17:37:33 2025
    Carlos E.R. <robin_listas@es.invalid> wrote:
    On 2025-03-11 08:58, The Natural Philosopher wrote:
    On 10/03/2025 22:28, John Ames wrote:
    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.

    Exactly.

    Journalctl should be able to take the One True Logfile and scan it,
    rewriting items to be retained and discarding items to be deleted .

    Nope.

    That's manipulating information and has legal implications. Yes,
    that's the intentional reason why systemd refuses to do it.

    I thought of this after I posted about the journal being a
    database of sorts. And yes, if this really worked it would
    make a lot of sense.

    But a person wanting to hide something would just delete all
    the log files and have done with it, not take the time to
    look for a specific entry.

    In anycase, to me the best way to save log data is to mirror
    it on a server only trusted people have access to, syslog
    can do this. 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.

    --
    [t]csh(1) - "An elegant shell, for a more... civilized age."
    - Paraphrasing Star Wars

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From The Natural Philosopher@21:1/5 to Pancho on Tue Mar 11 19:58:30 2025
    On 11/03/2025 15:50, Pancho wrote:
    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 Philosopher
    <tnp@invalid.invalid> wrote:

    On 10/03/2025 22:28, John Ames wrote:
    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.

    Exactly.

    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.

    Dont you think any intruder would not already have written a
    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.

    Since journactl can delete huge chunks it cannot be that secure
    Journactl selectivelely erases entries by time stamp, and by size. Why
    nt by 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.

    Clearly they haven't since anyone with root access can delete the logs entirely

    I mean really. Secure?


    Regards, Dave Hodgins



    --
    "First, find out who are the people you can not criticise. They are your oppressors."
    - George Orwell

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From The Natural Philosopher@21:1/5 to John Ames on Tue Mar 11 20:02:22 2025
    On 11/03/2025 16:19, John Ames wrote:
    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.

    Journalctl re signs the logs after erasure, Why note after partial erasure?
    And a genuine user doesn't mind if the log of all logs says 'someone
    just deleted 34,783 entries associated with the DNS server'.

    Quis custodiet ipsos custodes....

    --
    “Those who can make you believe absurdities, can make you commit atrocities.”

    ― Voltaire, Questions sur les Miracles à M. Claparede, Professeur de Théologie à Genève, par un Proposant: Ou Extrait de Diverses Lettres de
    M. de Voltaire

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Carlos E.R. on Tue Mar 11 21:05:45 2025
    On Tue, 11 Mar 2025 13:23:39 +0100, Carlos E.R. wrote:

    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.

    When all else fails, read the documentation!

    From the journald.conf man page <https://www.freedesktop.org/software/systemd/man/latest/journald.conf.html>, note the options for forwarding journal entries to alternative
    destinations:

    ForwardToSyslog=, ForwardToKMsg=, ForwardToConsole=, ForwardToWall=, ForwardToSocket=

    ...

    When forwarding over a socket the Journal Export Format is used
    when sending over the wire. Notably this includes the metadata
    field __REALTIME_TIMESTAMP so that systemd-journal-remote (see
    systemd-journal-remote.service(8)) can be used to receive the
    forwarded journal entries.

    The Journal Export Format is documented here: <https://systemd.io/JOURNAL_EXPORT_FORMATS/>.

    So the solution is simple: write your own socket listener which saves
    journal records to your own rewritable format, e.g. an SQLite
    database. You can then edit this to your heart’s content.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to The Natural Philosopher on Tue Mar 11 20:56:35 2025
    On Tue, 11 Mar 2025 07:49:31 +0000, The Natural Philosopher wrote:

    Completely possible if you are a competent programmer.

    Show us how.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From D@21:1/5 to John Ames on Tue Mar 11 22:36:35 2025
    On Tue, 11 Mar 2025, John Ames wrote:

    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.

    Never underestimate that pleasure! It is very long lasting! =D

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From D@21:1/5 to Pancho on Tue Mar 11 22:37:42 2025
    On Tue, 11 Mar 2025, Pancho wrote:

    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 Philosopher
    <tnp@invalid.invalid> wrote:

    On 10/03/2025 22:28, John Ames wrote:
    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.

    Exactly.

    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.

    Dont you think any intruder would not already have written a 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.

    It is very simple. You write it to WORM storage, or burn it to a disc.
    That's it. It's not really rocket science.

    In military intelligence circles, they work with data diods as well to
    limit traffic.





    Regards, Dave Hodgins




    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From D@21:1/5 to John Ames on Tue Mar 11 22:38:19 2025
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to The Natural Philosopher on Tue Mar 11 23:07:52 2025
    On Tue, 11 Mar 2025 14:52:41 +0000, The Natural Philosopher wrote:

    Dont you think any intruder would not already have written a journalctl
    to do exactly that?

    But aren’t you complaining about the fact that such a tool doesn’t already exist?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Carlos E.R. on Tue Mar 11 23:04:25 2025
    On Tue, 11 Mar 2025 13:21:25 +0100, Carlos E.R. wrote:

    ... they decided to not implement deletion or filtering of the contents inside the files.

    The file format (including some design goals) is documented here <https://systemd.io/JOURNAL_FILE_FORMAT/>. Note the feature point
    “Primarily append-based, hence robust to corruption”.

    Yes there are file formats that allow record deletion, while being
    resistant to corruption. They’re called “databases”. And they’re a
    bit more complex.

    systemd gets a whole lot of flak for being some supposed “huge
    monolith” as it is
    <http://0pointer.de/blog/projects/the-biggest-myths.html>. Imagine if
    they had included a full database format on top of that.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to John McCue on Tue Mar 11 23:42:29 2025
    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).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to The Natural Philosopher on Tue Mar 11 23:44:41 2025
    On Tue, 11 Mar 2025 14:50:27 +0000, The Natural Philosopher 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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to John Ames on Tue Mar 11 23:47:16 2025
    On Tue, 11 Mar 2025 08:41:26 -0700, John Ames wrote:

    It's a little tempting to do it anyway, just out of spite.

    <https://www.freedesktop.org/software/systemd/man/latest/systemd-journal-remote.html#Examples>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to The Natural Philosopher on Tue Mar 11 23:46:42 2025
    On Tue, 11 Mar 2025 15:29:02 +0000, The Natural Philosopher wrote:

    But I am too old and tired to piss around wiping Poettering's bottom
    for him.

    But not too old to use up your remaining breaths complaining fruitlessly
    about it.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carlos E.R.@21:1/5 to John Ames on Wed Mar 12 22:12:28 2025
    On 2025-03-11 16:59, 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 can delete by date, but only from the distant end of the log, not on
    the middle.

    --
    Cheers, Carlos.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carlos E.R.@21:1/5 to Lawrence D'Oliveiro on Wed Mar 12 22:10:35 2025
    On 2025-03-12 00:42, Lawrence D'Oliveiro wrote:
    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 another computer. The original remains intact. Maybe you can play
    with that and somehow replace the original files. Not something I'm
    going to experiment with, I leave that to the OP.

    --
    Cheers, Carlos.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Carlos E.R. on Wed Mar 12 21:38:50 2025
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carlos E.R.@21:1/5 to Lawrence D'Oliveiro on Wed Mar 12 22:26:43 2025
    On 2025-03-12 00:07, Lawrence D'Oliveiro wrote:

    Note that the systemd journal is not just one logfile, it can be split out into multiple separate files.

    Kind of like syslog, really.

    What I see there is one file for user, one file for system, with a
    certain date. I see more files, but it is the same pattern for other
    days or hours: one file system, another for user. There does not seem to
    be separation of files per units or some other concept.

    When displaying the journals, you can select what to print. There are no
    tools to alter what is written as it happens, AFAIK. There are tools to
    remove the oldest entries.

    On the other hand, on syslog, there is originally a single stream of
    records, which are written to different files according to the criteria
    of the admin, who can do anything with them before writing them.

    --
    Cheers, Carlos.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carlos E.R.@21:1/5 to All on Wed Mar 12 22:14:57 2025
    On 2025-03-11 22:38, D wrote:


    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.

    But nobody has pointed to software that does it.

    --
    Cheers, Carlos.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to John Ames on Wed Mar 12 21:38:13 2025
    On Wed, 12 Mar 2025 09:07:01 -0700, John Ames wrote:

    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.

    That’s not the argument, though. The file format is designed to be
    resistant to corruption, which is why it’s append-only.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carlos E.R.@21:1/5 to Lawrence D'Oliveiro on Wed Mar 12 23:42:15 2025
    On 2025-03-12 22:38, Lawrence D'Oliveiro wrote:
    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.

    But the resulting file is not the one that "journalctl" reads, right?
    You have to somehow specify a different file.

    --
    Cheers, Carlos.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carlos E.R.@21:1/5 to John Ames on Wed Mar 12 23:44:57 2025
    On 2025-03-12 22:50, John Ames wrote:
    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.

    Then surely somebody will have done it, because many people want to
    remove entries from the journal. The application to do it will have been published somewhere.

    Me, I would like to remove the news.debug entries older than a month,
    for instance.

    --
    Cheers, Carlos.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Carlos E.R. on Thu Mar 13 00:12:35 2025
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carlos E.R.@21:1/5 to Lawrence D'Oliveiro on Thu Mar 13 08:21:11 2025
    On 2025-03-13 01:12, Lawrence D'Oliveiro wrote:
    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.

    Certainly, but that's a problem. You can no longer run

    journalctl --boot=-1

    and get the expected modified results as the OP wants.

    --
    Cheers, Carlos.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Kettlewell@21:1/5 to The Natural Philosopher on Thu Mar 13 07:47:23 2025
    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.

    --
    https://www.greenend.org.uk/rjk/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Carlos E.R. on Thu Mar 13 08:06:56 2025
    On Thu, 13 Mar 2025 08:21:11 +0100, Carlos E.R. wrote:

    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.

    This is why I said, see the docs <https://www.freedesktop.org/software/systemd/man/latest/journalctl.html>:

    -D DIR, --directory=DIR

    Takes a directory path as argument. If specified, journalctl will
    operate on the specified journal directory DIR instead of the
    default runtime and system journal paths.

    Added in version 187.

    -i GLOB, --file=GLOB

    Takes a file glob as an argument. If specified, journalctl will
    operate on the specified journal files matching GLOB instead of
    the default runtime and system journal paths. May be specified
    multiple times, in which case files will be suitably interleaved.

    Added in version 205.

    --root=ROOT

    Takes a directory path as an argument. If specified, journalctl
    will operate on journal directories and catalog file hierarchy
    underneath the specified directory instead of the root directory
    (e.g. --update-catalog will create
    ROOT/var/lib/systemd/catalog/database, and journal files under
    ROOT/run/journal/ or ROOT/var/log/journal/ will be displayed).

    Added in version 201.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carlos E.R.@21:1/5 to Richard Kettlewell on Thu Mar 13 09:37:10 2025
    On 2025-03-13 08:47, Richard Kettlewell wrote:
    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 had both journal and rsyslog working, but I don't know exactly how I
    did it years ago. I have experimented with what those two links propose.

    I have, on /etc/systemd/journald.conf:

    #ForwardToSyslog=no
    #MaxLevelSyslog=debug

    On /etc/rsyslog.conf I had:

    # provides support for local system logging (e.g. via logger command)
    $ModLoad imuxsock.so

    I commented that line and added:

    $ModLoad imjournal


    When I restart the syslog daemon, I get a flush of new entries that it
    reads from the journal. This is not good. And, when I issue:

    logger -p local3.info hello

    The message gets to the journal but not to the syslog. So I change to

    $ModLoad imuxsock.so
    $ModLoad imjournal

    and now the messages go to both places, but the restart of the daemon
    adds the flurry of entries to the log files again. This is not clean;
    when I do changes to the syslog filtering, I have to restart the daemon
    and everything will be written again.

    The weird thing is that with the previous configuration I was getting
    the messages, except some boot messages.


    Oh, I forgot to add

    $ModLoad mmjsonparse

    No difference, though. So I'm going to try the socket method instead.


    /etc/systemd/journald.conf:

    ForwardToSyslog=yes
    MaxLevelSyslog=debug

    /etc/rsyslog.conf:

    $ModLoad imuxsock.so
    #$ModLoad imjournal
    #$ModLoad mmjsonparse


    I restart both services, I send a message with logger... everything
    seems correct.


    --
    Cheers, Carlos.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Carlos E.R. on Thu Mar 13 22:07:06 2025
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carlos E.R.@21:1/5 to Lawrence D'Oliveiro on Fri Mar 14 12:57:19 2025
    On 2025-03-13 23:07, Lawrence D'Oliveiro wrote:
    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.

    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. To do so I run:

    journalctl --boot=-2 -- \ facility=kern,user,mail,daemon,auth,syslog,lpr,news,uucp,cron,authpriv,ftp,12,13,14,15,local0,local1,local2,local3,local4,local5,local6,local7


    The problem is, that some information is missing from the output,
    because there are messages submitted to the journal without a facility assigned.

    journalctl(1) does have one exclude type of option:

    "-T, --exclude-identifier=SYSLOG_IDENTIFIER
    Exclude messages for the specified syslog identifier"

    but

    journalctl: unrecognized option '--exclude-identifier=news'

    systemd 254 doesn't have it. 257 does. So, not me.


    --
    Cheers, Carlos.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?St=C3=A9phane?= CARPENTIE@21:1/5 to All on Fri Mar 14 20:22:22 2025
    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.

    --
    Si vous avez du temps à perdre :
    https://scarpet42.gitlab.io

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Carlos E.R. on Fri Mar 14 21:30:12 2025
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From vallor@21:1/5 to ldo@nz.invalid on Sat Mar 15 03:19:26 2025
    On Fri, 14 Mar 2025 21:30:12 -0000 (UTC), Lawrence D'Oliveiro
    <ldo@nz.invalid> wrote in <vr2753$23hho$4@dont-email.me>:

    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?

    rsyslog has rule-based filtering -- and since the resulting logs
    are text files, grep -v is your friend.

    Linux Mint, by default, comes with systemd-journald sending logs
    to the syslog socket, and it runs rsyslog. So, it has a more "standard"
    syslog environment for those who prefer that.

    --
    -v System76 Thelio Mega v1.1 x86_64 NVIDIA RTX 3090 Ti
    OS: Linux 6.14.0-rc6 Release: Mint 22.1 Mem: 258G
    "No sense being pessimistic. It wouldn't work anyway."

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From c186282@21:1/5 to All on Sat Mar 15 22:39:30 2025
    On 3/14/25 4:22 PM, Stéphane CARPENTIER wrote:
    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.


    OR you're Hunter Biden who doesn't have the remaining
    brain cells to think ahead .... :-)

    If you are NOT a bank, if you are NOT doing accounting
    for a bunch of clients, then it's best to arrange for
    the least amount of logging and thumbnails and such
    that's possible for you. Every install I always mark
    the local thumbnail subdir as read-only, even to root.
    Browsers should be set to delete all or most history.
    My bank sites, I always have to re-enable JS every
    time I log in.

    Systemd ... scatters stuff into a number of places.
    Frankly, you'll have to write something like a
    Python script and run as root every so often.

    Rude and crude - get log file size, open log RW,
    copy HALF that many bytes, write that to the log
    and close. Some logs put the latest stuff at the
    bottom so you kinda have to reverse that logic
    by SEEKing halfway thru and then duplicating
    from there until EOF. One mangled entry, who
    cares eh ?

    There are some distros - 'Tails', 'ParrotOS', 'Alpine' -
    that are kinda set up by default to cover yer ass.
    Also some non-systemd versions like Devuian. They
    are all pretty straight-up to use. If you're really
    paranoid, install/run in a VM for on-need use.

    ON THE WHOLE I'm not terribly against systemd - it
    makes some previously super-annoying tricks a lot
    easier to realize. It's not intended to be Winders
    by another name. In my uses, I run a number of
    hand-writ daemons at, or near, startup and systemd
    will both do that easily and smartly AND keep and eye
    on them and re-start if they fail.

    I use 'MX' quite a lot and the current ones install
    with systemd disabled ... all SysV Init. You have to
    choose a line from the Grub menu to get the systemd
    variant running. Some of my boxes default to one,
    others to the other, depending on mission.

    Check BeeLink and BMax for very affordable Linux-
    capable mini-boxes. The N100 based are quite
    snappy with any Linux distro and have enough
    of everything. Think they have N150s now for the
    same price as the N95/N100s. Not every use needs
    an i9 with 64gb RAM. If you can find/hit the 'to
    BIOS' key on boot you need NEVER have Winders
    run on them for a single nanosecond. Still have
    one in-reserve, unused, maybe FreeBSD ?

    (current new China trade sanctions MAY increase
    the price of these boxes for awhile)

    Anyway, you're not trapped. Party on dude.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carlos E.R.@21:1/5 to Lawrence D'Oliveiro on Sun Mar 16 14:48:04 2025
    On 2025-03-14 22:30, Lawrence D'Oliveiro wrote:
    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?

    I just copy the /var/log/messages file. It already has that information filtered out. I only have to find the start and end of the session.

    --
    Cheers, Carlos.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Carlos E.R. on Mon Mar 17 00:40:53 2025
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carlos E.R.@21:1/5 to Lawrence D'Oliveiro on Tue Mar 18 20:03:34 2025
    On 2025-03-17 01:40, Lawrence D'Oliveiro wrote:
    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.

    There is no mail in the /var/log/messages file at all, since ever. Mail
    goes to /var/log/mail. This is the default configuration of the
    rsyslog.conf file, since ever, for years and years. Similarly for news.

    --
    Cheers, Carlos.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Carlos E.R. on Tue Mar 18 22:06:41 2025
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Carlos E.R. on Tue Mar 18 21:20:05 2025
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carlos E.R.@21:1/5 to Lawrence D'Oliveiro on Tue Mar 18 22:51:36 2025
    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.

    --
    Cheers, Carlos.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carlos E.R.@21:1/5 to Lawrence D'Oliveiro on Wed Mar 19 01:29:09 2025
    On 2025-03-18 23:06, Lawrence D'Oliveiro wrote:
    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.

    Yes, someone kindly created a script doing just that for me, but
    unfortunately it doesn't process well multiline log entries. And some
    lines with multiple spaces are shortened to a single space.


    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.

    I'm stuck with whatever version my distribution carries, which is 254.
    You see, not that old.

    This version can do filtering using facilities, but the problem is that
    there are a bunch of entries in the journal with no facility assigned.
    So when filtering by facilities, with the exact line I posted before by
    error, there are megabytes of missing information from the output.

    This is the line I am using:

    journalctl --boot=cdf...\
    --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


    --
    Cheers, Carlos.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From The Natural Philosopher@21:1/5 to Carlos E.R. on Wed Mar 19 06:31:10 2025
    On 18/03/2025 21:51, 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.

    LOL :-)

    --
    Truth welcomes investigation because truth knows investigation will lead
    to converts. It is deception that uses all the other techniques.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)