Michael Tokarev:
> The "trick" I use with postfix for a long time locally
> to address this issue is to mount a tmpfs on linux on
> /var/spool/postfix/run, create subdirs (pid, public,
> private) there [...]
>
> So, the question is: can postfix change the paths so
> that all these "runtime" dirs are in a single subdir
> (as run/pid, run/public, run/private) - that is changing
> 3 strings in postfix code (and postfix-files) and adding
> one extra line into postfix-files, -- in order to simplify
> such a setup ?
Sounds reasonable. However, this is not the only option.
1) Mounting tmpfs over a mail queue subdirectory introduces additional
dependency (something needs to mount and populate spool/run
before any Postfix program is allowed to execute) otherwise there
will be surprises when a Postfix program needs to be executed
before everything is up and running (for example, when some boot
script wants to submit mail about saved editor buffers, this
will result in "postdrop: warning: unable to look up public/pickup:
No such file or directory"). Normally, a missing "public/pickup"
directory is a sign of major trouble (no mail will ever be picked
up). This would violate one basic Postfix principle, which is
that it must be able to submit mail at any time even before all
daemons are up and running.
2) We could wait until all commodity boxes have solid-state drives.
SSDs have many desirable properties and prices are coming down.
3) Instead of changing the file system layout, we could change
master.cf to use "unix" instead of "fifo" endpoints for the queue
manager and pickup services. The reason for using FIFOs is that
Solaris 2.4 UNIX-domain sockets locked up the kernel during
Postfix tests (the change to FIFOs then exposed bugs in several
4.4BSD implementations, but I disgress).
To this date, both the trigger client (used in postdrop and cleanup)
and trigger server (used in qmgr and pickup) contain code for
UNIX-domain sockets. This code has not been tested in 12 years,
so minor updates are likely needed. But the benefit of this is
that there are no visible changes except four bytes in master.cf.
I would prefer the third solution, as it introduces no external
dependencies on boot scripts to mount and populate spool/postfix/run,
and it introduces no visible changes to the file system layout.
> I'm fine to change postfix-files locally so it looks at
> run/pid etc instead of pid, but that appears to be a bit
> ugly...
I don't understand why this is needed at all. On my own systems,
"ls -lat /var/spool/postfix/pid" shows that there are no writes to
the directory itself or to any files in that directory after the
mail system has started up.
Wietse
