Loading ...
Sorry, an error occurred while loading the content.

Re[6]: qmgr ignoring syslog_facility?

Expand Messages
  • Dietmar Braun
    ... As I wrote in my initial posting, here they are: arath:/var/log/mail# more /var/log/mail/postfix Jun 2 12:31:54 arath postfix/qmgr[22691]: 1B28611E538:
    Message 1 of 20 , Jun 2, 2008
    • 0 Attachment
      Monday, June 2, 2008, 4:24:04 PM, you wrote:
      > What messages is the OP seeing reported to the default location?

      As I wrote in my initial posting, here they are:

      arath:/var/log/mail# more /var/log/mail/postfix
      Jun 2 12:31:54 arath postfix/qmgr[22691]: 1B28611E538: from=<dbraun@...>, size=5469, nrcpt=1 (queue active)
      Jun 2 12:31:54 arath postfix/qmgr[22691]: 2240511E539: from=<dbraun@...>, size=15738, nrcpt=1 (queue active)
      Jun 2 12:31:54 arath postfix/qmgr[22691]: 1B28611E538: removed
      Jun 2 12:31:54 arath postfix/qmgr[22691]: 31E8911E538: from=<dbraun@...>, size=5156, nrcpt=1 (queue active)
      Jun 2 12:31:54 arath postfix/qmgr[22691]: 40A8111E53A: from=<dbraun@...>, size=44438, nrcpt=1 (queue active)
      Jun 2 12:31:54 arath postfix/qmgr[22691]: 4664C11E53B: from=<dbraun@...>, size=2660, nrcpt=1 (queue active)
      Jun 2 12:31:54 arath postfix/qmgr[22691]: 4C39911E53C: from=<dbraun@...>, size=8703, nrcpt=1 (queue active)
      Jun 2 12:31:54 arath postfix/qmgr[22691]: 530C711E53D: from=<dbraun@...>, size=26249, nrcpt=1 (queue active)
      Jun 2 12:31:54 arath postfix/qmgr[22691]: 4664C11E53B: removed
      Jun 2 12:31:54 arath postfix/qmgr[22691]: 40A8111E53A: removed
      Jun 2 12:31:54 arath postfix/qmgr[22691]: 530C711E53D: removed
      Jun 2 12:31:54 arath postfix/qmgr[22691]: 6AADB11E53A: from=<dbraun@...>, size=46161, nrcpt=1 (queue active)
      Jun 2 12:31:54 arath postfix/qmgr[22691]: 2240511E539: removed
      Jun 2 12:31:54 arath postfix/qmgr[22691]: 7935411E539: from=<dbraun@...>, size=4497, nrcpt=1 (queue active)
      Jun 2 12:31:54 arath postfix/qmgr[22691]: 31E8911E538: removed
      Jun 2 12:31:54 arath postfix/qmgr[22691]: 4C39911E53C: removed
      Jun 2 12:31:54 arath postfix/qmgr[22691]: 6AADB11E53A: removed
      Jun 2 12:31:54 arath postfix/qmgr[22691]: 86DD211E538: from=<dbraun@...>, size=4426, nrcpt=1 (queue active)
      Jun 2 12:31:54 arath postfix/qmgr[22691]: 7935411E539: removed
      Jun 2 12:31:54 arath postfix/qmgr[22691]: 86DD211E538: removed


      --
      NetCologne Gesellschaft fuer Telekommunikation mbH
      Am Coloneum 9, 50829 Koeln
      Geschaeftsfuehrer: Werner Hanf, Dipl.-Ing. Karl-Heinz Zankel
      HRB 25580, AG Koeln
    • Dietmar Braun
      ... Thanks a lot! Dietmar -- NetCologne Gesellschaft fuer Telekommunikation mbH Am Coloneum 9, 50829 Koeln Geschaeftsfuehrer: Werner Hanf, Dipl.-Ing.
      Message 2 of 20 , Jun 2, 2008
      • 0 Attachment
        Monday, June 2, 2008, 4:14:59 PM, you wrote:
        > Fixed in the next release...

        Thanks a lot!

        Dietmar

        --
        NetCologne Gesellschaft fuer Telekommunikation mbH
        Am Coloneum 9, 50829 Koeln
        Geschaeftsfuehrer: Werner Hanf, Dipl.-Ing. Karl-Heinz Zankel
        HRB 25580, AG Koeln
      • Wietse Venema
        ... Actually, the syslog_facility feature got broken when I implemented the above fix for syslog_name. Wietse
        Message 3 of 20 , Jun 2, 2008
        • 0 Attachment
          Wietse Venema:
          > Wietse Venema:
          > > Dietmar Braun:
          > > > Monday, June 2, 2008, 3:54:23 PM, you wrote:
          > > > > Before the fix below, changing the name/level required "postfix stop"
          > > > > and "postfix start" for daemon processes.
          > > >
          > > > > 20070223
          > > >
          > > > > Cleanup: syslog_name now works as documented with both
          > > > > daemons and commands (including set-gid commands). Files:
          > > > > global/mail_task.c postlog/postlog.c, global/mail_version.h,
          > > > > sendmail/sendmail.c, postsuper/postsuper.c, postalias/postalias.c,
          > > > > postmap/postmap.c, postqueue/postqueue.c, postdrop/postdrop.c,
          > > > > master/trigger_server.c, master/single_server.c,
          > > > > master/multi_server.c.
          > > >
          > > > arath:/var/log/mail# postconf | grep mail_version
          > > > mail_version = 2.5.2
          > > >
          > > > Hm, I suppose my quite "fresh" postfix should have that? ;)
          > >
          > > Apparently, that fixes changes in syslog_name, but not changes in
          > > syslog_facility. I'll put that on the TODO list.
          >
          > All msg_syslog_init() calls have fixed parameters, so it seems that
          > the syslog_facility parameter implementation was not completed
          > after the main.cf parameter was defined.

          Actually, the syslog_facility feature got broken when I implemented
          the above fix for syslog_name.

          Wietse
        • Victor Duchovni
          ... Only in the case that master.cf contains -o syslog_name=... overrides, right? ... mail_params_init(); if (redo_syslog_init)
          Message 4 of 20 , Jun 2, 2008
          • 0 Attachment
            On Mon, Jun 02, 2008 at 10:49:40AM -0400, Wietse Venema wrote:

            > > > Apparently, that fixes changes in syslog_name, but not changes in
            > > > syslog_facility. I'll put that on the TODO list.
            > >
            > > All msg_syslog_init() calls have fixed parameters, so it seems that
            > > the syslog_facility parameter implementation was not completed
            > > after the main.cf parameter was defined.
            >
            > Actually, the syslog_facility feature got broken when I implemented
            > the above fix for syslog_name.


            Only in the case that master.cf contains "-o syslog_name=..." overrides, right?

            ...

            mail_params_init();
            if (redo_syslog_init)
            msg_syslog_init(mail_task(var_procname), LOG_PID, LOG_FACILITY);
            ^^^^^^^^^^^^
            should be var_syslog_facility?

            ...

            case 'o':
            /* XXX Use split_nameval() */
            if ((oval = split_at(optarg, '=')) == 0)
            oval = "";
            mail_conf_update(optarg, oval);
            if (strcmp(optarg, VAR_SYSLOG_NAME) == 0)
            redo_syslog_init = 1;
            break;

            ...

            --
            Viktor.

            Disclaimer: off-list followups get on-list replies or get ignored.
            Please do not ignore the "Reply-To" header.

            To unsubscribe from the postfix-users list, visit
            http://www.postfix.org/lists.html or click the link below:
            <mailto:majordomo@...?body=unsubscribe%20postfix-users>

            If my response solves your problem, the best way to thank me is to not
            send an "it worked, thanks" follow-up. If you must respond, please put
            "It worked, thanks" in the "Subject" so I can delete these quickly.
          • Wietse Venema
            ... A bug is a bug, even if it triggers only sometimes. The redo_syslog_init branch clobbers the syslog_facility. However, LOG_FACILITY is an int, while
            Message 5 of 20 , Jun 2, 2008
            • 0 Attachment
              Victor Duchovni:
              > On Mon, Jun 02, 2008 at 10:49:40AM -0400, Wietse Venema wrote:
              >
              > > > > Apparently, that fixes changes in syslog_name, but not changes in
              > > > > syslog_facility. I'll put that on the TODO list.
              > > >
              > > > All msg_syslog_init() calls have fixed parameters, so it seems that
              > > > the syslog_facility parameter implementation was not completed
              > > > after the main.cf parameter was defined.
              > >
              > > Actually, the syslog_facility feature got broken when I implemented
              > > the above fix for syslog_name.
              >
              >
              > Only in the case that master.cf contains "-o syslog_name=..." overrides, right?
              >
              > ...
              >
              > mail_params_init();
              > if (redo_syslog_init)
              > msg_syslog_init(mail_task(var_procname), LOG_PID, LOG_FACILITY);
              > ^^^^^^^^^^^^
              > should be var_syslog_facility?

              A bug is a bug, even if it triggers only sometimes.

              The redo_syslog_init branch clobbers the syslog_facility. However,
              LOG_FACILITY is an int, while var_syslog_facility is a string.
              The msg_syslog(3) API needs to be revised so that name and facility
              can be updated more easily.

              Wietse
            • Victor Duchovni
              ... I am also not sure about when/how the explicit syslog_facility is used. It seems that it is passed with each call to msg_syslog(): static void
              Message 6 of 20 , Jun 2, 2008
              • 0 Attachment
                On Mon, Jun 02, 2008 at 12:45:51PM -0400, Wietse Venema wrote:

                > > Only in the case that master.cf contains "-o syslog_name=..." overrides, right?
                > >
                > > ...
                > >
                > > mail_params_init();
                > > if (redo_syslog_init)
                > > msg_syslog_init(mail_task(var_procname), LOG_PID, LOG_FACILITY);
                > > ^^^^^^^^^^^^
                > > should be var_syslog_facility?
                >
                > A bug is a bug, even if it triggers only sometimes.
                >
                > The redo_syslog_init branch clobbers the syslog_facility. However,
                > LOG_FACILITY is an int, while var_syslog_facility is a string.
                > The msg_syslog(3) API needs to be revised so that name and facility
                > can be updated more easily.

                I am also not sure about when/how the explicit syslog_facility is used. It seems
                that it is passed with each call to msg_syslog():

                static void msg_syslog_print(int level, const char *text)
                {
                static int log_level[] = {
                LOG_INFO, LOG_WARNING, LOG_ERR, LOG_CRIT, LOG_CRIT,
                };
                static char *severity_name[] = {
                "info", "warning", "error", "fatal", "panic",
                };

                if (level < 0 || level >= (int) (sizeof(log_level) / sizeof(log_level[0])))
                msg_panic("msg_syslog_print: invalid severity level: %d", level);

                if (level == MSG_INFO) {
                syslog(syslog_facility | log_level[level], "%.*s",
                (int) MSG_SYSLOG_RECLEN, text);
                } else {
                syslog(syslog_facility | log_level[level], "%s: %.*s",
                severity_name[level], (int) MSG_SYSLOG_RECLEN, text);
                }
                }

                So does it in fact matter what facility is passed to the second openlog()?

                --
                Viktor.

                Disclaimer: off-list followups get on-list replies or get ignored.
                Please do not ignore the "Reply-To" header.

                To unsubscribe from the postfix-users list, visit
                http://www.postfix.org/lists.html or click the link below:
                <mailto:majordomo@...?body=unsubscribe%20postfix-users>

                If my response solves your problem, the best way to thank me is to not
                send an "it worked, thanks" follow-up. If you must respond, please put
                "It worked, thanks" in the "Subject" so I can delete these quickly.
              • Wietse Venema
                ... No, but the whole discussion shows that syslog_name/facility support is poorly structured and that it needs to be cleaned up. This code is no longer
                Message 7 of 20 , Jun 2, 2008
                • 0 Attachment
                  Victor Duchovni:
                  > So does it in fact matter what facility is passed to the second openlog()?

                  No, but the whole discussion shows that syslog_name/facility support
                  is poorly structured and that it needs to be cleaned up. This code
                  is no longer "obviously correct".

                  Wietse
                Your message has been successfully submitted and would be delivered to recipients shortly.