Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #81041 > unrolled thread

ever had 1GB+ kern.log (and syslog) from changing monitors?

Back to article view | Back to comp.os.linux.misc

Contents

  ever had 1GB+ kern.log (and syslog) from changing monitors? Robert Riches <spamtrap42@jacob21819.net> - 2026-01-13 04:57 +0000
    Re: ever had 1GB+ kern.log (and syslog) from changing monitors? c186282 <c186282@nnada.net> - 2026-01-13 00:32 -0500
      Re: ever had 1GB+ kern.log (and syslog) from changing monitors? 🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl> - 2026-01-13 08:09 +0100
        Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-13 08:16 +0000
          Re: ever had 1GB+ kern.log (and syslog) from changing monitors? "Carlos E.R." <robin_listas@es.invalid> - 2026-01-13 11:22 +0100
            Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-13 19:51 +0000
              Re: ever had 1GB+ kern.log (and syslog) from changing monitors? "Carlos E.R." <robin_listas@es.invalid> - 2026-01-14 14:42 +0100
                Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-14 20:54 +0000
                  Re: ever had 1GB+ kern.log (and syslog) from changing monitors? "Carlos E.R." <robin_listas@es.invalid> - 2026-01-14 23:14 +0100
                    Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-14 22:36 +0000
                      Re: ever had 1GB+ kern.log (and syslog) from changing monitors? "Carlos E.R." <robin_listas@es.invalid> - 2026-01-15 14:40 +0100
                        Re: ever had 1GB+ kern.log (and syslog) from changing monitors? The Natural Philosopher <tnp@invalid.invalid> - 2026-01-15 13:54 +0000
                        Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-16 04:20 +0000
                          Re: ever had 1GB+ kern.log (and syslog) from changing monitors? "Carlos E.R." <robin_listas@es.invalid> - 2026-01-16 21:40 +0100
                            Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-16 21:03 +0000
                              Re: ever had 1GB+ kern.log (and syslog) from changing monitors? "Carlos E.R." <robin_listas@es.invalid> - 2026-01-16 22:23 +0100
                                Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-16 21:41 +0000
                                  Re: ever had 1GB+ kern.log (and syslog) from changing monitors? "Carlos E.R." <robin_listas@es.invalid> - 2026-01-16 22:53 +0100
                                    Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-17 20:34 +0000
                                      Re: ever had 1GB+ kern.log (and syslog) from changing monitors? "Carlos E.R." <robin_listas@es.invalid> - 2026-01-17 22:57 +0100
                                        Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Marc Haber <mh+usenetspam1118@zugschl.us> - 2026-01-18 11:14 +0100
                                          Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Nuno Silva <nunojsilva@invalid.invalid> - 2026-01-18 10:44 +0000
                                          Re: ever had 1GB+ kern.log (and syslog) from changing monitors? "Carlos E.R." <robin_listas@es.invalid> - 2026-01-18 12:50 +0100
                                            Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-18 21:04 +0000
                                              Re: ever had 1GB+ kern.log (and syslog) from changing monitors? "Carlos E.R." <robin_listas@es.invalid> - 2026-01-18 23:04 +0100
                                                Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-19 00:46 +0000
                                                  Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Nuno Silva <nunojsilva@invalid.invalid> - 2026-01-19 09:42 +0000
                                                Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Marc Haber <mh+usenetspam1118@zugschl.us> - 2026-01-19 09:56 +0100
                                                  Re: ever had 1GB+ kern.log (and syslog) from changing monitors? "Carlos E.R." <robin_listas@es.invalid> - 2026-01-19 14:29 +0100
                                                    Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Marc Haber <mh+usenetspam1118@zugschl.us> - 2026-01-19 15:53 +0100
                                                      Re: ever had 1GB+ kern.log (and syslog) from changing monitors? "Carlos E.R." <robin_listas@es.invalid> - 2026-01-19 22:46 +0100
                                                        Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Richard Kettlewell <invalid@invalid.invalid> - 2026-01-19 23:05 +0000
                                                          Re: ever had 1GB+ kern.log (and syslog) from changing monitors? "Carlos E.R." <robin_listas@es.invalid> - 2026-01-20 02:36 +0100
                                                            Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-20 03:02 +0000
                                                            Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Richard Kettlewell <invalid@invalid.invalid> - 2026-01-20 08:37 +0000
                                                              Re: ever had 1GB+ kern.log (and syslog) from changing monitors? "Carlos E.R." <robin_listas@es.invalid> - 2026-01-20 14:04 +0100
                                                                Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Richard Kettlewell <invalid@invalid.invalid> - 2026-01-20 17:37 +0000
                                                                  Re: ever had 1GB+ kern.log (and syslog) from changing monitors? "Carlos E.R." <robin_listas@es.invalid> - 2026-01-20 21:01 +0100
                                                                    Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-20 20:24 +0000
                                                                    Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Richard Kettlewell <invalid@invalid.invalid> - 2026-01-20 22:25 +0000
                                                                Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-20 20:36 +0000
                                                                  Re: ever had 1GB+ kern.log (and syslog) from changing monitors? "Carlos E.R." <robin_listas@es.invalid> - 2026-01-20 23:22 +0100
                                                        Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-19 23:24 +0000
                                                          Re: ever had 1GB+ kern.log (and syslog) from changing monitors? "Carlos E.R." <robin_listas@es.invalid> - 2026-01-20 02:39 +0100
                                                            Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-23 05:48 +0000
                                                              Re: ever had 1GB+ kern.log (and syslog) from changing monitors? "Carlos E.R." <robin_listas@es.invalid> - 2026-01-23 14:07 +0100
                                                                Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-23 21:19 +0000
                                                                  Re: ever had 1GB+ kern.log (and syslog) from changing monitors? "Carlos E.R." <robin_listas@es.invalid> - 2026-01-23 22:26 +0100
                                                                    Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Bobbie Sellers <bliss-sf4ever@dslextreme.com> - 2026-01-23 21:45 -0800
                                                                      Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Harold Stevens <wookie@aspen.localdomain> - 2026-01-24 04:18 -0600
                                        Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-18 21:02 +0000
                                          Re: ever had 1GB+ kern.log (and syslog) from changing monitors? "Carlos E.R." <robin_listas@es.invalid> - 2026-01-18 23:04 +0100
                                  Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Nuno Silva <nunojsilva@invalid.invalid> - 2026-01-16 23:33 +0000
                                    Re: ever had 1GB+ kern.log (and syslog) from changing monitors? "Carlos E.R." <robin_listas@es.invalid> - 2026-01-17 14:33 +0100
                                      Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-17 20:35 +0000
                                        Re: ever had 1GB+ kern.log (and syslog) from changing monitors? "Carlos E.R." <robin_listas@es.invalid> - 2026-01-17 22:56 +0100
                                          Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-18 01:51 +0000
                                            Re: ever had 1GB+ kern.log (and syslog) from changing monitors? "Carlos E.R." <robin_listas@es.invalid> - 2026-01-18 12:55 +0100
                                              Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-18 21:02 +0000
                                                Re: ever had 1GB+ kern.log (and syslog) from changing monitors? "Carlos E.R." <robin_listas@es.invalid> - 2026-01-18 23:05 +0100
                                                  Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-19 00:46 +0000
                              Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Nuno Silva <nunojsilva@invalid.invalid> - 2026-01-16 23:30 +0000
                                Re: ever had 1GB+ kern.log (and syslog) from changing monitors? "Carlos E.R." <robin_listas@es.invalid> - 2026-01-17 14:36 +0100
                                  Re: ever had 1GB+ kern.log (and syslog) from changing monitors? The Natural Philosopher <tnp@invalid.invalid> - 2026-01-17 18:25 +0000
                                  Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-17 20:33 +0000
                                  Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Richard Kettlewell <invalid@invalid.invalid> - 2026-01-18 10:48 +0000
                                Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Harold Stevens <wookie@aspen.localdomain> - 2026-01-17 10:23 -0600
                Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Richard Kettlewell <invalid@invalid.invalid> - 2026-01-18 10:43 +0000
                  Re: ever had 1GB+ kern.log (and syslog) from changing monitors? "Carlos E.R." <robin_listas@es.invalid> - 2026-01-18 12:59 +0100
                    Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-18 21:06 +0000
                      Re: ever had 1GB+ kern.log (and syslog) from changing monitors? "Carlos E.R." <robin_listas@es.invalid> - 2026-01-18 23:06 +0100
                        Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-19 00:48 +0000
                          Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Nuno Silva <nunojsilva@invalid.invalid> - 2026-01-19 09:44 +0000
          Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Nuno Silva <nunojsilva@invalid.invalid> - 2026-01-13 11:40 +0000
      Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Robert Riches <spamtrap42@jacob21819.net> - 2026-01-14 03:27 +0000
    Re: ever had 1GB+ kern.log (and syslog) from changing monitors? "Carlos E.R." <robin_listas@es.invalid> - 2026-01-13 11:24 +0100
      Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Nuno Silva <nunojsilva@invalid.invalid> - 2026-01-13 11:43 +0000
      Re: ever had 1GB+ kern.log (and syslog) from changing monitors? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-13 19:52 +0000

