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
