On 04/20/2017 11:04 AM, Viktor Dukhovni wrote:
On Thu, Apr 20, 2017 at 03:30:58PM +0200, Patrick Ben Koetter wrote:

* Robert Moskowitz <r...@htt-consult.com>:
My system does not have a battery for the clock (like most armv7 SOCs), thus
I rely on that at some point in boot time, chronyd sets the time.  If a file
is updated prior to chronyd accomplishing its task (or network connectivity
is down), the file ends up with a timestamp of "Dec 31  1969".

I notice that occasionally, after a reboot, /etc/aliases.db reverts to this
time, and I have to run newaliases to fix it.  I suppose I could run touch
as well.

So is postfix startup rebuilding aliases.db, perhaps?  Is there some way to
It isn't. Something else must tamper your data.
While the "postfix start" command does not rebuild the aliases
database, it is possible that a more feature-rich start script
that invokes "postfix start" (provided by the O/S distribution)
does rebuild the aliases database.

I think I found it

more /usr/lib/systemd/system/postfix.service
[Unit]
Description=Postfix Mail Transport Agent
After=syslog.target network.target
Conflicts=sendmail.service exim.service

[Service]
Type=forking
PIDFile=/var/spool/postfix/pid/master.pid
EnvironmentFile=-/etc/sysconfig/network
ExecStartPre=-/usr/libexec/postfix/aliasesdb
ExecStartPre=-/usr/libexec/postfix/chroot-update
ExecStart=/usr/sbin/postfix start
ExecReload=/usr/sbin/postfix reload
ExecStop=/usr/sbin/postfix stop


That /usr/libexec/postfix/aliasesdb ?

Now if I can figure out that After line...


You should be much more concerned about Postfix starting with
the wrong time than about the timestamp on the aliases.db file.

If the queue manager believes it is 1970, it is going to have a
hard time processing the queue correctly.  Make sure that the
Postfix start script does not run before the clock is set.

You could arrange for a small measure of sanity by setting the
clock to the modification time of some file that is updated at
shutdown if NTP or similar fails.  The RNG state save file
seems like a reasonable bet.

Another option is to refuse to start Postfix if the time is
before the date that your version of Postfix was released.

For example, with:

     $ postconf -dh mail_version
     3.1.3

we have:

     $ postconf -dh mail_release_date
     20161001


Reply via email to