Page 1 of 4  [1] 2 3 4  Next page →

#81041 — ever had 1GB+ kern.log (and syslog) from changing monitors?

Each of my /var/log/syslog and /var/log/kern.log is over 1GB
today after unplugging two monitors and plugging in two different
monitors.

The hardware is about 5 years old:
  - Motherboard: Asus Pro WS X570-ACE
  - Processor: AMD Ryzen 7 5800X 8-Core Processor
  - GPU: MSI Radeon RX5500XT
  - old monitors: 2x Asus VW266H
  - new monitors: 2x Asus PA279CV

Software is Devuan Daedalus.

The old monitors were connected to the first two DisplayPort
connectors via (probably no-name) DisplayPort-to-HDMI adapters
and a Kopul HDMI switchers.

The new monitors are connected to the same first two DisplayPort
connectors via PearStone DisplayPort-to-HDMI adapters and the
same Kopul HDMI switchers.

(The switchers let me push a button and see security camera
output on one monitor, then push another button to go back to
computer stuff.)

I had tested the new monitors and adapter cables via the GPU's
third DisplayPort connector, with and without going through the
switcher.  All tested out well.

Today, while the machine would have been showing the text console
and not X, I physically installed the new monitors on the
above-desk mounts and plugging everything in.  The switchers
showed that there was signal on the input line, but the monitors
stayed in standby mode.  About the time I plugging things in,
syslog and kern.log show the following:

