On 2023-03-10 08:58, Per Jessen wrote:

Carlos E. R. wrote:

...

Why so many debug messages are going to the /var/log/warn log file?

I almost overlooked your [rant] in the subject :-) I'll try to keep my reply in the same spirit :-)

First of all, it depends on your syslog settings, but you probably have the default where any log message with level warning, error or critical is written to /var/log/warn.

Yes, certainly, except that I have, over the years, written reams of rules to filter out the noise.

...

For example:

<1.3> 2023-03-09T21:28:27.225193+01:00 Telcontar xsane - - - io/hpmud/model.c 532: no hp_HP_Color_LaserJet_CP1515n attributes found in /usr/share/hplip/data/models/models.dat <1.3> 2023-03-09T21:28:27.228248+01:00 Telcontar xsane - - - io/hpmud/model.c 543: no hp_HP_Color_LaserJet_CP1515n attributes found in /usr/share/hplip/data/models/unreleased/unreleased.dat

Well, it is a printer only, but xsane is looking to see if it has a scanner and not finding it. Why is that so huge a problem that I have to be warned about it?

Well, try to look at it from the pov of xsane. xsane has been asked to "look" at your printer, but is unable as the model data is not available. For xsane, that is a problem, albeit not a serious one. Hence a warning.

Asked by whom? Not by me. xsane is probing hardwware (the printer is in the LAN). The messages caused by probing are noise. The warn log should only have serious things.

...

I don't care. The programmer might want to see it, but users have no need to see it.

Users have got no business looking at /var/log/warn - that is for the admin.

I have the admin hat on.

...

Yet it has priority 3. It should be a debug message. For the programmer.

* debugging happens during development. It is the process of getting rid of bugs. Cf. Grace Hopper. * when built for production, most debugging messages are disabled, some maybe be left, to be activated with one or more '-d' switches. * this problem is not a bug, it is an unexpected operational issue. * there is no way xsane can communicate anything to the programmer, from some arbitrary system. * even if, why would the programmer care that your system data is incomplete?

...

<1.4> 2023-03-09T23:11:37.426440+01:00 Telcontar tracker-extract 24161 - - Locale 'LANG' is not set, defaulting to C locale

The application expects to find a valid locale setting, but does not find one. Configuration issue, sounds like it is reasonable to log a warning. I think that message is from the library, not the application.

Configuration issue but not by me, I did not configure it.

...

Why is that a warning, and spamming the WARNING log?

A1. Same reason as with xsane - the library has been asked to set up locale data, but cannot find the LANG setting. A2. because the condition repeats regularly.

But not by me.

...

<1.4> 2023-03-09T21:45:20.910119+01:00 Telcontar krusader 17147 - - QCoreApplication::applicationDirPath: Please instantiate the QApplication object first [snip]

See above.

No, it is a message for the programmer, that did a "bad" job.

...

There are so many messages going as WARNINGS that the truly important ones are ignored.

Oh no. On my systems, they are all ignored, I usually remove that logging to /var/log/warn.

...

Sometimes I write a rule on rsyslog to clear some, but there are so many!

I presume you are actively monitoring /var/log/warn, so that filtering would be much easier to do with a grep.

Of course I do monitor warn, and others. If only warning entries were written to warn, there would be nothing for days. When something appears, it is serious.

To answer $SUBJ - they are not debug messages, they are reports of operational issues.

IMO, they are debug messages. Not important enough to be there. They would be fine in the /var/log/messages. Those softwares run perfectly fine despite the logs. Only something that crashes should go to warn. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

On 2023-03-10 13:32, Per Jessen wrote:

Carlos E. R. wrote:

...

...

...

For example:

Well, try to look at it from the pov of xsane. xsane has been asked to "look" at your printer, but is unable as the model data is not available. For xsane, that is a problem, albeit not a serious one. Hence a warning.

Asked by whom? Not by me.

