Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-20344

startup messages belong in stderr/error-log not stdout

Details

    Description

      this annoying message don't belog to stdout and i have pointed this out years ago on the mailing list after the update which introduced it with a heatet discussion because most people spoke up didn't gasp what i am talking about

      we have maraidb logfiles and so there is no point to spit out anything ond stdout which on other init systems won't be seen at all

      Aug 14 04:02:41 backup-dbmail systemd[1]: Stopping MariaDB Replication...
      Aug 14 04:02:43 backup-dbmail systemd[1]: Stopped MariaDB Replication.
      Aug 14 04:10:18 backup-dbmail systemd[1]: Starting MariaDB Replication...
      Aug 14 04:10:18 backup-dbmail mysqld[496132]: 2019-08-14 4:10:18 140369542626816 [Note] /usr/libexec/mysqld (mysqld 10.2.26-MariaDB) starting as process 496132 ...
      Aug 14 04:10:20 backup-dbmail systemd[1]: Started MariaDB Replication.

      Attachments

        Issue Links

          Activity

            I'd say it's questionable whether it's a bug. The message is printed as soon as the server executable is started, before command line options are parsed. So it cannot possibly go into the error log.

            The only way to fix it is to stop printing an early "starting" message altogether. I don't really know how many users rely on it, so I cannot say if it's safe to remove.

            Given the risk, I tend to think that it's far safer to redirect stderr to /dev/null if needed, intead of removing this early message for everyone.

            serg Sergei Golubchik added a comment - I'd say it's questionable whether it's a bug. The message is printed as soon as the server executable is started, before command line options are parsed. So it cannot possibly go into the error log. The only way to fix it is to stop printing an early "starting" message altogether. I don't really know how many users rely on it, so I cannot say if it's safe to remove. Given the risk, I tend to think that it's far safer to redirect stderr to /dev/null if needed, intead of removing this early message for everyone.
            hreindl Reindl Harald added a comment -

            > I tend to think that it's far safer to redirect stderr to /dev/null if needed

            nobody right in his mind redirects stderr to /dev/null and nobody needs that message at all, systemd tells you the processid anyways and for the rare systems which still use initscripts that message wasn't there all the years

            hreindl Reindl Harald added a comment - > I tend to think that it's far safer to redirect stderr to /dev/null if needed nobody right in his mind redirects stderr to /dev/null and nobody needs that message at all, systemd tells you the processid anyways and for the rare systems which still use initscripts that message wasn't there all the years
            hreindl Reindl Harald added a comment -

            > [Note] /usr/libexec/mysqld (mysqld 10.2.26-MariaDB) starting as process 496132

            BTW: next time you design something like that do it with using your brain and don't spit a variable version number in the middle so that you can't write a proper rsyslog filter

            "/usr/libexec/mysqld starting as process 496132" would have been enough, i know which versions are installed and if i don't know it's time top get back control

            hreindl Reindl Harald added a comment - > [Note] /usr/libexec/mysqld (mysqld 10.2.26-MariaDB) starting as process 496132 BTW: next time you design something like that do it with using your brain and don't spit a variable version number in the middle so that you can't write a proper rsyslog filter "/usr/libexec/mysqld starting as process 496132" would have been enough, i know which versions are installed and if i don't know it's time top get back control
            hreindl Reindl Harald added a comment - - edited

            in a sane world one could just log to syslog: MDEV-23555

            hreindl Reindl Harald added a comment - - edited in a sane world one could just log to syslog: MDEV-23555

            Ok, sorry. I stand corrected. I used to think this message is printed almost immediately on startup. Perhaps it was. But now it's printed after all options are parsed. At that point the configured error log destination is known and it surely should be able to use it.

            I'd even say that the intention was to print this line into the error log, not stderr. Last commit that touched it was "MDEV-9593 - Print the real version in the error log", so the intention clearly was to print it into the error log. Thus it's a bug.

            serg Sergei Golubchik added a comment - Ok, sorry. I stand corrected. I used to think this message is printed almost immediately on startup. Perhaps it was. But now it's printed after all options are parsed. At that point the configured error log destination is known and it surely should be able to use it. I'd even say that the intention was to print this line into the error log, not stderr. Last commit that touched it was " MDEV-9593 - Print the real version in the error log", so the intention clearly was to print it into the error log. Thus it's a bug.
            danblack Daniel Black added a comment - Corrected in https://github.com/MariaDB/server/pull/1979#issuecomment-1291460656

            OK to push

            sanja Oleksandr Byelkin added a comment - OK to push
            danblack Daniel Black added a comment -

            Thanks for the review sanja.

            Happy to have this fixed finally.

            danblack Daniel Black added a comment - Thanks for the review sanja . Happy to have this fixed finally.

            People

              danblack Daniel Black
              hreindl Reindl Harald
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.