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. 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. 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. Thanks in advance. g.
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
Hi, On Fri, 19 Nov 2004 11:16:17 +0100 Balazs Scheidler <bazsi@balabit.hu> wrote:
Probably the timezone settings are not correct within your chroot. That's right. Fixed. thx.
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. 32475 open("/proc/kmsg", O_RDONLY|O_NONBLOCK|O_NOCTTY|O_LARGEFILE) = 8 . . 32475 read(8, 0x806e960, 2048) = -1 EPERM (Operation not permitted) 32475 getpid() = 32475 32475 time(NULL) = 1101116175 32475 time(NULL) = 1101116175 32475 poll([{fd=9, events=0}, {fd=5, events=POLLOUT, revents=POLLOUT}, {fd=8, events=POLLIN, revents=POLLIN}, {fd=7, ev ents=POLLIN}, {fd=6, events=POLLIN}, {fd=3, events=POLLIN}], 6, 100) = 2 32475 write(5, "Nov 22 10:36:15 burp syslog-ng[3"..., 103) = 103 32475 time(NULL) = 1101116175 32475 close(8)
You are right again. What should I do? Have I forgotten something about /proc? I tried to give the file to the group I am running syslog-ng as. Also change perms to 660. Made no difference. When I start syslog-ng as root it can read kmsg. I am running the 2.6.8-1-686 built by debian. With debian patches applied. They may have included something in those patches...
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.
Well this particular build of this release on this system does not :) I shall investigate further and get back to the list. I configured logrotate to issue reload again, so I can say some more about it tomorrow. Thanks. g.
On Mon, 2004-11-22 at 12:09, Horvath Gabor Kalman wrote:
Hi,
On Fri, 19 Nov 2004 11:16:17 +0100 Balazs Scheidler <bazsi@balabit.hu> wrote:
Probably the timezone settings are not correct within your chroot. That's right. Fixed. thx.
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. 32475 open("/proc/kmsg", O_RDONLY|O_NONBLOCK|O_NOCTTY|O_LARGEFILE) = 8
this call was successful. you need to look for the read() syscall which resulted in "Operation not permitted". -- Bazsi
On Mon, 22 Nov 2004 13:39:53 +0100 Balazs Scheidler <bazsi@balabit.hu> wrote:
32475 open("/proc/kmsg", O_RDONLY|O_NONBLOCK|O_NOCTTY|O_LARGEFILE) = 8
this call was successful. you need to look for the read() syscall which resulted in "Operation not permitted".
32475 open("/proc/kmsg", O_RDONLY|O_NONBLOCK|O_NOCTTY|O_LARGEFILE) = 8 . . 32475 read(8, 0x806e960, 2048) = -1 EPERM (Operation not permitted) two lines below the one you copied :) Back to the other issue: syslog-ng not reopening the files on HUP. syslog-ng 802 syslog 5w REG 9,0 2798018 71961 /home/syslog/var/log/syslog.1 (deleted) syslog-ng 802 syslog 9w REG 9,0 37841 34779 /home/syslog/var/log/messages.1 (deleted) syslog-ng 802 syslog 10w REG 9,0 458383 29060 /home/syslog/var/log/auth.log.1 (deleted) syslog-ng 802 syslog 11w REG 9,0 2597302 31908 /home/syslog/var/log/mail.log.1 (deleted) syslog-ng 802 syslog 12w REG 9,0 2597302 29263 /home/syslog/var/log/mail.info.1 (deleted) syslog-ng 802 syslog 14w REG 9,0 98466 29082 /home/syslog/var/log/daemon.log.1 (deleted) syslog-ng 802 syslog 15w REG 9,0 101443 369853 /home/syslog/var/log/debug.1 (deleted) this is what I see in lsof. If I issue restart instead reload, it works just fine. I also checked the init script I use (debian's default in sid) and it looks fine to me... br g.
On Tue, 2004-11-30 at 16:56, Horvath Gabor Kalman wrote:
On Mon, 22 Nov 2004 13:39:53 +0100 Balazs Scheidler <bazsi@balabit.hu> wrote:
32475 open("/proc/kmsg", O_RDONLY|O_NONBLOCK|O_NOCTTY|O_LARGEFILE) = 8
this call was successful. you need to look for the read() syscall which resulted in "Operation not permitted".
32475 open("/proc/kmsg", O_RDONLY|O_NONBLOCK|O_NOCTTY|O_LARGEFILE) = 8 .
then your kernel does not allow opening /proc/kmsg from within the chroot, remove this source from your syslog-ng config. -- Bazsi
participants (2)
-
Balazs Scheidler
-
Horvath Gabor Kalman