Who started up xsane?

I did not tell it to search for that printer.

...

xsane is probing hardwware (the printer is in the LAN). The messages caused by probing are noise. The warn log should only have serious things.

It seems to me that the nature of a warning is "be careful about this, otherwise something serious might happen".

Nothing serious about it. It is probing for scanners, HP makes scanners, but that one doesn't have a scanner. Noise.

...

...

I presume you are actively monitoring /var/log/warn, so that filtering would be much easier to do with a grep.

Of course I do monitor warn, and others. If only warning entries were written to warn, there would be nothing for days. When something appears, it is serious.

I honestly don't know that there is much "of course" about monitoring /var/log/warn. I certain never have - removing it is one of the first customisations we do to any newly installed system.

You remove the file? I'm truly astonished.

...

...

To answer $SUBJ - they are not debug messages, they are reports of operational issues.

IMO, they are debug messages. Not important enough to be there. They would be fine in the /var/log/messages. Those softwares run perfectly fine despite the logs. Only something that crashes should go to warn.

To each his own. Anyway, instead of ranting, why don't you put on your admin hat and go reconfigure your syslog not to log warn messages to /var/log/warn ?

Attached is a patch.

I do want warnings. *True* warnings, not noise. Sometimes, I report noise to bugzilla... -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

On 2023-03-10 14:18, Per Jessen wrote:

Carlos E. R. wrote:

...

On 2023-03-10 13:32, Per Jessen wrote:

...

Carlos E. R. wrote:

...

...

...

For example:

Well, try to look at it from the pov of xsane. xsane has been asked to "look" at your printer, but is unable as the model data is not available. For xsane, that is a problem, albeit not a serious one. Hence a warning.

Asked by whom? Not by me.

Who started up xsane?

I did not tell it to search for that printer.

a) you installed xsane b) you accepted the default config c) you started xsane.

I configured in YaST which is the scanner. No need to probe. And anyway, probing messagges are noise by definition, unless there is a "I can not probe at all", and this can be told to the user in the same dialog where I ask to open the scanner or probe for it. The messages about the progress of the probing are not to go into the warning log.

...

...

It seems to me that the nature of a warning is "be careful about this, otherwise something serious might happen".

Nothing serious about it. It is probing for scanners, HP makes scanners, but that one doesn't have a scanner.

If you're keen on only "serious" things being written to /var/log/warn, see my patch.

What, remove warning entries from the warning log? Not going to happen. The syslog definition is correct, the problem is the programs defining their debug messages as warnings.

...

...

I honestly don't know that there is much "of course" about monitoring /var/log/warn. I certain never have - removing it is one of the first customisations we do to any newly installed system.

You remove the file?

We remove the logging to it, yes. Nobody ever looks at it. I think it is an ancient relic from early UNIX days. The syslog config has a lot of old crud - for instance:

/var/log/mail.info/err/notice /var/log/news/news.crit/err/notice.

I use both.

...

...

...

IMO, they are debug messages. Not important enough to be there. They would be fine in the /var/log/messages. Those softwares run perfectly fine despite the logs. Only something that crashes should go to warn.

To each his own. Anyway, instead of ranting, why don't you put on your admin hat and go reconfigure your syslog not to log warn messages to /var/log/warn ?

Attached is a patch.

I do want warnings. *True* warnings, not noise.

Noise is in the eyes (well, ears) of the beholder.

Yes. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

On 2023-03-10 17:01, Per Jessen wrote:

Carlos E. R. wrote:

...

And anyway, probing messagges are noise by definition, unless there is a "I can not probe at all", and this can be told to the user in the same dialog where I ask to open the scanner or probe for it. The messages about the progress of the probing are not to go into the warning log. [snip] The syslog definition is correct, the problem is the programs defining their debug messages as warnings.

Well, seeing as your ideas of debugging are quite different to mine, I guess it is time for a bugzilla or a pull request.