2026-01-12T12:00:37.370890-08:00 one kernel: [180281.980042] [drm:retrieve_link_
cap [amdgpu]] *ERROR* retrieve_link_cap: Read receiver caps dpcd data failed.
2026-01-12T12:00:38.627964-08:00 one kernel: [180283.233347] ------------[ cut h
ere ]------------
2026-01-12T12:00:38.627976-08:00 one kernel: [180283.234095] WARNING: CPU: 7 PID
: 13497 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3076 dc_update_pla
nes_and_stream+0x342/0x880 [amdgpu]

then lists of kernel modules, register dumps, stack traces
and etc.

then a ton of these:

2026-01-12T12:00:38.754724-08:00 one kernel: [180283.364640] [drm:dc_add_plane_to_context [amdgpu]] *ERROR* Head pipe not found for stream_state 000000000268a75b !
2026-01-12T12:00:38.758717-08:00 one kernel: [180283.365909] [drm:dc_add_plane_to_context [amdgpu]] *ERROR* Head pipe not found for stream_state 000000000268a75b !
2026-01-12T12:00:38.758720-08:00 one kernel: [180283.367165] [drm:dc_add_plane_to_context [amdgpu]] *ERROR* Head pipe not found for stream_state 000000000268a75b !

at a rate of about 980 per second for a total of about 6,803,402
lines and just over 1GB of text in each file.  Thankfully, a
clean reboot of the machine accomplished via a thin-client
machine, the GPU, switchers, and monitors signed a peace treaty
and are now happily working together.

Has anyone else seen anything similar to that?

Thanks.

-- 
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)

[toc] | [next] | [standalone]

#81044

