[oS-en] [Rant] Why so many debug messages are going to the /var/log/warn log file?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Why so many debug messages are going to the /var/log/warn log file? 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? I don't care. The programmer might want to see it, but users have no need to see it. Yet it has priority 3. It should be a debug message. For the programmer. #define KERN_EMERG "<0>" /* system is unusable */ #define KERN_ALERT "<1>" /* action must be taken immediately */ #define KERN_CRIT "<2>" /* critical conditions */ #define KERN_ERR "<3>" /* error conditions */ #define KERN_WARNING "<4>" /* warning conditions */ #define KERN_NOTICE "<5>" /* normal but significant condition */ #define KERN_INFO "<6>" /* informational */ #define KERN_DEBUG "<7>" /* debug-level messages */ There are many more. <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 <1.4> 2023-03-09T23:22:05.421592+01:00 Telcontar tracker-extract 24950 - - Locale 'LANG' is not set, defaulting to C locale <1.4> 2023-03-09T23:22:43.379085+01:00 Telcontar tracker-extract 24973 - - Locale 'LANG' is not set, defaulting to C locale <1.4> 2023-03-09T23:23:08.342804+01:00 Telcontar tracker-extract 24991 - - Locale 'LANG' is not set, defaulting to C locale <1.4> 2023-03-09T23:25:31.775909+01:00 Telcontar tracker-extract 25112 - - Locale 'LANG' is not set, defaulting to C locale <1.4> 2023-03-09T23:26:15.878323+01:00 Telcontar tracker-extract 25144 - - Locale 'LANG' is not set, defaulting to C locale Why is that a warning, and spamming the WARNING log? <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" Ditto. 1.4> 2023-03-09T19:07:32.113665+01:00 Telcontar tumblerd 4988 - - Name org.freedesktop.thumbnails.Cache1 lost on the message dbus, exiting. <1.4> 2023-03-09T19:07:32.113782+01:00 Telcontar tumblerd 4988 - - Name org.freedesktop.thumbnails.Manager1 lost on the message dbus, exiting. <1.4> 2023-03-09T19:07:32.113857+01:00 Telcontar tumblerd 4988 - - Name org.freedesktop.thumbnails.Thumbnailer1 lost on the message dbus, exiting. There are so many messages going as WARNINGS that the truly important ones are ignored. Sometimes I write a rule on rsyslog to clear some, but there are so many! if $syslogfacility == 1 and $syslogseverity == 4 and $programname == 'tracker-extract' \ and $msg contains "Locale 'LANG' is not set, defaulting to C locale" \ then -/var/log/pruned.warn & stop Maybe I should filter out entire programs: if $syslogfacility == 1 and $syslogseverity == 4 and ($programname == 'tracker-extract' or $programname == 'kglobalaccel5' or $programname == 'tumblerd' or $programname == 'krusader') \ then -/var/log/pruned.warn & stop This is like shouting WOLF! every day. When the wolf comes, nobody listens. - -- Cheers Carlos E. R. (from 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZAphHRwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVZgAAoJMABOTAlYBMsczWniyX 0Y329uOeAJ9izLcUwLTMKE/KrerMkzRF/qPMBA== =OfdZ -----END PGP SIGNATURE-----
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.
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.
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.
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.
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.
<1.4> 2023-03-09T21:45:20.910119+01:00 Telcontar krusader 17147 - - QCoreApplication::applicationDirPath: Please instantiate the QApplication object first [snip]
See above.
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. To answer $SUBJ - they are not debug messages, they are reports of operational issues. -- Per Jessen, Zürich (7.6°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
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)
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?
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".
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.
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. -- Per Jessen, Zürich (10.8°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
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)
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.
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.
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.
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. -- 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.
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)
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.
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. -- Per Jessen, Zürich (10.1°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
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)
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??
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. -- Per Jessen, Zürich (7.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
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)
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. 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. -- Per Jessen, Zürich (1.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
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 Fri, 10 Mar 2023 20:49:45 +0100 "Carlos E. R." <robin.listas@telefonica.net> 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.
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 :)
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.
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 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.
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-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.
-- Cheers / Saludos,
Carlos E. R. (from 15.4 x86_64 at Telcontar)
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. Leslie -- Platform: Linux Distribution: openSUSE Leap 15.4 (x86_64)
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)
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.
My normal action when I see a warning message is dispatch a bug,
Why on earth would you do that? 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 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: 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: 2023-03-11T02:17:55.283468+00:00 anna postfix/smtp[31379]: warning: no MX host for jessen.ch has a valid address record 2023-03-11T01:29:42.339317+00:00 anna postfix/cleanup[23707]: warning: 5255D24040: message rejected: hopcount exceeded 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} ? -- Per Jessen, Zürich (2.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
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)
Carlos E. R. wrote:
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.
What error? We are talking about warnings, not errors. See what you wrote above.
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.
I'll leave it you to report this warning. It is just some arbitrary server offering deprecated ciphers not supported (by default) by the client.
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.
So you would report all of those? Wietse will be taken to hospital with laughter cramps. I am really struggling to understand why the xsane warning about missing data is any different to the postfix warning about missing data.
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.
Never mind - I guess you have some sort of aversion to using /var/log/mail ? -- Per Jessen, Zürich (3.9°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
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
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? -- Per Jessen, Zürich (4.5°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-----
Carlos E. R. wrote:
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.
Well, as I wrote "I've been working on a small proxy daemon for nginx", so you would not have seen any of those warnings in your logfile nor could you be familiar with that daemon :-)
They seem to me cryptic debug messages intended to be understood only by the programmer,
Actually, they are all reports of something have gone wrong, locally. Inability to allocate memory - local problem. Inability to load mapfile - local problem. Invalid entries in mapfile - local problem. Inability to resolve hostname - local problem. socket/bind/list/select - local problems. For instance, inability to create a socket could mean a lack of local file descriptors, or maybe some apparmor issue.
so they should not be written to "/var/log/warn" file.
Well, that is of course of up to your local syslog config, but as they are likely local problems, what do you suggest the programmer should do with them? If they are classed as debug, nobody will ever see them, and the dameon will fail without notice. -- Per Jessen, Zürich (12.8°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On Fri, 10 Mar 2023 14:18:42 +0100, Per Jessen <per@jessen.ch> 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 2023-03-09 16:43:40 Carlos E. R. wrote:
Why so many debug messages are going to the /var/log/warn log file?
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? I don't care. The programmer might want to see it, but users have no need to see it.
Yet it has priority 3. It should be a debug message. For the programmer.
#define KERN_EMERG "<0>" /* system is unusable */ #define KERN_ALERT "<1>" /* action must be taken immediately */ #define KERN_CRIT "<2>" /* critical conditions */ #define KERN_ERR "<3>" /* error conditions */ #define KERN_WARNING "<4>" /* warning conditions */ #define KERN_NOTICE "<5>" /* normal but significant condition */ #define KERN_INFO "<6>" /* informational */ #define KERN_DEBUG "<7>" /* debug-level messages */
There are many more.
<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 <1.4> 2023-03-09T23:22:05.421592+01:00 Telcontar tracker-extract 24950 - - Locale 'LANG' is not set, defaulting to C locale <1.4> 2023-03-09T23:22:43.379085+01:00 Telcontar tracker-extract 24973 - - Locale 'LANG' is not set, defaulting to C locale <1.4> 2023-03-09T23:23:08.342804+01:00 Telcontar tracker-extract 24991 - - Locale 'LANG' is not set, defaulting to C locale <1.4> 2023-03-09T23:25:31.775909+01:00 Telcontar tracker-extract 25112 - - Locale 'LANG' is not set, defaulting to C locale <1.4> 2023-03-09T23:26:15.878323+01:00 Telcontar tracker-extract 25144 - - Locale 'LANG' is not set, defaulting to C locale
Why is that a warning, and spamming the WARNING log?
<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"
Ditto.
1.4> 2023-03-09T19:07:32.113665+01:00 Telcontar tumblerd 4988 - - Name org.freedesktop.thumbnails.Cache1 lost on the message dbus, exiting. <1.4> 2023-03-09T19:07:32.113782+01:00 Telcontar tumblerd 4988 - - Name org.freedesktop.thumbnails.Manager1 lost on the message dbus, exiting. <1.4> 2023-03-09T19:07:32.113857+01:00 Telcontar tumblerd 4988 - - Name org.freedesktop.thumbnails.Thumbnailer1 lost on the message dbus, exiting.
There are so many messages going as WARNINGS that the truly important ones are ignored.
Sometimes I write a rule on rsyslog to clear some, but there are so many!
if $syslogfacility == 1 and $syslogseverity == 4 and $programname == 'tracker-extract' \ and $msg contains "Locale 'LANG' is not set, defaulting to C locale" \ then -/var/log/pruned.warn & stop
Maybe I should filter out entire programs:
if $syslogfacility == 1 and $syslogseverity == 4 and ($programname == 'tracker-extract' or $programname == 'kglobalaccel5' or $programname == 'tumblerd' or $programname == 'krusader') \ then -/var/log/pruned.warn & stop
This is like shouting WOLF! every day. When the wolf comes, nobody listens.
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. Leslie -- Platform: Linux Distribution: openSUSE Leap 15.4 (x86_64)
On Fri, 10 Mar 2023 21:47:32 -0600, J Leslie Turriff <jlturriff@mail.com> 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 2023-03-11 06:02, Robert Webb wrote:
On Fri, 10 Mar 2023 21:47:32 -0600, J Leslie Turriff <jlturriff@mail.com> 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 '|'? You can make use of "--priority=...". Default is "info", which is fine. Interestingly, the program is missing "--facility=..." -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Sat, 11 Mar 2023 11:54:54 +0100, "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2023-03-11 06:02, Robert Webb wrote:
On Fri, 10 Mar 2023 21:47:32 -0600, J Leslie Turriff <jlturriff@mail.com> 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
On 2023-03-11 14:22, Robert Webb wrote:
On Sat, 11 Mar 2023 11:54:54 +0100, "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2023-03-11 06:02, Robert Webb wrote:
On Fri, 10 Mar 2023 21:47:32 -0600, J Leslie Turriff <jlturriff@mail.com> 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.
If you set "--facility=local3", you can immediately drive all the local3 messages to a separate log file, fast, little processing. But you can't. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
participants (6)
-
Andrei Borzenkov -
Carlos E. R. -
Dave Howorth -
J Leslie Turriff -
Per Jessen -
Robert Webb