Bug 8061 - sysklogd logging alternate sockets with wrong time
sysklogd logging alternate sockets with wrong time
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: sysklogd (Show other bugs)
6.1
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Bill Nottingham
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-12-30 03:00 EST by adam
Modified: 2014-03-16 22:11 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-01-03 15:28:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description adam 1999-12-30 03:00:04 EST
I'm running named in a chroot jail, and using the -a argument to syslogd to
get it to listen on a socket within the jail.  (/jails/named/dev/log)

Information does get logged, but it's logged (I think) with GMT, not with
the adjusted local time zone that everything else is logged with.  Which
leads to stuff like this... (note timestamps)

Dec 29 16:03:36 hostname -- MARK --
Dec 30 00:07:09 hostname named[30851]: Cleaned cache of 434 RRsets
Dec 30 00:07:09 hostname named[30851]: USAGE [...elided...]
Dec 30 00:07:09 hostname named[30851]: NSTATS [...elided...]
Dec 30 00:07:09 hostname named[30851]: XSTATS [...elided...]
Dec 29 16:18:01 hostname -- MARK --

"hostname" is running a custom 2.2.12 kernel with the latest sysklogd
package from updates.redhat.com (1.3-3) and named 8.2.2p5.  This also
happens on two other machines I administer, which use custom 2.2.13
kernels.
Comment 1 Bill Nottingham 1999-12-30 12:32:59 EST
Do you have timezone data in your chroot jail?
Comment 2 adam 2000-01-03 12:34:59 EST
nope -- copying /etc/localtime into the chroot jail's "/etc" solves the problem
Comment 3 Andrew Bartlett 2000-12-27 02:07:02 EST
This is similar to bug 18671, should it be up to the application to decide the
current time?  Why can't syslogd do this (and therefore make fakeing logs a
little harder)?

Note You need to log in before you can comment on or make changes to this bug.