tickets #151222
openmail queue maintenance
0%
Description
I was working on anna and noticed some odd errors in the log. There 209 mails queued up, not in itself unusual.
Some of them are unusual or at least indicative of a poor mail config:
Queue id BD05620CAE:
From: "(Cron Daemon)" <root@monitor.infra.opensuse.org>
To: root@monitor.infra.opensuse.org
Subject: Cron <root@monitor> test -x /root/bin/create_contacts_icinga2.sh && /root/bin/create_contacts_icinga2.sh -c -q -r
Message-Id: <20231114030002.B0FB849B600@monitor.infra.opensuse.org>
Date: Tue, 14 Nov 2023 03:00:02 +0000 (UTC)
icinga2.service is not active, cannot reload.
Looks like maybe cron reports should be sent to admin-auto?
Queue id BA5A0244B6:
From: "(Cron Daemon)" <mirrorcache@mirrorcache-us-db.infra.opensuse.org>
To: mirrorcache@mirrorcache-us-db.infra.opensuse.org
Subject: Cron <mirrorcache@mirrorcache-us-db> /usr/share/mirrorcache/cron.sh
Message-Id: <20231120041501.CC88D6D1@mirrorcache-us-db.infra.opensuse.org>
Date: Mon, 20 Nov 2023 04:15:01 +0000 (UTC)
/bin/sh: /usr/share/mirrorcache/cron.sh: Permission denied
Looks like maybe cron reports should be sent to admin-auto?
Queue id B9EC924261:
From: "(Cron Daemon)" <root@status2.opensuse.org>
To: root@status2.opensuse.org
Subject: Cron <root@status2> test -x /root/bin/update_status.o.o.sh && /root/bin/update_status.o.o.sh >/dev/null
Message-Id: <20231111045218.4686675AC@status2.opensuse.org>
ping: software.opensuse.org: Temporary failure in name resolution
I presume this is some relatively innocent & temporary migration fall-out, but again, maybe cron-reports ought to go to admin-auto?
There were also a few bounces by 'smtp-in12.suse.de' due to unknown addresses: aduffeck@suse.de, coolo@suse.de, dmacvicar@suse.de. I have unsubscribed from the respective mailing lists.
Updated by pjessen 5 months ago
pjessen wrote:
There were also a few bounces by 'smtp-in12.suse.de' due to unknown addresses: aduffeck@suse.de, coolo@suse.de, dmacvicar@suse.de. I have unsubscribed from the respective mailing lists.
For the record -
kde.lists - aduffeck, dmacvicar unsubscribed.
ruby.lists - coolo, aduffeck, dmacvicar unsubscribed.
Updated by pjessen 5 months ago
crameleon wrote in #note-1:
Salt should deploy an /etc/aliases entry for root -> admin-auto. Maybe some machine's miss it or are not correctly configured to use the aliases file?
Looking at monitor.i.o.o -
monitor (heroes-bot, monitor.o.o, syslog.i.o.o):~ # grep ^root /etc/aliases
root: admin-auto@opensuse.org
The postfix config also looks good. However:
2023-11-21T03:00:03.338762+00:00 monitor postfix/pickup[28279]: 528854DAC4F: uid=0 from=<root>
2023-11-21T03:00:03.347288+00:00 monitor postfix/cleanup[29547]: 528854DAC4F: message-id=<20231121030003.528854DAC4F@monitor.infra.opensuse.org>
2023-11-21T03:00:03.348870+00:00 monitor postfix/qmgr[1486]: 528854DAC4F: from=<root@monitor.infra.opensuse.org>, size=917, nrcpt=1 (queue active)
2023-11-21T03:00:03.398984+00:00 monitor postfix/smtp[29549]: 528854DAC4F: to=<root@monitor.infra.opensuse.org>, orig_to=<root>, relay=relay.infra.opensuse.org[2a07:de40:b27e:64::c0a8:2f04]:25, delay=0.07, delays=0.02/0.01/0.02/0.02, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 5DDC11F9D3)
2023-11-21T03:00:03.399100+00:00 monitor postfix/qmgr[1486]: 528854DAC4F: removed
That one is currently stuck on anna 😁
Updated by pjessen 5 months ago
For monitor.i.o.o, I think the issue is as follows:
/etc/aliases only apply to local deliveries. However, postfix/main.cf has mydestination= which overrides the default mydestination = $myhostname, localhost.$mydomain, localhost.
Also, postfix/master.cf has the local transport commented out #local unix - n n - - local
I have made the following changes:
- main.cf: comment out
mydestination=to just leave the default. - master.cf: uncomment the local transport
The previous setup was clearly intentional, but as I am not familiar with monitor.i.o.o, someone really ought to review the setup and my proposed changes above.