Which I do. I have posted several bugzillas, but it is a lot of work, one per noisy message. Recently: Bug 1207778 - systemd complains: Failed to resolve group 'brltty'

...

...

We remove the logging to it, yes. Nobody ever looks at it. I think it is an ancient relic from early UNIX days. The syslog config has a lot of old crud - for instance:

/var/log/mail.info/err/notice /var/log/news/news.crit/err/notice.

I use both.

Why I am not surprised :-)

We remove mail.{info,err,notice} on all machines, and I only have one single machine that has any use for news.{crit,err,notice} - our news-server.

I can understand removing news logs if there is no news handling in a machine, but all my machines send email. If there is a problem and the log is disabled, it would be a disaster. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

On 2023-03-10 21:15, Per Jessen wrote:

Carlos E. R. wrote:

...

On 2023-03-10 17:01, Per Jessen wrote:

...

Carlos E. R. wrote:

...

And anyway, probing messagges are noise by definition, unless there is a "I can not probe at all", and this can be told to the user in the same dialog where I ask to open the scanner or probe for it. The messages about the progress of the probing are not to go into the warning log. [snip] The syslog definition is correct, the problem is the programs defining their debug messages as warnings.

Well, seeing as your ideas of debugging are quite different to mine, I guess it is time for a bugzilla or a pull request.

Which I do. I have posted several bugzillas, but it is a lot of work, one per noisy message.

Maybe it is worth mentioning that it is even more effort for the developer and the packagers.

...

...

We remove mail.{info,err,notice} on all machines, and I only have one single machine that has any use for news.{crit,err,notice} - our news-server.

I can understand removing news logs if there is no news handling in a machine, but all my machines send email.

Really??

Certainly. Even the server. Two desktops (two locations), two laptops... even some of the virtual machines. Plus the archived machines.

...

If there is a problem and the log is disabled, it would be a disaster.

Personal problem I suggest. I think maybe I handle a bit more email than you do, but you are welcome to volunteer your expertise for the Heroes team, we also have a couple of mail servers that need some TLC occasionally. No mail.{info,err,notice} logs though.

Huh. I can't work without logs. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

On 2023-03-11 09:23, Per Jessen wrote:

Carlos E. R. wrote:

...

On 2023-03-10 21:15, Per Jessen wrote:

...

...

I can understand removing news logs if there is no news handling in a machine, but all my machines send email.

Really??

Certainly. Even the server. Two desktops (two locations), two laptops... even some of the virtual machines. Plus the archived machines.

https://en.wikipedia.org/wiki/Sarcasm

...

No mail.{info,err,notice} logs though.

Huh. I can't work without logs.

You can't read very well either. Try reading the above again, just that _one_ line.

I don't detect sarcasm unless there is a explicit smiley.

Just in case you miss it - again(!) - I am talking about _three_ logfiles, in the typical shorthand of the shell:

mail.info mail.err mail.notice

That is all. I have no need for those, so they are removed from the syslog config.

I don't. Typically they'd have different rotate ages. It is possible that in a year time the verbose log is gone, but the err is still there. I have err, warn, info and mail. I don't see "notice". -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

On 2023-03-10 21:59, Dave Howorth wrote:

On Fri, 10 Mar 2023 20:49:45 +0100 "Carlos E. R." <> wrote:

...

On 2023-03-10 17:01, Per Jessen wrote:

...

Carlos E. R. wrote:

...

And anyway, probing messagges are noise by definition, unless there is a "I can not probe at all", and this can be told to the user in the same dialog where I ask to open the scanner or probe for it. The messages about the progress of the probing are not to go into the warning log. [snip] The syslog definition is correct, the problem is the programs defining their debug messages as warnings.

I'm with Per here. There's no way a developer will see any messages on your systems, so either the messages are wrongly classified or configured in the application or they aren't debugging messages.

