On 01.05.2012 17:09, Wietse Venema wrote:
> 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.
By default these dirs -- /var/spool/postfix/run/{pid,private,public} -
should be created at install time just like now these dirs are create
in /var/spool/postfix. The only change I'm asking about is to move
the "runtime" directories into a subdir (suggesting to name it "run"),
I don't ask to mount anything in there or to create these on boot.
With this scheme, all default installs will be functional just like
now, but the option to mount some tmpfs over /var/spool/postfix/run
_and_ create {pid,private,public} subdirs in there will be easier.
That's whole difference: just moving these 3 into a subdir, to
group them together, all the rest remains the same.
This change does not add any additional external dependency. Only
when some separate filesystem gets mounted over there, only in that
case something should create the subdirs inside, and this "something"
can be the same which did the mount.
> 2) We could wait until all commodity boxes have solid-state drives.
> SSDs have many desirable properties and prices are coming down.
This question has been asked in context of SSDs too, like, it is a
good idea to avoid extra writes to SSD. I've no idea how reliable
these beasts are, actually, - reports varies greatly, probably as
with everything else, there are cheaper less reliable models and
more expensive, but more reliable. I dunno, I never used any SSD
myself so far.
> 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).
Yes, I remember that change to work around an issue on solaris.
After all, this can be a compile-time option in sys_defs.h. I
think I suggested just that when the original bug has been
identified, but I don't remember why FIFO has been choosen
unconditionally -- most likely because it just works everywhere.
But I know you dislike partial solutions - me dislikes them too :)
> 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.
Note the word "etc" after run/pid. I added all 3 "runtime" dirs into
the mix -- pid, private, public -- the directories where the files
makes any sense at all till postfix is running _only_. Files in
there does not exist, so to say, when it is not running - even if
formally corresponding inodes do exist.
This is exactly the case for /var/run directory, and nowadays it
become quite common to use some tmpfs for this directory - one of
the reasons is a problem of pid boot files after fresh boot (or,
you may say it is a problem of stupid startup scripts who does not
verify that the pid listed in a pidfile actually correspond to our
daemon and not some other random process - but tmpfs on /var/run
makes this problem go away completely).
That's why I grouped all 3 "runtime" dirs together in my setup and
moved them into a tmpfs - there's just no reason for them to be in
a regular filesystem which preserves content over reboots. Yes
it is obviously not necessary to do this just to stop the filesystem
writes and spinning up disks.
Besides, the same effect can be achieved by using subdirs of "pid"
directory for private and public dirs, -- ie, instead of
run/pid, run/private, run/public
it is equally easy to have
pid, pid/private, pid/public
since files in pid/ does not clash with names "private" and "public".
This way, filesystem layout changes less, but that's unimportant
details.
And yes, I verified the socket code (instead of pipe code) on linux
a few days ago and it appears to work fine there too. So indeed, this
is a very good possibility too, but it does not cover solaris well.
Thanks,
/mjt