On 1/12/26 23:57, Robert Riches wrote:
> Each of my /var/log/syslog and /var/log/kern.log is over 1GB
> today after unplugging two monitors and plugging in two different
> monitors.
> 
> The hardware is about 5 years old:
>    - Motherboard: Asus Pro WS X570-ACE
>    - Processor: AMD Ryzen 7 5800X 8-Core Processor
>    - GPU: MSI Radeon RX5500XT
>    - old monitors: 2x Asus VW266H
>    - new monitors: 2x Asus PA279CV
> 
> Software is Devuan Daedalus.
> 
> The old monitors were connected to the first two DisplayPort
> connectors via (probably no-name) DisplayPort-to-HDMI adapters
> and a Kopul HDMI switchers.
> 
> The new monitors are connected to the same first two DisplayPort
> connectors via PearStone DisplayPort-to-HDMI adapters and the
> same Kopul HDMI switchers.
> 
> (The switchers let me push a button and see security camera
> output on one monitor, then push another button to go back to
> computer stuff.)
> 
> I had tested the new monitors and adapter cables via the GPU's
> third DisplayPort connector, with and without going through the
> switcher.  All tested out well.
> 
> Today, while the machine would have been showing the text console
> and not X, I physically installed the new monitors on the
> above-desk mounts and plugging everything in.  The switchers
> showed that there was signal on the input line, but the monitors
> stayed in standby mode.  About the time I plugging things in,
> syslog and kern.log show the following:
> 
> 2026-01-12T12:00:37.370890-08:00 one kernel: [180281.980042] [drm:retrieve_link_
> cap [amdgpu]] *ERROR* retrieve_link_cap: Read receiver caps dpcd data failed.
> 2026-01-12T12:00:38.627964-08:00 one kernel: [180283.233347] ------------[ cut h
> ere ]------------
> 2026-01-12T12:00:38.627976-08:00 one kernel: [180283.234095] WARNING: CPU: 7 PID
> : 13497 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3076 dc_update_pla
> nes_and_stream+0x342/0x880 [amdgpu]
> 
> then lists of kernel modules, register dumps, stack traces
> and etc.
> 
> then a ton of these:
> 
> 2026-01-12T12:00:38.754724-08:00 one kernel: [180283.364640] [drm:dc_add_plane_to_context [amdgpu]] *ERROR* Head pipe not found for stream_state 000000000268a75b !
> 2026-01-12T12:00:38.758717-08:00 one kernel: [180283.365909] [drm:dc_add_plane_to_context [amdgpu]] *ERROR* Head pipe not found for stream_state 000000000268a75b !
> 2026-01-12T12:00:38.758720-08:00 one kernel: [180283.367165] [drm:dc_add_plane_to_context [amdgpu]] *ERROR* Head pipe not found for stream_state 000000000268a75b !
> 
> at a rate of about 980 per second for a total of about 6,803,402
> lines and just over 1GB of text in each file.  Thankfully, a
> clean reboot of the machine accomplished via a thin-client
> machine, the GPU, switchers, and monitors signed a peace treaty
> and are now happily working together.
> 
> Has anyone else seen anything similar to that?
> 
> Thanks.


   Ummm ... minor errors CAN produce HUGE log files.

   You can either do a LOT of research OR just write
   a root crontab script that nukes "older" logs.

[toc] | [prev] | [next] | [standalone]

#81053

W dniu 13.01.2026 o 06:32, c186282 pisze:
>    You can either do a LOT of research OR just write
>    a root crontab script that nukes "older" logs.

There are better options:
1. Separate /var partition, and
2. Setup logrotate: <https://linux.die.net/man/8/logrotate>

Then logs will newer exceed /var partition size limit, and in the case 
of flood logs rest of OS will be not affected.

Logrotate should automatically delete older logs. Even in the case of 
flood logs.

-- 
Jacek Marcin Jaworski,    Pruszcz Gd., woj. Pomorskie, Polska🇵🇱, EU🇪🇺;
tel.: +48-609-170-742,   najlepiej w godz.: 5:15-5:55 lub 17:15-17:55;
<jmj@energokod.gda.pl>, gpg: 4A541AA7A6E872318B85D7F6A651CC39244B0BFA;
Domowa s. WWW:                             <https://energokod.gda.pl>;
Mini Netykieta:         <https://energokod.gda.pl/MiniNetykieta.html>;
Mailowa Samoobrona:             <https://emailselfdefense.fsf.org/pl>.

[toc] | [prev] | [next] | [standalone]

#81057

On Tue, 13 Jan 2026 08:09:56 +0100, 🇵🇱Jacek Marcin Jaworski🇵🇱 wrote:

> Logrotate should automatically delete older logs. Even in the case of 
> flood logs.

systemd deals with this sort of thing a lot better.

[toc] | [prev] | [next] | [standalone]

#81063