That's exactly what I am saying! They are wrongly classified or configured in the applications. My normal action when I see a warning message is dispatch a bug, something is wrong. But there are way too many! The criteria for sending a message as "warning" to syslog has become too lax, applications are now way more verbose (as warnings) that they were a decade ago.

...

...

Well, seeing as your ideas of debugging are quite different to mine, I guess it is time for a bugzilla or a pull request.

Which I do. I have posted several bugzillas, but it is a lot of work, one per noisy message.

Recently:

Bug 1207778 - systemd complains: Failed to resolve group 'brltty'

I'm impressed :)

An update has been submitted.

...

...

...

...

We remove the logging to it, yes. Nobody ever looks at it. I think it is an ancient relic from early UNIX days. The syslog config has a lot of old crud - for instance:

/var/log/mail.info/err/notice /var/log/news/news.crit/err/notice.

I use both.

Why I am not surprised :-)

Me too.

...

...

We remove mail.{info,err,notice} on all machines, and I only have one single machine that has any use for news.{crit,err,notice} - our news-server.

I can understand removing news logs if there is no news handling in a machine, but all my machines send email. If there is a problem and the log is disabled, it would be a disaster.

I don't know about your MUA but in mine (Claws) if I have a problem sending a message I go to the menus: Tools/Network Log and have a look at exactly what was sent over the wire. If necessary i restart the program from the command-line and increase logging further. No need to go to any system logs and no problem if they're missing.

Well, there is a difference: my MUAs hand over the email to postfix for sending. This was a necessity long ago, because I used Alpine as MUA. Now it is a preference. And in this machine, I run an nntp (news) proxy server, so there is a lot of writing in the news logs. So much that the systemd journal is swamped, because it doesn't have the capability to filter anything out. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

On 2023-03-11 07:33, Andrei Borzenkov wrote:

On 11.03.2023 00:27, Carlos E. R. wrote:

...

My normal action when I see a warning message is dispatch a bug, something is wrong.

Instead of trying to understand why this warning is printed? No surprise there are so many unhandled bug reports.

Well, for example in Bug 1207778 someone forgot to create group 'brltty' when the package gets installed. In this case, which I have not yet reported: <1.4> 2023-03-09T23:11:37.426440+01:00 Telcontar tracker-extract 24161 - - Locale 'LANG' is not set, defaulting to C locale <1.4> 2023-03-09T23:20:54.003175+01:00 Telcontar tracker-extract 24897 - - Locale 'LANG' is not set, defaulting to C locale <1.4> 2023-03-09T23:21:36.812011+01:00 Telcontar tracker-extract 24927 - - Locale 'LANG' is not set, defaulting to C locale Something is not setting the locale. I can get thousand of those. Notice that I do not call tracker-extract myself, nor did I configure it myself. These: <1.4> 2023-03-09T21:45:20.910119+01:00 Telcontar krusader 17147 - - QCoreApplication::applicationDirPath: Please instantiate the QApplication object first <1.4> 2023-03-09T21:45:21.655721+01:00 Telcontar krusader 17147 - - 21:45:21.655-warning default unknown@0 # QWidget::insertAction: Attempt to insert null action <1.4> 2023-03-09T21:45:21.657776+01:00 Telcontar krusader 17147 - - 21:45:21.657-warning default unknown@0 # QWidget::insertAction: Attempt to insert null action <1.4> 2023-03-09T21:45:21.666504+01:00 Telcontar krusader 17147 - - 21:45:21.666-warning kf.i18n unknown@0 # Trying to convert empty KLocalizedString to QString. <1.4> 2023-03-09T21:53:41.223609+01:00 Telcontar tracker-extract 17950 - - Locale 'LANG' is not set, defaulting to C locale <1.4> 2023-03-09T22:20:14.013742+01:00 Telcontar krusader 6836 - - 22:20:14.012-warning kf.kio.widgets unknown@0 # Failed to check which JobView API is supported "The name org.kde.kuiserver was not provided by any .service files" are programmers errors. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

