Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.misc > #81041 > unrolled thread
| Started by | Robert Riches <spamtrap42@jacob21819.net> |
|---|---|
| First post | 2026-01-13 04:57 +0000 |
| Last post | 2026-01-13 19:52 +0000 |
| Articles | 18 on this page of 78 — 11 participants |
Back to article view | Back to comp.os.linux.misc
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 4 of 4 — ← Prev page 1 2 3 [4]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-01-19 00:46 +0000 |
| Message-ID | <10kjutp$3tacf$5@dont-email.me> |
| In reply to | #81280 |
On Sun, 18 Jan 2026 23:05:56 +0100, Carlos E.R. wrote: > On 2026-01-18 22:02, Lawrence D’Oliveiro wrote: >> >> On Sun, 18 Jan 2026 12:55:40 +0100, Carlos E.R. wrote: >> >>> ... and convert the logs to another set in whatever other time zone >>> you wish. >> >> But you can’t do that with tools provided with syslog. > > Certainly it can. Not that part.
[toc] | [prev] | [next] | [standalone]
| From | Nuno Silva <nunojsilva@invalid.invalid> |
|---|---|
| Date | 2026-01-16 23:30 +0000 |
| Message-ID | <10kehls$23etv$1@dont-email.me> |
| In reply to | #81208 |
On 2026-01-16, Lawrence D’Oliveiro wrote: > On Fri, 16 Jan 2026 21:40:30 +0100, Carlos E.R. wrote: > >> Way too complicated. > > First you said it couldn’t be done at all -- that it was > “intentionally impossible”, and “intentionally not implemented by the > journal”. Now when I point out it can be done quite easily, > potentially with just a few lines of script, you claim that’s “way too > complicated”. > > What I think is, it’s your existing way of laboriously copying and > filtering text-format logfiles with your own (likely regexp-heavy) > custom scripting, that is “way too complicated”, and you are suffering > from something called the “sunk-cost fallacy”, where you don’t want to > throw away all the effort you have put into your existing ways of > doing things, even if the new way is simpler. No, you're again LDO-ing the conversation. You effectively said this can't be done within systemd's journal. That may be ok, and it may well be possible to do it externaly, easily or less so, but the point stands that someone pointed a use case for which that journal apparently (from what you said) isn't a suitable replacement. As usual, you try to sweep this under the rug of "it's FLOSS so you can change it [or make it part of a larger workflow]". (If you really insist in going in that direction, there's not much to be discussed, because, as far as the missing bits can be implemented in a Turing-complete language, it has to be possible to do so; the only limitation is going to be licensing. That part you got right. But derailing the train of thought this way really appears like you're making extensive efforts to avoid conceding that the tool you prefer does not have this feature.) -- Nuno Silva
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-01-17 14:36 +0100 |
| Message-ID | <fsfs3mxu17.ln2@Telcontar.valinor> |
| In reply to | #81218 |
On 2026-01-17 00:30, Nuno Silva wrote: > On 2026-01-16, Lawrence D’Oliveiro wrote: > >> On Fri, 16 Jan 2026 21:40:30 +0100, Carlos E.R. wrote: >> >>> Way too complicated. >> >> First you said it couldn’t be done at all -- that it was >> “intentionally impossible”, and “intentionally not implemented by the >> journal”. Now when I point out it can be done quite easily, >> potentially with just a few lines of script, you claim that’s “way too >> complicated”. >> >> What I think is, it’s your existing way of laboriously copying and >> filtering text-format logfiles with your own (likely regexp-heavy) >> custom scripting, that is “way too complicated”, and you are suffering >> from something called the “sunk-cost fallacy”, where you don’t want to >> throw away all the effort you have put into your existing ways of >> doing things, even if the new way is simpler. > > No, you're again LDO-ing the conversation. You effectively said this > can't be done within systemd's journal. That may be ok, and it may well > be possible to do it externaly, easily or less so, but the point stands > that someone pointed a use case for which that journal apparently (from > what you said) isn't a suitable replacement. > > As usual, you try to sweep this under the rug of "it's FLOSS so you can > change it [or make it part of a larger workflow]". > > (If you really insist in going in that direction, there's not much to be > discussed, because, as far as the missing bits can be implemented in a > Turing-complete language, it has to be possible to do so; the only > limitation is going to be licensing. That part you got right. But > derailing the train of thought this way really appears like you're > making extensive efforts to avoid conceding that the tool you prefer > does not have this feature.) > In some machines, the journal is cryptographically signed. Thus any later manipulation is impossible, it invalidates the signature. -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2026-01-17 18:25 +0000 |
| Message-ID | <10kgk5t$2olv6$2@dont-email.me> |
| In reply to | #81244 |
On 17/01/2026 13:36, Carlos E.R. wrote:
> On 2026-01-17 00:30, Nuno Silva wrote:
>> On 2026-01-16, Lawrence D’Oliveiro wrote:
>>
>>> On Fri, 16 Jan 2026 21:40:30 +0100, Carlos E.R. wrote:
>>>
>>>> Way too complicated.
>>>
>>> First you said it couldn’t be done at all -- that it was
>>> “intentionally impossible”, and “intentionally not implemented by the
>>> journal”. Now when I point out it can be done quite easily,
>>> potentially with just a few lines of script, you claim that’s “way too
>>> complicated”.
>>>
>>> What I think is, it’s your existing way of laboriously copying and
>>> filtering text-format logfiles with your own (likely regexp-heavy)
>>> custom scripting, that is “way too complicated”, and you are suffering
>>> from something called the “sunk-cost fallacy”, where you don’t want to
>>> throw away all the effort you have put into your existing ways of
>>> doing things, even if the new way is simpler.
>>
>> No, you're again LDO-ing the conversation. You effectively said this
>> can't be done within systemd's journal. That may be ok, and it may well
>> be possible to do it externaly, easily or less so, but the point stands
>> that someone pointed a use case for which that journal apparently (from
>> what you said) isn't a suitable replacement.
>>
>> As usual, you try to sweep this under the rug of "it's FLOSS so you can
>> change it [or make it part of a larger workflow]".
>>
>> (If you really insist in going in that direction, there's not much to be
>> discussed, because, as far as the missing bits can be implemented in a
>> Turing-complete language, it has to be possible to do so; the only
>> limitation is going to be licensing. That part you got right. But
>> derailing the train of thought this way really appears like you're
>> making extensive efforts to avoid conceding that the tool you prefer
>> does not have this feature.)
>>
>
> In some machines, the journal is cryptographically signed. Thus any
> later manipulation is impossible, it invalidates the signature.
>
Yes. systemd is very 'big corporate' Huge data, no tampering, discard
nothing *in case*.
Totally inappropriate for single user desktop use.
--
"First, find out who are the people you can not criticise. They are your
oppressors."
- George Orwell
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-01-17 20:33 +0000 |
| Message-ID | <10kgrn6$2rc7o$3@dont-email.me> |
| In reply to | #81244 |
On Sat, 17 Jan 2026 14:36:47 +0100, Carlos E.R. wrote: > In some machines, the journal is cryptographically signed. Thus any > later manipulation is impossible, it invalidates the signature. Where do you think a piece of open-source software could hide a crypto key from you on your own machine? This sort of thing is always under the sysadmin’s control.
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2026-01-18 10:48 +0000 |
| Message-ID | <wwv3443nqm9.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #81244 |
"Carlos E.R." <robin_listas@es.invalid> writes: > In some machines, the journal is cryptographically signed. Thus any > later manipulation is impossible, it invalidates the signature. _Undetectable_ manipulation is impossible. Data doesn’t become immutable just because there’s a signature on it. In the specific case of journald: If you don’t want signed logs, you don’t have to sign them. If you do have signed logs, you don’t have to verify them if you don’t want to. -- https://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | Harold Stevens <wookie@aspen.localdomain> |
|---|---|
| Date | 2026-01-17 10:23 -0600 |
| Message-ID | <slrn10mndsk.1376.wookie@aspen.localdomain> |
| In reply to | #81218 |
In Message-ID: <10kehls$23etv$1@dont-email.me> > No, you're again LDO-ing the conversation. +1 Carlos may as well not be involved. FLOSS Gospel matters more. -- 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 (404) GoogleGroup (404 http://twovoyagers.com/improve-usenet.org/).
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2026-01-18 10:43 +0000 |
| Message-ID | <wwv8qdvnqv8.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #81115 |
"Carlos E.R." <robin_listas@es.invalid> writes:
> I want to purge from the journal all messages from facility=news,
> level>Warning, age> 7 days. Only those messages. Leave all the rest
> intact.
>
> Doing this goes against the philosophy of the journal, so it is
> intentionally imposible.
It’s a long-standing TODO[1]. There is also support for multiple
namespaces with different expiry policies, but I suspect it’s not
flexible enought to meet your requirements in a sensible way.
Anyway, this is not consistent with “intentionally impossible”. It just
hasn’t been implemented yet.
[1] from https://github.com/systemd/systemd/blob/main/TODO#L2454:
- journald: allow per-priority and per-service retention times when
rotating/vacuuming
--
https://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-01-18 12:59 +0100 |
| Message-ID | <7huu3mxkli.ln2@Telcontar.valinor> |
| In reply to | #81261 |
On 2026-01-18 11:43, Richard Kettlewell wrote: > "Carlos E.R." <robin_listas@es.invalid> writes: >> I want to purge from the journal all messages from facility=news, >> level>Warning, age> 7 days. Only those messages. Leave all the rest >> intact. >> >> Doing this goes against the philosophy of the journal, so it is >> intentionally imposible. > > It’s a long-standing TODO[1]. There is also support for multiple > namespaces with different expiry policies, but I suspect it’s not > flexible enought to meet your requirements in a sensible way. > > Anyway, this is not consistent with “intentionally impossible”. It just > hasn’t been implemented yet. I was told it was “intentionally impossible” by people in the know back then. > > [1] from https://github.com/systemd/systemd/blob/main/TODO#L2454: > > - journald: allow per-priority and per-service retention times when > rotating/vacuuming Good to know. -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-01-18 21:06 +0000 |
| Message-ID | <10kji10$3p7to$5@dont-email.me> |
| In reply to | #81267 |
On Sun, 18 Jan 2026 12:59:03 +0100, Carlos E.R. wrote: > I was told it was “intentionally impossible” by people in the know > back then. Obviously, whatever it was they were “in the know” about, it wasn’t systemd. Shouldn’t it have been obvious to you, even back then if not now, that you *cannot* design Open Source software to make anything (short of violating the laws of mathematics or physics) “intentionally impossible”?
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-01-18 23:06 +0100 |
| Message-ID | <c4204mx7r3.ln2@Telcontar.valinor> |
| In reply to | #81273 |
On 2026-01-18 22:06, Lawrence D’Oliveiro wrote: > On Sun, 18 Jan 2026 12:59:03 +0100, Carlos E.R. wrote: > >> I was told it was “intentionally impossible” by people in the know >> back then. > > Obviously, whatever it was they were “in the know” about, it wasn’t > systemd. Oh, yes they were. Systemd devs. > > Shouldn’t it have been obvious to you, even back then if not now, that > you *cannot* design Open Source software to make anything (short of > violating the laws of mathematics or physics) “intentionally > impossible”? -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-01-19 00:48 +0000 |
| Message-ID | <10kjv0n$3tacf$6@dont-email.me> |
| In reply to | #81279 |
On Sun, 18 Jan 2026 23:06:36 +0100, Carlos E.R. wrote: > On 2026-01-18 22:06, Lawrence D’Oliveiro wrote: >> >> On Sun, 18 Jan 2026 12:59:03 +0100, Carlos E.R. wrote: >> >>> I was told it was “intentionally impossible” by people in the know >>> back then. >> >> Obviously, whatever it was they were “in the know” about, it wasn’t >> systemd. > > Oh, yes they were. Systemd devs. All I can say is, either they misinterpreted your question, or you misinterpreted their reply. Because the tools provided do indeed allow you to filter the logs in exactly the way you have described.
[toc] | [prev] | [next] | [standalone]
| From | Nuno Silva <nunojsilva@invalid.invalid> |
|---|---|
| Date | 2026-01-19 09:44 +0000 |
| Message-ID | <10kkudi$6osq$2@dont-email.me> |
| In reply to | #81285 |
On 2026-01-19, Lawrence D’Oliveiro wrote: > On Sun, 18 Jan 2026 23:06:36 +0100, Carlos E.R. wrote: > >> On 2026-01-18 22:06, Lawrence D’Oliveiro wrote: >>> >>> On Sun, 18 Jan 2026 12:59:03 +0100, Carlos E.R. wrote: >>> >>>> I was told it was “intentionally impossible” by people in the know >>>> back then. >>> >>> Obviously, whatever it was they were “in the know” about, it wasn’t >>> systemd. >> >> Oh, yes they were. Systemd devs. > > All I can say is, either they misinterpreted your question, or you > misinterpreted their reply. Because the tools provided do indeed allow > you to filter the logs in exactly the way you have described. You keep doing this, you keep alluding at your idea of externally handling it as evidence that it can be done internally. Those are two different things. -- Nuno Silva
[toc] | [prev] | [next] | [standalone]
| From | Nuno Silva <nunojsilva@invalid.invalid> |
|---|---|
| Date | 2026-01-13 11:40 +0000 |
| Message-ID | <10k5auk$32slq$3@dont-email.me> |
| In reply to | #81057 |
On 2026-01-13, 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. Really? Care to elaborate? I'd think both would deal with it in some way once configured to do so. Why are you elevating systemd on this regard? What's the killer feature there that logrotate and compatible syslog implementations don't have? -- Nuno Silva
[toc] | [prev] | [next] | [standalone]
| From | Robert Riches <spamtrap42@jacob21819.net> |
|---|---|
| Date | 2026-01-14 03:27 +0000 |
| Message-ID | <slrn10me38l.oqh.spamtrap42@one.localnet> |
| In reply to | #81044 |
On 2026-01-13, c186282 <c186282@nnada.net> wrote: > 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. With behavior probably inherited from pre-systemd Debian, Devuan takes care of that pretty well for most practical purposes: keep the current file and one prior uncompressed, compress everything older than that, keep only a fixed number of compressed files. IIRC, I have seen the same or rather similar behavior in all other distributions I have used. In this particular case, the flooding has stopped, and there is enough disk space that the current 1.1GB files won't likely be a problem between now and when they are rotated off the edge of the planet. If I had been more prompt in logging in from the thin-client machine, the files would not have reached the size they did. Thanks. -- Robert Riches spamtrap42@jacob21819.net (Yes, that is one of my email addresses.)
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-01-13 11:24 +0100 |
| Message-ID | <b3jh3mx9rh.ln2@Telcontar.valinor> |
| In reply to | #81041 |
On 2026-01-13 05:57, Robert Riches wrote: > 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 ! Repeated entries should have been detected and filtered, with a line like "1000 of these". -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | Nuno Silva <nunojsilva@invalid.invalid> |
|---|---|
| Date | 2026-01-13 11:43 +0000 |
| Message-ID | <10k5b44$32slq$4@dont-email.me> |
| In reply to | #81065 |
On 2026-01-13, Carlos E.R. wrote: > On 2026-01-13 05:57, Robert Riches wrote: >> 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 ! > > Repeated entries should have been detected and filtered, with a line > like "1000 of these". That, if present, ought to be configurable, because the timestamps are information too. -- Nuno Silva
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-01-13 19:52 +0000 |
| Message-ID | <10k67pd$3cii8$5@dont-email.me> |
| In reply to | #81065 |
On Tue, 13 Jan 2026 11:24:11 +0100, Carlos E.R. wrote: > Repeated entries should have been detected and filtered, with a line > like "1000 of these". systemd does that by default.
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.os.linux.misc
csiph-web