On 2026-01-13 09:16, Lawrence D’Oliveiro wrote:
> On Tue, 13 Jan 2026 08:09:56 +0100, 🇵🇱Jacek Marcin Jaworski🇵🇱 wrote:
> 
>> Logrotate should automatically delete older logs. Even in the case of
>> flood logs.
> 
> systemd deals with this sort of thing a lot better.

Not really.

For example, in my machine I use leafnode as an nntp proxy server to 
Usenet. It is very verbose, and floods the logs. With syslog, I put them 
in a different file and rotate them faster, keeping only warning or 
emergency level for longer.

With systemd I can do nothing. The entire verborrea of nntp is kept, and 
the total is either rotated faster, or grow huge faster.

-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#81093

On Tue, 13 Jan 2026 11:22:55 +0100, Carlos E.R. wrote:

> For example, in my machine I use leafnode as an nntp proxy server to
> Usenet. It is very verbose, and floods the logs. With syslog, I put
> them in a different file and rotate them faster, keeping only
> warning or emergency level for longer.
>
> With systemd I can do nothing. The entire verborrea of nntp is kept,
> and the total is either rotated faster, or grow huge faster.

<https://www.freedesktop.org/software/systemd/man/latest/journald.conf.html>

See the options for overall rate-limiting and log size limits,
rotation control, retention time, filtering by log level ... and of
course forwarding to syslog and other legacy places.

[toc] | [prev] | [next] | [standalone]

#81115

On 2026-01-13 20:51, Lawrence D’Oliveiro wrote:
> On Tue, 13 Jan 2026 11:22:55 +0100, Carlos E.R. wrote:
> 
>> For example, in my machine I use leafnode as an nntp proxy server to
>> Usenet. It is very verbose, and floods the logs. With syslog, I put
>> them in a different file and rotate them faster, keeping only
>> warning or emergency level for longer.
>>
>> With systemd I can do nothing. The entire verborrea of nntp is kept,
>> and the total is either rotated faster, or grow huge faster.
> 
> <https://www.freedesktop.org/software/systemd/man/latest/journald.conf.html>
> 
> See the options for overall rate-limiting and log size limits,
> rotation control, retention time, filtering by log level ... and of
> course forwarding to syslog and other legacy places.

Not useful at all.

You don't understand. You are telling me of the options to control the 
total of things.

I want to purge from the journal all messages from facility=news, 
level>Warning, age> 7 days. Only those messages. Leave all the rest intact.

Doing this goes against the philosophy of the journal, so it is 
intentionally imposible.

-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#81123

On Wed, 14 Jan 2026 14:42:44 +0100, Carlos E.R. wrote:

> I want to purge from the journal all messages from facility=news,
> level>Warning, age> 7 days. Only those messages. Leave all the rest
> intact.

You can’t purge selected lines from a logfile with syslog, either. You
would have to copy the log to a new file, and leave out the lines you
don’t want.

[toc] | [prev] | [next] | [standalone]

#81127

On 2026-01-14 21:54, Lawrence D’Oliveiro wrote:
> On Wed, 14 Jan 2026 14:42:44 +0100, Carlos E.R. wrote:
> 
>> I want to purge from the journal all messages from facility=news,
>> level>Warning, age> 7 days. Only those messages. Leave all the rest
>> intact.
> 
> You can’t purge selected lines from a logfile with syslog, either. 

Yes, I can and I do.

With config lines in /etc/rsyslog.conf and in logrotate.

> You
> would have to copy the log to a new file, and leave out the lines you
> don’t want.

Which I can also easily do, as part of the rotate process.

-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#81130

On Wed, 14 Jan 2026 23:14:31 +0100, Carlos E.R. wrote:

> On 2026-01-14 21:54, Lawrence D’Oliveiro wrote:
>
>> You can’t purge selected lines from a logfile with syslog, either.
>
> Yes, I can and I do.
>
> With config lines in /etc/rsyslog.conf and in logrotate.

Try the journalctl --vacuum-xxx options, then.

[toc] | [prev] | [next] | [standalone]

#81157

