DevHeads.net

Local delivery to mbox / inode issue

I am using incrond to monitor an mbox file (in /var/mail) for changes, but
it is failing to trigger when postfix adds an incoming mail to the file.
(It triggers fine however if I touch the file.)

I may be barking up the wrong tree but I wonder if this is because instead
of merely appending to the existing mbox file, postfix/local rewrites the
file so that its inode changes (which I know breaks incrond's ability to
monitor a file). If so, is there a way to get postfix to append to the file
without changing the inode, and if so what are the disadvantages?

I have postfix 3.3.0, local has default settings, and /var/mail is on
filesystem ext4 (options rw,relatime,data=ordered) under Ubuntu 18.04.1
(GNU/Linux 4.15).

Comments

Re: Local delivery to mbox / inode issue

By Matus UHLAR - f... at 12/07/2018 - 05:14

On 06.12.18 15:45, Dominic Raferd wrote:
hmmm, why?
maybe there's other way to implement your requirement

Re: Local delivery to mbox / inode issue

By Dominic Raferd at 12/07/2018 - 06:22

On Fri, 7 Dec 2018 at 09:15, Matus UHLAR - fantomas < ... at fantomas dot sk>
wrote:

I think I have it working now. The problem was not postfix (of course), it
was that I was modifying the mbox file using
postlock $MBOXFILE sed -if $SCRIPTFILE $MBOXFILE
which in fact replaces it, I am now using:
postlock $MBOXFILE /bin/bash -c "sed -f $SCRIPTFILE $MBOXFILE|sponge
$MBOXFILE" # not sure if bash subshell is necessary?
and also comparing the inode before and after - if the inode changes (which
is not normally the case) then I restart incrond.

The use case is my home-grown quarantining system. Mail server periodically
emails me about quarantined emails - I can reply to these emails using
short codes, this reply is placed by postfix in the monitored $MBOXFILE.
When $MBOXFILE changes, incrond triggers a script which looks at the latest
email in it and interprets it to take the necessary actions i.e. removing
unwanted mails from quarantine, releasing wanted ones, whitelisting sender
etc.

Re: Local delivery to mbox / inode issue

By Dominic Raferd at 12/31/2018 - 03:33

To complete this thread: because sponge does not always prevent a change in
the inode of the file to which it is writing (in this case $MBOXFILE), and
sed -i never does, I now use ed; and the rather horrible hack of restarting
incrond is not required.

Re: Local delivery to mbox / inode issue

By Matus UHLAR - f... at 12/07/2018 - 06:39

On 07.12.18 10:22, Dominic Raferd wrote:
You can run script at the time of mail delivery by using .forward that pipes
mail to a script. You don't need to watch file for changes.

Re: Local delivery to mbox / inode issue

By Dominic Raferd at 12/07/2018 - 09:23

On Fri, 7 Dec 2018 at 10:40, Matus UHLAR - fantomas < ... at fantomas dot sk>
wrote:

That is neat, but not sure in that situation how I give the script
permissions to operate on the quarantined files (i.e. run amavisd-release),
and update whitelist files.

Re: Local delivery to mbox / inode issue

By Wietse Venema at 12/06/2018 - 12:08

Dominic Raferd:
Possible causes:

- Your file system does not set the file mtime when Postfix appends
to the file. Fix: don't disable mtime updates for append operations.

- There is a clock drift problem where the host with Postfix has
different time than the host with the file system. Fix: run NTP on
both hosts.

Have you verified that the inode number changes?

Postfix opens an mbox file with O_APPEND mode which is standardized
by the POSIX API. If that causes the file inode number to change,
then you need to use a different file system.

Wietse

Re: Local delivery to mbox / inode issue

By Dominic Raferd at 12/06/2018 - 12:15

Thanks for the swift response - see below.

- it does set the mtime when Postfix appends to the file

- There is a clock drift problem where the host with Postfix has
- Postfix is on the same host as the filesystem

no, I will check how to do this

Postfix opens an mbox file with O_APPEND mode which is standardized
In this case I suspect that the inode issue is not the cause of incrond's
problem.

Re: Local delivery to mbox / inode issue

By Bill Cole at 12/06/2018 - 12:36

'ls -li' is your friend.

Re: Local delivery to mbox / inode issue

By Dominic Raferd at 12/06/2018 - 13:13

On Thu, 6 Dec 2018 at 16:37, Bill Cole <

Thanks, I have now used this to confirm that the inode number does not
change when postfix/local updates the mbox file. So the problem with
incrond lies elsewhere.

Re: Local delivery to mbox / inode issue

By Bill Cole at 12/06/2018 - 13:39

One thing to check is the sysctl parameter 'fs.inotify.max_user_watches'
(which is what its name implies.) Some (EL-family, for example)
distributions default to a low value (8K) which is a very easy limit to
hit with a tool like incron that is designed to exploit inotify to its
fullest.