localport binding...
I'm trying to get syslog-ng (1.5.20) to use 514 as its source port when using the udp destination driver as follows: <<Following taken from my syslog-ng.conf>> source s_sys { unix-stream("/dev/log"); internal(); }; destination d_syslog { udp("192.168.0.2" destport(514) localport(514)); }; log { source(s_src); destination(d_syslog); }; but it always seems to send the syslog udp datagrams using the next available non-privileged port as its source (>1024). I'm running as root (on RedHat 7.3) and syslogd is not running. Syslog-ng doesn't choke on the config, so I'm assuming its not a syntax problem, but I just can't seem to get it to use 514 as its source port?! Does anyone have any ideas what I may be doing wrong here? Or is it just silently ignoring my request to use port 514? Thanks.
On Sun, Sep 15, 2002 at 08:16:13PM -0400, Robert D. Beal wrote:
I'm trying to get syslog-ng (1.5.20) to use 514 as its source port when using the udp destination driver as follows:
destination d_syslog { udp("192.168.0.2" destport(514) localport(514)); };
I had no idea you could set the local port, I just checked the source of 1.5.20 and found this example: doc/sgml/syslog-ng.sgml: destination d_tcp { tcp("10.1.2.3" port(1999); localport(999)); }; Looks like you need this: destination d_syslog { udp("192.168.0.2" port(514); localport(514)); }; Give it a shot. -- "Vampireware /n/, a project, capable of sucking the lifeblood out of anyone unfortunate enough to be assigned to it, which never actually sees the light of day, but nonetheless refuses to die."
On Sun, Sep 15, 2002 at 06:33:51PM -0700, Nate Campi wrote:
On Sun, Sep 15, 2002 at 08:16:13PM -0400, Robert D. Beal wrote:
I'm trying to get syslog-ng (1.5.20) to use 514 as its source port when using the udp destination driver as follows:
destination d_syslog { udp("192.168.0.2" destport(514) localport(514)); };
I had no idea you could set the local port, I just checked the source of 1.5.20 and found this example:
doc/sgml/syslog-ng.sgml: destination d_tcp { tcp("10.1.2.3" port(1999); localport(999)); };
Looks like you need this:
destination d_syslog { udp("192.168.0.2" port(514); localport(514)); };
As it seems the docs is buggy, Robert is right. The bug lies in libol, it only binds the local socket if the local address is defined. So there are two solutions: * supply localip as well as localport * apply this patch to libol, and recompile diff -u -r1.26 -r1.28 --- io.c 11 Oct 2001 18:25:14 -0000 1.26 +++ io.c 16 Sep 2002 08:23:22 -0000 1.28 @@ -829,9 +834,9 @@ memcpy(sa, &a->sa, sizeof(a->sa)); return 1; } - if (a->ip && !tcp_addr(in, - a->ip->length, a->ip->data, - a->port)) + if (tcp_addr(in, + a ? a->ip->length : 7, a ? a->ip->data : "0.0.0.0", + a->port)) return 0; else if (!a->ip && !tcp_addr(in, 0, NULL, a->port)) -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
syslog-ng has some scary behavior when I have a source kernel { } in my syslog-ng.conf on NetBSD 1.5.x/i386. The results below are for syslog-ng 1.5.21, but this isn't a new problem since it also happens with 1.5.16. My configuration has a socket to the central server, two unix-dgram sockets (/var/run/log and a second /var/run/log in a chroot), incoming TCP sockets from a couple of other servers running syslog-ng, and several file destinations (in /var/log, similiar to a normal syslogd config file). There's also a /dev/console and usertty output, again trying to emulate regular syslogd. When I had this source in the config file: source kernel { file("/dev/klog"); }; syslog-ng started up properly, although with the annoying message: Changing permissions on special file /dev/klog and created all the file destinations and the socket to the central server. But when the daemon got HUP'd for rotation of the local logs, things went awry. The "Changing permissions" message reappeared and the file destinations to /var/log/xxxx were closed and not re-opened. Logging continued to the central server, but none of the local files were written. I took out the "source kernel" statement and HUP now works properly, without losing the local output files. A ktrace of the buggy configuration shows that syslog-ng is doing something very weird with all of its file sources - upon HUP, the unix-dgram sockets are closed and re-opened twice (!), the kernel source is also re-opened twice, and the local file destinations are never re-opened. Here's an annotated highlights of the ktrace of the buggy HUP: 27793 syslog-ng PSIG SIGHUP caught handler=0x8049f40 mask=() code=0x0 [...] 27793 syslog-ng CALL open(0x480ed515,0,0x1b6) 27793 syslog-ng NAMI "/etc/resolv.conf" [...] 27793 syslog-ng CALL open(0x8059b60,0,0x1b6) 27793 syslog-ng NAMI "/etc/syslog-ng.conf" [ re-reads config file ] [ closes most of the existing file descriptors ] 27793 syslog-ng CALL close(0x11) # TCP socket from client 27793 syslog-ng RET close 0 27793 syslog-ng CALL close(0x10) # TCP socket from 2nd client 27793 syslog-ng RET close 0 27793 syslog-ng CALL close(0x6) # TCP socket listening for clients 27793 syslog-ng RET close 0 27793 syslog-ng CALL close(0x5) # unix-dgram input 27793 syslog-ng RET close 0 27793 syslog-ng CALL close(0x3) # unix-dgram input 27793 syslog-ng RET close 0 [ unlink, bind, then chown and chmod /var/run/log unix-dgram input ] [ unlink, bind, then chown and chmod /var/chroot/var/run/log unix-dgram input ] [ this is weird - says it's changing permissions, but doesn't actually do anything ] 27793 syslog-ng CALL write(0x2,0xbfbfd4b0,0x2f) 27793 syslog-ng GIO fd 2 wrote 47 bytes "Changing permissions on special file /dev/klog " 27793 syslog-ng RET write 47/0x2f [ now syslog-ng tries to re-open /dev/klog before closing it, which doesn't work on NetBSD since the device is allowed for only one user at a time ] 27793 syslog-ng CALL open(0x8069e68,0x8004,0x180) 27793 syslog-ng NAMI "/dev/klog" 27793 syslog-ng RET open -1 errno 16 Device busy 27793 syslog-ng CALL issetugid 27793 syslog-ng RET issetugid 0 [.. call C library to print error message ] 27793 syslog-ng CALL write(0x2,0xbfbfd548,0x37) 27793 syslog-ng GIO fd 2 wrote 55 bytes "Error opening file /dev/klog for reading (Device busy) 27793 syslog-ng CALL close(0xf) # /var/log/cron 27793 syslog-ng RET close 0 27793 syslog-ng CALL close(0xe) # /var/log/maillog 27793 syslog-ng RET close 0 27793 syslog-ng CALL close(0xd) # /var/log/authlog 27793 syslog-ng RET close 0 27793 syslog-ng CALL close(0xc) # /var/log/daemon.log 27793 syslog-ng RET close 0 27793 syslog-ng CALL close(0xb) # /var/log/notices 27793 syslog-ng RET close 0 27793 syslog-ng CALL close(0xa) # /var/log/messages 27793 syslog-ng RET close 0 27793 syslog-ng CALL close(0x9) # /dev/console 27793 syslog-ng RET close 0 27793 syslog-ng CALL close(0x4) # /var/log/poplog 27793 syslog-ng RET close 0 27793 syslog-ng CALL close(0x8) # TCP socket to central server 27793 syslog-ng RET close 0 27793 syslog-ng CALL close(0x7) # /dev/klog 27793 syslog-ng RET close 0 [ these file descriptors are already closed (see above), but syslog-ng tries to close them a second time ] 27793 syslog-ng CALL close(0x6) 27793 syslog-ng RET close 0 27793 syslog-ng CALL close(0x5) 27793 syslog-ng RET close 0 27793 syslog-ng CALL close(0x3) 27793 syslog-ng RET close 0 [ For a second time, unlinks, binds, chown, then chmod the two unix-dgram sockets ] 27793 syslog-ng CALL socket(0x1,0x2,0) 27793 syslog-ng RET socket 3 [...] 27793 syslog-ng CALL __stat13(0xbfbfd8d2,0xbfbfd870) 27793 syslog-ng NAMI "/var/run/log" [...] 27793 syslog-ng CALL __stat13(0xbfbfd8d2,0xbfbfd870) 27793 syslog-ng NAMI "/var/chroot/var/run/log" [ recreates the TCP listening socket ] [ re-opens /dev/klog - note that it starts with the permissions message, yet doesn't seem to actually call chmod() anywhere ] 27793 syslog-ng CALL write(0x2,0xbfbfd4b0,0x2f) 27793 syslog-ng GIO fd 2 wrote 47 bytes "Changing permissions on special file /dev/klog " 27793 syslog-ng RET write 47/0x2f 27793 syslog-ng CALL open(0x805c088,0x8004,0x180) 27793 syslog-ng NAMI "/dev/klog" 27793 syslog-ng RET open 6 27793 syslog-ng CALL lseek(0x6,0,0,0,0x2) 27793 syslog-ng RET lseek 0 27793 syslog-ng CALL fcntl(0x6,0x3,0x6) 27793 syslog-ng RET fcntl 4 27793 syslog-ng CALL fcntl(0x6,0x4,0x4) 27793 syslog-ng RET fcntl 0 27793 syslog-ng CALL fcntl(0x6,0x2,0x1) 27793 syslog-ng RET fcntl 0 [ recreates the TCP socket to the central server ] 27793 syslog-ng CALL socket(0x2,0x1,0x6) 27793 syslog-ng RET socket 7 [...] 27793 syslog-ng CALL connect(0x7,0xbfbfd924,0x10) 27793 syslog-ng RET connect -1 errno 36 Operation now in progress Note that the file destinations which were closed were never re-opened. At this point, syslog-ng begins to receive log messages from the usual sources and relay them all to the central server, as if the file destinations were never defined in the first place. lsof from before and after the HUP confirms that the file destinations were never re-opened. Oh, one more note - I ktrace'd the working configuration, without the kernel source, and the unix-dgram sockets did NOT get re-opened twice as in the above ktrace. Curiouser and curiouser. Baszi? What's going on?
participants (4)
-
Balazs Scheidler
-
Ed Ravin
-
Nate Campi
-
Robert D. Beal