Glen B wrote:
Wietse Venema wrote:
Ben Winslow:
FWIW, my test system uses the system-wide timezone (US/Central)
in the output from mailq and the timezone from $TZ (US/Eastern)
for the output from postcat. This is, IMO, the correct behavior.
I hadn't thought of that (system versus user time zone). It could
explain the original problem report. The difference is really an
accident of implementation.
When the mail system is running, the mailq command connects to a
showq daemon which reports times according to the system time zone.
When the mail system is stopped, the super-user can still execute
the mailq command. In this case, mailq executes the showq program
directly, and will report times according to the "user" time zone.
Wietse
That appears to be the case but I'm not sure how to deal with it
since I only have _one_ timezone configured on my server and showq is
not chrooted. It's tough trying to obtain the queue contents from
postcat when the message arrival scope can change based on service
status. I considered reading the queue files directly but you've
stated that the format is not documented and therefore should not be
read/written directly. So, can I request a raw message dump tool that
simply outputs the headers and data section? I'd be fine with a raw
envelope used in SMTP DATA transactions. If this is possible with an
existing tool then I'd be fine with that also. As it stands I can't
rely on postcat output having an accurate local date/time.
Thanks,
GlenB
Update: /etc/default/rcS had UTC=yes configured so it was defaulting to
UTC if no timezone was set. Why no TZ was set in the chroot, I'm
clueless. Maybe it's something else I'm totally unaware of and will find
out later in life? Now.. things have flipped. mailq shows localtime when
services are running but UTC when not. I'm losing my marbles now, I
think. I'll post back if I find a resolution. Otherwise, thanks for the
help! It's still broken, but at least I know it's not the Postfix code
as I originally had thought.
GlenB