On 2023-03-12 04:47, J Leslie Turriff wrote:

On 2023-03-11 04:33:51 Carlos E. R. wrote:

...

These:

<1.4> 2023-03-09T21:45:20.910119+01:00 Telcontar krusader 17147 - - QCoreApplication::applicationDirPath: Please instantiate the QApplication object first <1.4> 2023-03-09T21:45:21.655721+01:00 Telcontar krusader 17147 - - 21:45:21.655-warning default unknown@0 # QWidget::insertAction: Attempt to insert null action <1.4> 2023-03-09T21:45:21.657776+01:00 Telcontar krusader 17147 - - 21:45:21.657-warning default unknown@0 # QWidget::insertAction: Attempt to insert null action <1.4> 2023-03-09T21:45:21.666504+01:00 Telcontar krusader 17147 - - 21:45:21.666-warning kf.i18n unknown@0 # Trying to convert empty KLocalizedString to QString. <1.4> 2023-03-09T21:53:41.223609+01:00 Telcontar tracker-extract 17950 - -  Locale 'LANG' is not set, defaulting to C locale <1.4> 2023-03-09T22:20:14.013742+01:00 Telcontar krusader 6836 - - 22:20:14.012-warning kf.kio.widgets unknown@0 # Failed to check which JobView API is supported "The name org.kde.kuiserver was not provided by any .service files"

are programmers errors.

I suspect that messages like these are caused by developers who assume that their applications will always execute in a full-blown desktop designed for their use (in this case, KDE). I get the same thing with Gnome applications that assume that all of Gnome is installed, though I never use the Gnome desktop. The ones that really irritate me are those from the DE that I'm running, that spam my terminal session when I start them from the command line. I can't see any excuse for their being written to the terminal, especially since they aren't complaining about things that stop the applications' successful execution.

Well, in that case they are intended to not be run from the terminal, unless you are debugging the application. They should all have a --quiet option. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

On 2023-03-11 09:40, Per Jessen wrote:

Carlos E. R. wrote:

...

On 2023-03-10 21:59, Dave Howorth wrote:

...

On Fri, 10 Mar 2023 20:49:45 +0100 "Carlos E. R." <> wrote:

...

On 2023-03-10 17:01, Per Jessen wrote:

...

Carlos E. R. wrote:

...

And anyway, probing messagges are noise by definition, unless there is a "I can not probe at all", and this can be told to the user in the same dialog where I ask to open the scanner or probe for it. The messages about the progress of the probing are not to go into the warning log. [snip] The syslog definition is correct, the problem is the programs defining their debug messages as warnings.

I'm with Per here. There's no way a developer will see any messages on your systems, so either the messages are wrongly classified or configured in the application or they aren't debugging messages.

That's exactly what I am saying!

I think you might want to reread what you've been saying :-)

Carlos: /var/log/warn is full of debugging messages

Per/Dave: nothing in /var/log/warn will ever reach any developer, hence they are not debugging messages.

Exactly, So they should not be logged.

...

My normal action when I see a warning message is dispatch a bug,

Why on earth would you do that?

To remedy the situation, so that the programmer or packager knows about the error.

Here are some warnings from one of our (openSUSE) mailservers:

2023-03-05T00:07:33.089097+00:00 anna postfix/qmgr[17957]: warning: mail for jessen.ch is using up 5838 of 20000 active queue entries

This is not the kind of log entries I complain about. This is a true and proper warning.

2023-03-11T08:23:34.455243+00:00 anna postfix/smtp[31360]: warning: TLS library problem: error:14094417:SSL routines:ssl3_read_bytes:sslv3 alert illegal parameter:ssl/record/rec_layer_s3.c:1544:SSL alert number 47:

This one you should report. Seems a programming error.

