warning: database postfix_domains.db is older than source file postfix_domains
Hi,
I frequently get this warning mail.log. stat'ing the files give:
# stat /opt/mailman/var/data/postfix_domains File: /opt/mailman/var/data/postfix_domains Size: 361 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 1573095 Links: 1 Access: (0660/-rw-rw----) Uid: ( 1004/ mailman) Gid: ( 1002/ mailman) Access: 2020-10-24 19:52:16.887258326 +0200 Modify: 2020-10-20 07:09:48.792000000 +0200 Change: 2020-10-20 07:09:48.792000000 +0200 Birth: - # stat /opt/mailman/var/data/postfix_domains.db File: /opt/mailman/var/data/postfix_domains.db Size: 12288 Blocks: 24 IO Block: 4096 regular file Device: 801h/2049d Inode: 1583965 Links: 1 Access: (0640/-rw-r-----) Uid: ( 1004/ mailman) Gid: ( 1002/ mailman) Access: 2020-10-26 07:46:54.569935782 +0100 Modify: 2020-10-20 07:09:47.575889000 +0200 Change: 2020-10-20 07:09:47.575889000 +0200 Birth: -
I do not have the feeling that this is really a problem, cause everything works well. But it is confusing and misleading and might makes me missing a problem in the future, when the database is really outdated.
Could this be easily fixed in mailman?
It's mailman core 3.3.1.
Kind regards Torge
On 10/26/20 10:07 AM, Torge Riedel wrote:
Hi,
I frequently get this warning mail.log. stat'ing the files give:
# stat /opt/mailman/var/data/postfix_domains File: /opt/mailman/var/data/postfix_domains Size: 361 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 1573095 Links: 1 Access: (0660/-rw-rw----) Uid: ( 1004/ mailman) Gid: ( 1002/ mailman) Access: 2020-10-24 19:52:16.887258326 +0200 Modify: 2020-10-20 07:09:48.792000000 +0200 Change: 2020-10-20 07:09:48.792000000 +0200 Birth: - # stat /opt/mailman/var/data/postfix_domains.db File: /opt/mailman/var/data/postfix_domains.db Size: 12288 Blocks: 24 IO Block: 4096 regular file Device: 801h/2049d Inode: 1583965 Links: 1 Access: (0640/-rw-r-----) Uid: ( 1004/ mailman) Gid: ( 1002/ mailman) Access: 2020-10-26 07:46:54.569935782 +0100 Modify: 2020-10-20 07:09:47.575889000 +0200 Change: 2020-10-20 07:09:47.575889000 +0200 Birth: -
I don't understand how this is happening. With defaults for mailman.cfg settings you should have in the [mta] section
configuration: python:mailman.config.postfix
which points to the file mailman/config.postfix.py in the installation which has in its [postfix] section
postmap_command: /usr/sbin/postmap
These settings say whenever mailman updates
/opt/mailman/var/data/postfix_domains
, it runs /usr/sbin/postmap
/opt/mailman/var/data/postfix_domainsto update
/opt/mailman/var/data/postfix_domains.db. These files,
postfix_domainsand
postfix_lmtp`should be written and closed before
invoking the posymap command, so Y don't understand why the
modify/change times on the .db files would be 1.22 seconds earlier than
those on the source.
I do not have the feeling that this is really a problem, cause everything works well. But it is confusing and misleading and might makes me missing a problem in the future, when the database is really outdated.
Could this be easily fixed in mailman?
I don't think it's a Mailman issue. For example on the server that supports this list I see
$ stat /opt/mailman/mm/var/data/postfix_* File: ‘/opt/mailman/mm/var/data/postfix_domains’ Size: 391 Blocks: 8 IO Block: 4096 regular file Device: ca11h/51729d Inode: 5113910 Links: 1 Access: (0660/-rw-rw----) Uid: ( 110/ mailman) Gid: ( 118/ mailman) Access: 2020-10-24 19:30:44.787818101 +0000 Modify: 2020-10-24 19:30:44.731817318 +0000 Change: 2020-10-24 19:30:44.731817318 +0000 Birth: - File: ‘/opt/mailman/mm/var/data/postfix_domains.db’ Size: 12288 Blocks: 24 IO Block: 4096 regular file Device: ca11h/51729d Inode: 5112421 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 110/ mailman) Gid: ( 118/ mailman) Access: 2020-10-26 19:39:45.452615116 +0000 Modify: 2020-10-24 19:30:44.787818101 +0000 Change: 2020-10-24 19:30:44.787818101 +0000 Birth: - File: ‘/opt/mailman/mm/var/data/postfix_lmtp’ Size: 3465 Blocks: 8 IO Block: 4096 regular file Device: ca11h/51729d Inode: 5113909 Links: 1 Access: (0660/-rw-rw----) Uid: ( 110/ mailman) Gid: ( 118/ mailman) Access: 2020-10-24 19:30:44.775817934 +0000 Modify: 2020-10-24 19:30:44.719817150 +0000 Change: 2020-10-24 19:30:44.719817150 +0000 Birth: - File: ‘/opt/mailman/mm/var/data/postfix_lmtp.db’ Size: 12288 Blocks: 24 IO Block: 4096 regular file Device: ca11h/51729d Inode: 5112424 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 110/ mailman) Gid: ( 118/ mailman) Access: 2020-10-26 19:40:38.509356931 +0000 Modify: 2020-10-24 19:30:44.775817934 +0000 Change: 2020-10-24 19:30:44.775817934 +0000 Birth: -
Which is what I expect.
Note that the only times both the postfix_domains
and postfix_lmtp
are updated together is when one of the mailman
subcommands aliases
or start
is run. Are you possibly running both these at the same time
causing some kind of race condition?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Is it possible that there are two servers involved, Mailman on one, Postfix on the other, Mailman executing postmap by some ssh mechanism, and clocks on the servers not really synchronized? Or do you use some other unusual setup such as file transfer from Mailman to Postfix?
Cheers, Hans-Martin
Am 27.10.20 um 00:45 schrieb Mark Sapiro:
Note that the only times both the
postfix_domains
andpostfix_lmtp
are updated together is when one of themailman
subcommandsaliases
orstart
is run. Are you possibly running both these at the same time causing some kind of race condition?
Hi Mark,
thanks for your answer. First of all I ran a 'systemctl restart mailman', which now gives expected timestamps via 'stat' on the four files.
I then checked what could cause a kind of race condition (there is only one server involved):
- I have logrotate configured for daily rotate (which includes a 'systemctl reload mailman')
- I have the cron jobs configured for mailman-web
So it could be that cron jobs for mailman-web are running at the same time when mailman-core is asked to reload after log rotation. Could this lead to a race condition?
But as you said: A 'reload' should not update the files.
Kind regards Torge
On 10/28/20 1:20 AM, Torge Riedel wrote:
- I have logrotate configured for daily rotate (which includes a 'systemctl reload mailman')
- I have the cron jobs configured for mailman-web
The mailman-web crons don't affect this. Only crons that run a mailman
command could.
So it could be that cron jobs for mailman-web are running at the same time when mailman-core is asked to reload after log rotation. Could this lead to a race condition?
But as you said: A 'reload' should not update the files.
What does your systemd mailman.service script contain for ExecReload?
What crons run at the time of the anomalous timestamps?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Am 28.10.20 um 20:09 schrieb Mark Sapiro:
What does your systemd mailman.service script contain for ExecReload?
ExecReload=/opt/mailman/core/bin/mailman.sh restart
What crons run at the time of the anomalous timestamps?
I checked that and came to the idea, that there might by a reboot of the machine at that time.
Maybe it is caused by start mailman & postfix at the same time or not in the "correct" order (postfix first, then mailman)?
Kind regards Torge
participants (3)
-
Hans-Martin Mosner
-
Mark Sapiro
-
Torge Riedel