On 2026-01-14 23:36, Lawrence D’Oliveiro wrote:
> On Wed, 14 Jan 2026 23:14:31 +0100, Carlos E.R. wrote:
> 
>> On 2026-01-14 21:54, Lawrence D’Oliveiro wrote:
>>
>>> You can’t purge selected lines from a logfile with syslog, either.
>>
>> Yes, I can and I do.
>>
>> With config lines in /etc/rsyslog.conf and in logrotate.
> 
> Try the journalctl --vacuum-xxx options, then.
        --vacuum-size=, --vacuum-time=, --vacuum-files=
            --vacuum-size= removes the oldest archived
            journal files until the disk space they use
            falls below the specified size. Accepts the
            usual "K", "M", "G" and "T" suffixes (to
            the base of 1024).

            --vacuum-time= removes archived journal
            files older than the specified timespan.
            Accepts the usual "s" (default), "m", "h",
            "days", "months", "weeks" and "years"
            suffixes, see systemd.time(7) for details.

            --vacuum-files= leaves only the specified
            number of separate journal files.

            Note that running --vacuum-size= has only
            an indirect effect on the output shown by
            --disk-usage, as the latter includes active
            journal files, while the vacuuming
            operation only operates on archived journal
            files. Similarly, --vacuum-files= might not
            actually reduce the number of journal files
            to below the specified number, as it will
            not remove active journal files.

            --vacuum-size=, --vacuum-time= and
            --vacuum-files= may be combined in a single
            invocation to enforce any combination of a
            size, a time and a number of files limit on
            the archived journal files. Specifying any
            of these three parameters as zero is
            equivalent to not enforcing the specific
            limit, and is thus redundant.

            These three switches may also be combined
            with --rotate into one command. If so, all
            active files are rotated first, and the
            requested vacuuming operation is executed
            right after. The rotation has the effect
            that all currently active files are
            archived (and potentially new, empty
            journal files opened as replacement), and
            hence the vacuuming operation has the
            greatest effect as it can take all log data
            written so far into account.


Nope. These options remove entire files, when what I want to do is purge 
messages of certain age belonging to a certain facility and certain 
severity, regardless of what file they reside in.

I repeat: this feature is intentionally not implemented by the journal. 
They want to make a photograph of the system messages, all of them, 
intact and secure, never edited or changed to ensure integrity.


-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#81159

On 15/01/2026 13:40, Carlos E.R. wrote:
> On 2026-01-14 23:36, Lawrence D’Oliveiro wrote:
>> On Wed, 14 Jan 2026 23:14:31 +0100, Carlos E.R. wrote:
>>
>>> On 2026-01-14 21:54, Lawrence D’Oliveiro wrote:
>>>
>>>> You can’t purge selected lines from a logfile with syslog, either.
>>>
>>> Yes, I can and I do.
>>>
>>> With config lines in /etc/rsyslog.conf and in logrotate.
>>
>> Try the journalctl --vacuum-xxx options, then.
>         --vacuum-size=, --vacuum-time=, --vacuum-files=
>             --vacuum-size= removes the oldest archived
>             journal files until the disk space they use
>             falls below the specified size. Accepts the
>             usual "K", "M", "G" and "T" suffixes (to
>             the base of 1024).
> 
>             --vacuum-time= removes archived journal
>             files older than the specified timespan.
>             Accepts the usual "s" (default), "m", "h",
>             "days", "months", "weeks" and "years"
>             suffixes, see systemd.time(7) for details.
> 
>             --vacuum-files= leaves only the specified
>             number of separate journal files.
> 
>             Note that running --vacuum-size= has only
>             an indirect effect on the output shown by
>             --disk-usage, as the latter includes active
>             journal files, while the vacuuming
>             operation only operates on archived journal
>             files. Similarly, --vacuum-files= might not
>             actually reduce the number of journal files
>             to below the specified number, as it will
>             not remove active journal files.
> 
>             --vacuum-size=, --vacuum-time= and
>             --vacuum-files= may be combined in a single
>             invocation to enforce any combination of a
>             size, a time and a number of files limit on
>             the archived journal files. Specifying any
>             of these three parameters as zero is
>             equivalent to not enforcing the specific
>             limit, and is thus redundant.
> 
>             These three switches may also be combined
>             with --rotate into one command. If so, all
>             active files are rotated first, and the
>             requested vacuuming operation is executed
>             right after. The rotation has the effect
>             that all currently active files are
>             archived (and potentially new, empty
>             journal files opened as replacement), and
>             hence the vacuuming operation has the
>             greatest effect as it can take all log data
>             written so far into account.
> 
> 
> Nope. These options remove entire files, when what I want to do is purge 
> messages of certain age belonging to a certain facility and certain 
> severity, regardless of what file they reside in.
> 
> I repeat: this feature is intentionally not implemented by the journal. 
> They want to make a photograph of the system messages, all of them, 
> intact and secure, never edited or changed to ensure integrity.
> 
> 
I found coincidentally that I had a directory full of a years worth of 
journal files that could not be eliminated.