2023-03-11T06:14:37.193691+00:00 anna postfix/smtp[8502]: warning: numeric domain name in resource data of MX record for jessen.ch:

This is a proper warning.

2023-03-11T02:17:55.283468+00:00 anna postfix/smtp[31379]: warning: no MX host for jessen.ch has a valid address record

This is a proper warning.

2023-03-11T01:29:42.339317+00:00 anna postfix/cleanup[23707]: warning: 5255D24040: message rejected: hopcount exceeded

This is a proper warning.

Those are for the _admin_, they are _warnings_ that something didn't work as expected. Any experienced admin will look at the above and disregard, a less experienced admin might start investigating.

If - and only _if_ - there is a suspected and reproducable problem with postfix, would anyone write a bugreport.

...

...

I don't know about your MUA but in mine (Claws) if I have a problem sending a message I go to the menus: Tools/Network Log and have a look at exactly what was sent over the wire. If necessary i restart the program from the command-line and increase logging further. No need to go to any system logs and no problem if they're missing.

Well, there is a difference: my MUAs hand over the email to postfix for sending. This was a necessity long ago, because I used Alpine as MUA. Now it is a preference.

What has that got to do with mail.{info,err,notice} ?

I needed to know what was going on with the mail I produced, see the possible problems and act on them. Ie, check the logs, either as routine, or in retrospect. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

Dave Howorth wrote:

I'm with Per here. There's no way a developer will see any messages on your systems, so either the messages are wrongly classified or configured in the application or they aren't debugging messages.

Thanks, I was beginning to feel a bit lonely :-) This week I've been working on a small proxy daemon for nginx, hopefully it will reduce the memory footprint on mailman3. It writes some warnings - message( 0, "Unable to allocate %luMb for map", message( 0, "something went wrong, %s could not be loaded", mapfile ); message( 0, "map loaded, %u invalid entries", inv ); message( 0, "getaddrinfo(%s) failed: error %d: %s\n", hostname, rc, gai_strerror(rc) ); message( 0, "socket() failed: error %d: %s\n", errno, strerror(errno) ); message( 0, "bind() failed: error %d: %s\n", errno, strerror(errno) ); message( 0, "listen() failed: error %d: %s\n", errno, strerror(errno) ); message( 0, "select() failed: error %d; %s", errno, strerror(errno) ); Of course it has some debugging output too, which will remain enabled until I deploy it in production.

...

...

We remove mail.{info,err,notice} on all machines, and I only have one single machine that has any use for news.{crit,err,notice} - our news-server.

I can understand removing news logs if there is no news handling in a machine, but all my machines send email. If there is a problem and the log is disabled, it would be a disaster.

I don't know about your MUA but in mine (Claws) if I have a problem sending a message I go to the menus: Tools/Network Log and have a look at exactly what was sent over the wire. If necessary i restart the program from the command-line and increase logging further. No need to go to any system logs and no problem if they're missing.

