[syslog-ng]syslog-ng chrooted vs timezone

[Balazs Scheidler]

On Fri, 2004-11-19 at 07:58, Horvath Gabor Kalman wrote:
> Hi!
> 
> I have a problem with syslog-ng running in chroot:
> 
> Nov 17 15:45:02 burp /USR/SBIN/CRON[26238]: ...
> Nov 17 14:47:42 burp syslog-ng[16074]: syslog-ng version 1.6.4 going down
> Nov 17 14:47:47 burp syslog-ng[26331]: syslog-ng version 1.6.4 starting
> Nov 17 14:47:47 burp syslog-ng[26331]: io.c: do_read: read() failed (errno 1), Operation not permitted
> Nov 17 14:48:27 burp syslog-ng[26331]: syslog-ng version 1.6.4 going down
> 
> It seems that all messages that are generated internally within syslog-ng are logged with false timstamps.
> The system is debian testing. 

Probably the timezone settings are not correct within your chroot. Check
if /etc/localtime is pointing to the correct timezone file.

> 
> I am testing syslog-ng in chroot before deploying it on our production syslog server. :) Good thing I did this test.
> The second start in the log snippet was done by hand. Not from the init script. 
> 
> I am also interested to know what that io.c message is.
> It does not seem to affect syslog-ng.

Probably some kernel hardening rejected a read request on some special
files? Maybe /proc/kmsg? I'd check to be sure with strace to see what
was the read which failed.

> 
> I had another problem: when logrotate rotated the logs the sent a reload to the chrooted syslog-ng process, it kept the syslog open. So after that was deleted it kept happily logging there not into the newly created file. I works just fine if I send restart instead of reload.

Probably it sent the HUP signal to the wrong PID, it's a quite common
problem, that it reads the PID from a file called /var/run/syslogd.pid,
instead of /var/run/syslog-ng.pid (where syslog-ng stores its pidfile).

Syslog-ng reopens all files when receiving a HUP signal.

-- 
Bazsi