Hide Forgot
Description of problem: Just rebooted my laptop after apply today updates and loking across ystem logs for all warnings and errors I fond the line: Aug 22 07:06:36 domek smartd[858]: Warning via /usr/libexec/smartmontools/smartdnotify to root: successful As long as it is sucessfull operation loos like this should not be logged. Version-Release number of selected component (if applicable): $ rpm -qf /usr/sbin/smartd smartmontools-6.5-1.fc25.x86_64
This is not an error message. You can verify it by journalctl: $ journalctl -o verbose and look for the message, it will have PRIORITY=6 which means "info". If you want to see only warning (or more important messages), you can use $ journalctl -p warning
I did not wrote that it has been logged any kind of error. I've createt this ticket because logging success as warning is unusuall. It it would be a normal thing we will have more sucesses logged as warnings. Isn't it? Simple this should be not logged that way. Many people after boot are trying to check system logs looking for any traces of errors or warnings. This message is simple misleading. As long as it is not logged any error it is an error logging it that way.
1)it's a "info" level syslog message, so no warning 2)it's not "warning: something succeeded", but "sending warning message to user succeeded" so, still not a bug
Can you answer on question how many log entries logged on info level are logged with "warning" in logged message? I know that it is not a bug logged by application. Neither it is NOT a WARNING. Isn't it? If it is not warning why application log this sucess witch "warning" word in info level message? Application needs to be corrected to not deliver ,misleading log entries. If it is success and if it needs to be logged ("why success needs to be logged?" it is another question) it shod be logged with proper message not containing words like "warning".
Please before you will close this ticket please try to answer on at least one of my question.
(In reply to Tomasz Kłoczko from comment #4) > Can you answer on question how many log entries logged on info level are > logged with "warning" in logged message? Read previous comments again. This message is not a warning. It's an information that "warning was sent". This means that word "warning" is important, because it exactly describes what happened. > I know that it is not a bug logged by application. Neither it is NOT a > WARNING. Isn't it? It's informational message > If it is not warning why application log this sucess witch "warning" word in > info level message? same as first answer - because that message describes information - action, what application did > Application needs to be corrected to not deliver > ,misleading log entries. It's not misleading. You are asking something like that if application opens some file, that it should not use word "open" in it's debug log. warning it sent, so "warning" word is in the "what it did" message > If it is success and if it needs to be logged ("why success needs to be > logged?" it is another question) it shod be logged with proper message not > containing words like "warning". "info" level message means what application does, it's close to debug messages. If you don't want to see them, use $ journalctl -p warning as I've already told you. I hope I explained it enough again. Even if you still do not agree or understand, do NOT reopen this bug, because this is NOT A BUG and my opinion will not change. Thank you
> It's not misleading. How many other logged info level log entries you saw with "warning" word wtin it? AFAIK it is ONLY example. You are completly ignoring the fact tat NONE other info level notifications in whoe distribution is logged with message containing "warning" word. Even you constantly repeat that this message does not logs warning. If you can agree with your own conclusion please accept consequence of this conclusion that this misleading message needs to be change or it is incorrect log level/severity of logged message (it is some non-zero possibility that it may be something wrong here as well .. someone need to check source code to confirm this as well).
Tomasz, by reopening the bugzilla you are not doing the right thing. If you don't believe Michal is right with not a bug resolution, please bring this on the community mailing list - devel.org . In my opinion, it is not a bug. As Michal stated before , it is not a warning. It is an information saying "Warning sent succesfully". Consider potential info message: "INFO: Error message logged in /var/log/foobar" - I think there are several such info level/debug level messages in the distribution. I partially agree having prefix "INFO:" would make things more clear, however, it is probably upstream decision - and I don't think such change should be done as distribution downstream patch. Please do not reopen the bugzilla again, instead move the discussion to mailing list - or to smartmontools upstream ( https://www.smartmontools.org/query?milestone=Release+6.5 ) - where you can more likely get this message changed to more clear format. With constant reopening without further arguments, you may get your bugzilla account blocked by Fedora infrastructure engineers - please read bugzilla etiquette - https://bugzilla.mozilla.org/page.cgi?id=etiquette.html . Point 2.2 says: "No whining about decisions. If a respected project contributor has marked a bug as INVALID, then it is invalid. Someone filing another duplicate of it does not change this. Unless you have further important evidence, do not post a comment arguing that an INVALID or WONTFIX bug should be reopened."
I give up. I cannot discuss with people who do not accepting what they are saying that it is not a warning message and ignoring this that ***it looks like warning*** because it is logged with "warning" within it. I'm working in company where logs are regularly checked for all entries logged with "error" or "warning" words because many software maintainers does not care about what and how they are logging events so relaying on syslog or systemd journal is never working well. I know that in many places people are doing exactly the same things. If you don't believe that it does not work just one example: [root@domek tkloczko]# for j in success info error warning critical alert emergency ; do for i in emerg alert crit err warning notice info debug; do echo -n "$j in messages on level $i: "; journalctl -x -p $i| grep -wi $j|wc -l;done; done debug in messages on level emerg: 0 debug in messages on level alert: 0 debug in messages on level crit: 0 debug in messages on level err: 2 debug in messages on level warning: 57 debug in messages on level notice: 85 debug in messages on level info: 699 debug in messages on level debug: 704 success in messages on level emerg: 0 success in messages on level alert: 0 success in messages on level crit: 0 success in messages on level err: 0 success in messages on level warning: 1 success in messages on level notice: 1107 success in messages on level info: 1656 success in messages on level debug: 79110 info in messages on level emerg: 0 info in messages on level alert: 0 info in messages on level crit: 0 info in messages on level err: 3 info in messages on level warning: 64 info in messages on level notice: 64 info in messages on level info: 3938 info in messages on level debug: 4028 error in messages on level emerg: 0 error in messages on level alert: 18 error in messages on level crit: 31 error in messages on level err: 117 error in messages on level warning: 4672 error in messages on level notice: 4750 error in messages on level info: 28734 error in messages on level debug: 321598 warning in messages on level emerg: 0 warning in messages on level alert: 0 warning in messages on level crit: 0 warning in messages on level err: 0 warning in messages on level warning: 41633 warning in messages on level notice: 41633 warning in messages on level info: 72039 warning in messages on level debug: 74142 critical in messages on level emerg: 0 critical in messages on level alert: 0 critical in messages on level crit: 68 critical in messages on level err: 68 critical in messages on level warning: 728 critical in messages on level notice: 728 critical in messages on level info: 864 critical in messages on level debug: 872 alert in messages on level emerg: 0 alert in messages on level alert: 0 alert in messages on level crit: 0 alert in messages on level err: 0 alert in messages on level warning: 0 alert in messages on level notice: 0 alert in messages on level info: 0 alert in messages on level debug: 0 emergency in messages on level emerg: 0 emergency in messages on level alert: 0 emergency in messages on level crit: 0 emergency in messages on level err: 0 emergency in messages on level warning: 0 emergency in messages on level notice: 0 emergency in messages on level info: 0 emergency in messages on level debug: 56 So as you see there are on Linux some emergency debug messages. Thre are some number of I remember opening similar cases in last couple of years about logged messages in dist software available in Solaris. Such cases been accepted and messages has been fixed without discussion. Solaris has very strict rules about kernel and application layer log messages. Those rules are so strict that writing alarming scripts it is incredibly easy thing. In case of Linux even catching some traces of incorrectness in emitted from kernel it is rocket science and never ending story. Devil always sits in details, and as you guys don't care about details I'm accepting this.