Even on the rare occasion, /var/log/mail would still be there. Not having it would certainly be annoying, but hardly a disaster. -- Per Jessen, Zürich (2.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2023-03-11 at 13:10 +0100, Per Jessen wrote:

Per Jessen wrote:

...

This week I've been working on a small proxy daemon for nginx, hopefully it will reduce the memory footprint on mailman3. It writes some warnings -

message( 0, "Unable to allocate %luMb for map", message( 0, "something went wrong, %s could not be loaded", mapfile ); message( 0, "map loaded, %u invalid entries", inv ); message( 0, "getaddrinfo(%s) failed: error %d: %s\n", hostname, rc, gai_strerror(rc) ); message( 0, "socket() failed: error %d: %s\n", errno, strerror(errno) ); message( 0, "bind() failed: error %d: %s\n", errno, strerror(errno) ); message( 0, "listen() failed: error %d: %s\n", errno, strerror(errno) ); message( 0, "select() failed: error %d; %s", errno, strerror(errno) );

So Carlos, with your built-in sense for what is debug, warning and error - how would you deal with the above?

Anything worth reporting to the developer?

They don't seem to me entries from the /var/log/warn file, and I'm not familiar with that tool. They seem to me cryptic debug messages intended to be understood only by the programmer, so they should not be written to "/var/log/warn" file. If I find those things in MY "/var/log/warn" file, I might write a bugzilla so that they are sent elsewhere. And/Or, I might write a filter to rsyslog to delete them from "/var/log/warn". I have many already. - -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZBYm4xwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfV2AAAoIt17gh5MxO7l5ucgu+U no3p3VOrAJwOoUyBVeyr8tMPXqCV4Vpl3hhYXQ== =nvvm -----END PGP SIGNATURE-----

On Fri, 10 Mar 2023 14:18:42 +0100, Per Jessen wrote:

Wednesday last week, radio SRF1 spent an entire afternoon celebrating the 50th anniversary of the release of "Dark Side of the Moon".  I guess that might be noise to some philis .... people.

Mmmm, laser light show, powerful brownies, people like aliens. -- Robert Webb

On Fri, 10 Mar 2023 21:47:32 -0600, J Leslie Turriff wrote:

    I don't know about /var/log/warn, but a similar thing that bugs me is the noise that comes out of GUI programs that I start from the command line.  Just about every one of them writes junk on the terminal, sometimes just because I'm scrolling a window(!)  For the ones I use a lot I've written wrappers that consign stderr to /dev/null (which of course is dangerous because it also suppresses valid error messages.

No kidding.  I have this problem running GUI programs remotely.  Carlos is not going to like my solution.  I just say, "Let them spam the logs, instead of my terminal!"  Here are the last two lines of my script:   #ssh -X "$DEST_SPEC" "$1"' >/dev/null 2>&1'   ssh -X "$DEST_SPEC" systemd-cat -t "$Cmd" -- "$@" & You can see from the commented-out line, I was doing something similar before deciding to send the abuse to the logs.  'systemd-cat' captures both stdout and stderr.  I'm a happy camper now.  (Let's have a special mention for gwenview here.) -- Robert Webb

On Sat, 11 Mar 2023 11:54:54 +0100, "Carlos E. R." wrote:

On 2023-03-11 06:02, Robert Webb wrote:

...

On Fri, 10 Mar 2023 21:47:32 -0600, J Leslie Turriff wrote:

...

      I don't know about /var/log/warn, but a similar thing that bugs me is the noise that comes out of GUI programs that I start from the command line.  Just about every one of them writes junk on the terminal, sometimes just because I'm scrolling a window(!)  For the ones I use a lot I've written wrappers that consign stderr to /dev/null (which of course is dangerous because it also suppresses valid error messages.

I don't care about those, as I dedicate a separate terminal for those programs.

...

No kidding.  I have this problem running GUI programs remotely.  Carlos is not going to like my solution.  I just say, "Let them spam the logs, instead of my terminal!"  Here are the last two lines of my script:

    #ssh -X "$DEST_SPEC" "$1"' >/dev/null 2>&1'     ssh -X "$DEST_SPEC" systemd-cat -t "$Cmd" -- "$@" &

You can see from the commented-out line, I was doing something similar before deciding to send the abuse to the logs.  'systemd-cat' captures both stdout and stderr.  I'm a happy camper now.  (Let's have a special mention for gwenview here.)

I'm not familiar with that program and syntax, but as long as you don't spam the warning long, I'm fine.

Doesn't systemd-cat need a '|'?

It can run either way, accepting input from a pipe, or running a program as a wrapper, capturing stdout and stderr.

You can make use of "--priority=...". Default is "info", which is fine.

I would have preferred setting different priorities for stdout and stderr, but then ordering of message lines can get messed up.

Interestingly, the program is missing "--facility=..."

But there is "--identifier=..." (-t), which can be used to filter messages. -- Robert Webb