I was deleting file then, copy in new one.
I stopped the deletion. It seems to work.
I thought of writing directly to the file in the maps directory.
But not sure about the file locking you mentioned.
I'll do some more homework.
thx
--john
On 4/19/25 6:10 PM, Wietse Venema via Postfix-users wrote:
John Hill via Postfix-users:
When I manually update my lmdb access tables, adding or deleting. I see
this message in the log: error: accept connection: Socket operation on
non-socket.
The line before this error: table
lmdb:/etc/postfix/maps/postscreen_blacklist has changed - finishing in
the background
First that is NOT AN ERROR message.
Scond, you're doing something wrong.
When the LMDB table is used properly, postscren, will not claim
that it has changed. The table asserts the DICT_FLAG_MULTI_WRITER
flag (multi-writer safe), and the 'table has changed' code skips
tables that assert that flag.
HOWEVER, the table will be flagged as 'changed' when you delete
the old .lmdb file that postscreen still has open (the link count
is zero).
I am using postmap -i on the tables.
I create access tables in a working directory, then copy them to the
postfix maps directory and run postmap.
I suppose that somewhere in that process, the .lmdb file is renamed
into place which deletes the old .lmdb file that postscreen still
has open.
Am I doing something wrong?
You are not following the locking protocol as described in
https://www.postfix.org/lmdb_table.5.html#synchronization
SYNCHRONIZATION
The Postfix LMDB adapter does not use LMDB's built-in locking
scheme, because that would require world-writable lockfiles
and therefore violate the Postfix security model. Instead,
Postfix uses fcntl(2) locks with whole-file granularity.
Programs that use LMDB's built-in locking protocol will
corrupt a Postfix LMDB database or will read garbage.
Every Postfix LMDB database read or write transaction must
be protected from start to end with a shared or exclusive
fcntl(2) lock. A writer may atomically downgrade an exclusive
lock to a shared lock before opening a database read
transaction, but it must hold an exclusive lock while
opening a write transaction.
Note that fcntl(2) locks do not protect transactions
within the same process against each other. If a program
cannot avoid making simultaneous database requests,
then it must protect its transactions with in-process locks,
in addition to the per-process fcntl(2) locks.
Assuming that the above synchronization protocol is in effect, AND
you aren't deleting the .lmdb file, postscreen won't bother with
forking off into the background.
Wietse
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
