Mehmet Avcioglu:
> > Now, Postfix queue files don't repair themselves spontaneously.
> > Before I go off with speculation, I have a few questions to narrow
> > the search:
> >
> > - Is only the showq process affected or other programs, too?
>
> Yes, only the 'showq' logs this message.
>
> > - Is this reproducible?
>
> Multiple servers are running and keep logging these lines. Restarting
> postfix or the server does not change, so I continue to see it with new
> mails. So I am able to reproduce it, now sure how or why though :)
>
> > - Are you using a special malloc library?
>
> This is with stock RHEL 8.2 running postfix-3.3.1-12.el8 without many
> additions or changes.
Then I suspect that the code reaches the 10000 limit because
there are ~10000 files in the queue.
The rec_get routine uses bad code to determine that the program has
switched to a new file, and thus it thinks that there is one file
with 10000 backward jumps, instead of 10000 files with one backwards
jump. It compares memory addresses instead of pathnames. That works
because typical malloc() implementations don't return the same
addresses all the time.
Below is a patch that should fix this.
Wietse
diff -ur /var/tmp/postfix-3.7-20210707/src/global/record.c src/global/record.c
--- /var/tmp/postfix-3.7-20210707/src/global/record.c 2021-01-13
18:54:42.000000000 -0500
+++ src/global/record.c 2021-07-13 16:20:47.540814072 -0400
@@ -338,8 +338,10 @@
*/
#define REVERSE_JUMP_LIMIT 10000
- if (saved_path != VSTREAM_PATH(stream)) {
- saved_path = VSTREAM_PATH(stream);
+ if (saved_path == 0 || strcmp(saved_path, VSTREAM_PATH(stream)) != 0) {
+ if (saved_path)
+ myfree(saved_path);
+ saved_path = mystrdup(VSTREAM_PATH(stream));
reverse_count = 0;
saved_offset = 0;
}