They were of the form user-1000@....and system.jourmal@... all contained 
the @symbol.
I deleted them all manually.

journalctl is happier


-- 
Climate Change: Socialism wearing a lab coat.

[toc] | [prev] | [next] | [standalone]

#81180

On Thu, 15 Jan 2026 14:40:36 +0100, Carlos E.R. wrote:

> Nope. These options remove entire files, when what I want to do is
> purge messages of certain age belonging to a certain facility and
> certain severity, regardless of what file they reside in.
>
> I repeat: this feature is intentionally not implemented by the
> journal.

With Open Source, there is always a way.

Looks like the way to do it is to use the export format from
journalctl, and do your custom filtering on that. If you want to put
the result back into systemd journal format, you can use this
<https://www.freedesktop.org/software/systemd/man/latest/systemd-journal-remote.html>.

[toc] | [prev] | [next] | [standalone]

#81206

On 2026-01-16 05:20, Lawrence D’Oliveiro wrote:
> On Thu, 15 Jan 2026 14:40:36 +0100, Carlos E.R. wrote:
> 
>> Nope. These options remove entire files, when what I want to do is
>> purge messages of certain age belonging to a certain facility and
>> certain severity, regardless of what file they reside in.
>>
>> I repeat: this feature is intentionally not implemented by the
>> journal.
> 
> With Open Source, there is always a way.
> 
> Looks like the way to do it is to use the export format from
> journalctl, and do your custom filtering on that. If you want to put
> the result back into systemd journal format, you can use this
> <https://www.freedesktop.org/software/systemd/man/latest/systemd-journal-remote.html>.

Way too complicated. Instead I simply continue using syslog.

-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#81208

On Fri, 16 Jan 2026 21:40:30 +0100, Carlos E.R. wrote:

> Way too complicated.

First you said it couldn’t be done at all -- that it was
“intentionally impossible”, and “intentionally not implemented by the
journal”. Now when I point out it can be done quite easily,
potentially with just a few lines of script, you claim that’s “way too
complicated”.

What I think is, it’s your existing way of laboriously copying and
filtering text-format logfiles with your own (likely regexp-heavy)
custom scripting, that is “way too complicated”, and you are suffering
from something called the “sunk-cost fallacy”, where you don’t want to
throw away all the effort you have put into your existing ways of
doing things, even if the new way is simpler.

[toc] | [prev] | [next] | [standalone]

#81210

On 2026-01-16 22:03, Lawrence D’Oliveiro wrote:
> On Fri, 16 Jan 2026 21:40:30 +0100, Carlos E.R. wrote:
> 
>> Way too complicated.
> 
> First you said it couldn’t be done at all -- that it was
> “intentionally impossible”, and “intentionally not implemented by the
> journal”. Now when I point out it can be done quite easily,
> potentially with just a few lines of script, you claim that’s “way too
> complicated”.

It is way too complicated. I want tools provided by the systemd people, not hacks.

Remember, I was simply commenting a feature that syslog has as default, and systemd refuses to implement.

> What I think is, it’s your existing way of laboriously copying and
> filtering text-format logfiles with your own (likely regexp-heavy)
> custom scripting, that is “way too complicated”, and you are suffering
> from something called the “sunk-cost fallacy”, where you don’t want to
> throw away all the effort you have put into your existing ways of
> doing things, even if the new way is simpler.

I am using no scripting at all. I use the default toolset for handling syslog messages for decades of *nix.

/etc/rsyslog.conf:    (this configuration came with the system, commented out, so I just had to uncoment it)

news.crit                               -/var/log/news/news.crit
news.err                                -/var/log/news/news.err
news.notice                             -/var/log/news/news.notice
news.debug                              -/var/log/news/news.debug


/etc/logrotate.d/syslog:    (this configuration is the same as default for other files)

/var/log/news/news.crit /var/log/news/news.err /var/log/news/news.notice {
     compress
     dateext
     maxage 365
     rotate 99
     missingok
     notifempty
     size +4096k
     su news news
     create 640 news news
     sharedscripts
     postrotate
         /usr/bin/systemctl reload syslog.service > /dev/null
#       /etc/init.d/syslog reload > /dev/null
     endscript
}


#CER news.debug is very verbose, not needed to keep long.
/var/log/news/news.debug  {
     compress
     dateext
     maxage 30
     rotate 10
     missingok
     notifempty
     size +4096k
     su news news
     create 640 news news
     sharedscripts
     postrotate
         /usr/bin/systemctl reload syslog.service > /dev/null
     endscript
}



-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#81216

On Fri, 16 Jan 2026 22:23:08 +0100, Carlos E.R. wrote:

> I am using no scripting at all. I use the default toolset for
> handling syslog messages for decades of *nix.
>
> /etc/rsyslog.conf: (this configuration came with the system,
> commented out, so I just had to uncoment it)
>
> news.crit                               -/var/log/news/news.crit
> news.err                                -/var/log/news/news.err
> news.notice                             -/var/log/news/news.notice
> news.debug                              -/var/log/news/news.debug

This involves splitting out the messages into categories upfront, at
collection time, not analysis time.

> /etc/logrotate.d/syslog:    (this configuration is the same as default for other files)
>
> [etc]

Same applies here.

> I want tools provided by the systemd people, not hacks.

Most data-collection philosophy is “collect everything first, split it
out for analysis later”. That seems to me more flexible than having to
decide up front how you want to divide up the raw data for analysis.
Because what happens if you change your mind about how you want to
analyze data you’ve already collected?

And it’s how the systemd tools work.

[toc] | [prev] | [next] | [standalone]

#81217

On 2026-01-16 22:41, Lawrence D’Oliveiro wrote:
> On Fri, 16 Jan 2026 22:23:08 +0100, Carlos E.R. wrote:
> 
>> I am using no scripting at all. I use the default toolset for
>> handling syslog messages for decades of *nix.
>>
>> /etc/rsyslog.conf: (this configuration came with the system,
>> commented out, so I just had to uncoment it)
>>
>> news.crit                               -/var/log/news/news.crit
>> news.err                                -/var/log/news/news.err
>> news.notice                             -/var/log/news/news.notice
>> news.debug                              -/var/log/news/news.debug
> 
> This involves splitting out the messages into categories upfront, at
> collection time, not analysis time.

Certainly. That's the syslog way.

> 
>> /etc/logrotate.d/syslog:    (this configuration is the same as default for other files)
>>
>> [etc]
> 
> Same applies here.
> 
>> I want tools provided by the systemd people, not hacks.
> 
> Most data-collection philosophy is “collect everything first, split it
> out for analysis later”. That seems to me more flexible than having to
> decide up front how you want to divide up the raw data for analysis.
> Because what happens if you change your mind about how you want to
> analyze data you’ve already collected?
> 
> And it’s how the systemd tools work.

systemd collects all data, and does not provide any means to purge 
selectively some data. It can only filter on display.

-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#81250

On Fri, 16 Jan 2026 22:53:47 +0100, Carlos E.R. wrote:

> On 2026-01-16 22:41, Lawrence D’Oliveiro wrote:
>>
>> This involves splitting out the messages into categories upfront, at
>> collection time, not analysis time.
> 
> Certainly. That's the syslog way.

That’s not a very scientific way.

> systemd collects all data, and does not provide any means to purge 
> selectively some data.

I already explained to you how you can do exactly that.

[toc] | [prev] | [next] | [standalone]

#81253

On 2026-01-17 21:34, Lawrence D’Oliveiro wrote:
> On Fri, 16 Jan 2026 22:53:47 +0100, Carlos E.R. wrote:
> 
>> On 2026-01-16 22:41, Lawrence D’Oliveiro wrote:
>>>
>>> This involves splitting out the messages into categories upfront, at
>>> collection time, not analysis time.
>>
>> Certainly. That's the syslog way.
> 
> That’s not a very scientific way.
> 
>> systemd collects all data, and does not provide any means to purge
>> selectively some data.
> 
> I already explained to you how you can do exactly that.

Not with tools officially provided by the systemd people. Fully 
compliant. A hack.

-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.os.linux.misc

csiph-web