/etc/init.d/syslog-ng has a dependency on net. In /etc/rc.conf I have rc_depend_strict="YES" and on startup the system (baselayout-2/openrc) attempts to start syslog-ng before all of the net devices have been started which causes the startup to fail. syslog-ng can be successfully started manually after the system has booted. emerge --info Portage 2.2_rc1 (default/linux/x86/2008.0/desktop, gcc-4.3.1, glibc-2.8_p20080602-r0, 2.6.25-gentoo-r5 i686) ================================================================= System uname: Linux-2.6.25-gentoo-r5-i686-Intel-R-_Core-TM-2_CPU_6700_@_2.66GHz-with-glibc2.0 Timestamp of tree: Sun, 22 Jun 2008 19:15:02 +0000 app-shells/bash: 3.2_p39 dev-java/java-config: 1.3.7, 2.1.6 dev-lang/python: 2.4.4-r11, 2.5.2-r4 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.2.5 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.62 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1-r1 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 2.2.4 virtual/os-headers: 2.6.25-r4 ACCEPT_KEYWORDS="x86 ~x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=native -mtune=native -pipe -ggdb" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/bind /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/eselect/postgresql /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=native -mtune=native -pipe -ggdb" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--with-bdeps y" FEATURES="buildsyspkg distlocks installsources parallel-fetch preserve-libs sandbox sfperms splitdebug strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ http://gentoo.blueyonder.co.uk http://gentoo.tiscali.nl/ http://gentoo.mirror.solnet.ch http://pandemonium.tiscali.de/pub/gentoo/" LANG="en_GB.UTF-8" LC_ALL="en_GB.UTF-8" LDFLAGS="" LINGUAS="en_GB en" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/musicbrainz /usr/portage/local/layman/sunrise /usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X a52 aac aalib acl acpi aim alsa apache2 arts audiofile avi bash-completion berkdb bluetooth bonobo branding browserplugin bzip2 bzlib cairo caps cddb cdparanoia cdr cjk cli cracklib crypt cups curl cvs cxx dbus directfb doc dri dts dvd dvdr dvdread eds emacs emboss encode esd ethereal evo examples exif expat fam fbcon ffmpeg fftw flac foomaticdb fortran ftp gcj gd gdbm gif glut gmp gnome gnome-keyring gnutls gphoto2 gpm graphviz gstreamer gtk gtk2 gtkhtml guile hal iconv icq idn ieee1394 imagemagick imlib ipv6 isdnlog jabber jack java javascript jbig jce jpeg jpeg2k junit kde kdehiddenvisibility kerberos ladspa latex lcms ldap leim libgda libnotify libsamplerate libwww lirc lm_sensors logrotate lua m17n-lib mad matroska mbox midi mikmod milter mime mmap mmx mng modplug mono mozilla mp3 mpeg mpi mplayer msn mudflap musepack ncurses nls nptl nptlonly nsplugin odbc offensive ogg oggvorbis openal opengl openmp oscar oss pam pcntl pcre pdf perl png postgres ppds pppd profile pulseaudio python qt3 qt3support qt4 quicktime readline recode reflection ruby sasl sdl session sharedmem sndfile snmp sockets sox speex spell spl sqlite sqlite3 sse sse2 ssl startup-notification subversion svg sysvipc tcl tcltk tcpd theora threads tiff tk truetype uicktime unicode usb v4l v4l2 vim-syntax vorbis wavpack win32codecs wmf wxwindows x264 x86 xattr xcb xface xine xml xml2 xorg xulrunner xv xvid yahoo zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" APACHE2_MPMS="worker" CAMERAS="canon ptp2" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en_GB en" LIRC_DEVICES="asusdh" USERLAND="GNU" VIDEO_CARDS="radeon vesa fbdev vga" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Sounds like a baselayout-2 issue.
Please state which net scripts are in the runlevel that syslog-ng is in.
(In reply to comment #2) > Please state which net scripts are in the runlevel that syslog-ng is in. > net.eth0 (which is started) net.aa6 (a routed sit tunnel) both are symlinks to /etc/init.d/net.lo
I have this same exact problem. I don't think the case statement in the depend function of the syslog-ng init script is working properly. Since I receive remote logging with this machine the network needs to be up before syslog-ng starts. It might be due to having iptables in the same runlevel since it has a depend of before net and use logger. Any ideas on how to fix?
I "fixed" this removing the dependency on syslog from iptables, but it's not really a fix, just a workaround.
2.0.9 is way too old, it is not even supported by upstream wouldn'be good to close this bug?
reproduced here with: openrc-0.8.2-r1 baselayout-2.0.2 iptables-1.4.10 syslog-ng-3.1.4 == reproduce preconditions 1 $ grep tcp /etc/syslog-ng/syslog-ng.conf tcp(ip(0.0.0.0) port(514)); reason: see /etc/init.d/syslog-ng depend() { # Make networking dependency conditional on configuration case $(sed 's/#.*//' /etc/syslog-ng/syslog-ng.conf) in *source*tcp*|*source*udp*|*destination*tcp*|*destination*udp*) need net <- this one use stunnel ;; esac config /etc/syslog-ng/syslog-ng.conf use clock need hostname localmount provide logger <- this one } == reproduce preconditions 2 /etc/init.d/iptables depend() { before net <- this one use logger <- this one } the dependency circle is made up with conditions above but only reproduce visually with the following condition == reproduce preconditions 3 /etc/rc.conf rc_parallel="YES"
The same problem with stunnel-4.35, rc_parallel=YES and rc_depend_strict=NO (openrc-0.8.3-r1, syslog-ng-3.2.4, iptables-1.4.11.1-r2). Once adding stunnel to default level, cycle with stunnel, logger and iptables appears. I guess this is because init scripts say syslog-ng uses stunnel and stunnel is before logger.
I also get this problem. I have network sources in my syslog-ng config, so the init script for it adds the 'need net' dependency. I then also have iptables, which has 'use logger' and 'before net'. So iptables has to start before 'net', but it needs syslog-ng, and syslog-ng cant start without 'net'. So we have ourselfs a nice circular dependency.
mr_bones_: I think the only viable solution here is to drop the 'need net' from syslog-ng's dependencies. syslog-ng CAN start up even when dest/source are network targets and there is no networking yet, as it just reconnects. Ideally you actually want the log buffering until that point, but that's only in the non-free version of syslog-ng.
I think removing "need net" has the potential to cause major headaches. There might be some situations where syslog-ng is happy starting without networking (when there's some network-related item in the config file) but I'm pretty sure there are other situation where syslog-ng will bail when the network isn't up. I still don't understand why the dep resolver equates "use" and "need". I would expect "use" to give way to "need" in the dep resolution.
pva: From the iptables side, can we relax the 'use logger' part of the init script somehow? (or make it optional for users to select if their rules contain LOG targets, which I think is rare, as lots of users moved to ULOG,NFLOG.) mr_bones: (In reply to comment #11) > I think removing "need net" has the potential to cause major headaches. There > might be some situations where syslog-ng is happy starting without networking > (when there's some network-related item in the config file) but I'm pretty sure > there are other situation where syslog-ng will bail when the network isn't up. Can we come up with some testcases? The only one I have so far is explicitly binding to a source address that does not yet exist. Binding to 0.0.0.0, or anything with a destination works fine (it retries). Also, the detection for source/dest fails to pick up cases like this: source s_hosts_tls { tcp(ip(0.0.0.0) port(6514) keep-alive(yes) max-connections(500) ... ); }; > I still don't understand why the dep resolver equates "use" and "need". I > would expect "use" to give way to "need" in the dep resolution. Running from memory here, there is only one very slightly different between use/need. In both cases, the listed services if they pass the tests get started before the consuming service. Specifically: - use only requires a service if it is already in the runlevel. - need always requires that the list service(s).
I have 'source network {udp(ip("192.168.1.2"),port(514))}' in /etc/syslog-ng/syslog-ng.conf. When I tried to replace 'need net' with 'need net.lo', syslog-ng died at startup (obviously it failed to bind to 192.168.1.2). So it seems that removing 'need net' is not a general solution.
*** Bug 394185 has been marked as a duplicate of this bug. ***
Since my bug was marked as a duplicate of this, I want to comment here, I see the same issue, but it is not caused by syslog-ng. It is, as https://bugs.gentoo.org/show_bug.cgi?id=394185 states a problem with openrc (or baselayout for that matter), which manifests unfortunately mostly with syslog-ng. It is not at all limited so syslog-ng. Here is more information and thoughts on this: As we saw, depend_strict does not change the behaviour and that is simply not influenced by syslog-ng and as such not limited to syslog-ng's init script. But eben without depend_strict, it should be possible, to make syslog wait for ALL networinterfaces, by manual intervention, for my, I did this: rc_logger_after="net_intel net_realtek" rc_net_intel_before="logger" rc_net_realtek_before="logger" The first line should esentially achieve the same, starting net services before logger. Now, let's take a look at the deptree: 1: depinfo_49_service='net.intel' depinfo_49_ineed_0='localmount' depinfo_49_iafter_0='bootmisc' depinfo_49_iafter_1='net.lo' depinfo_49_iafter_2='net.lo0' depinfo_49_iafter_3='hwclock' depinfo_49_iafter_4='swclock' depinfo_49_iprovide_0='net' depinfo_49_keyword_0='-jail' depinfo_49_keyword_1='-prefix' depinfo_49_keyword_2='-vserver' depinfo_49_ibefore_0='logger' depinfo_49_ibefore_1='local' 2: depinfo_52_service='net.realtek' depinfo_52_ineed_0='localmount' depinfo_52_iafter_0='bootmisc' depinfo_52_iafter_1='net.lo' depinfo_52_iafter_2='net.lo0' depinfo_52_iafter_3='hwclock' depinfo_52_iafter_4='swclock' depinfo_52_iprovide_0='net' depinfo_52_keyword_0='-jail' depinfo_52_keyword_1='-prefix' depinfo_52_keyword_2='-vserver' depinfo_52_ibefore_0='logger' depinfo_52_ibefore_1='local' 3: depinfo_86_service='syslog-ng' depinfo_86_ineed_0='net' depinfo_86_ineed_1='hostname' depinfo_86_ineed_2='localmount' depinfo_86_iuse_0='stunnel' depinfo_86_iuse_1='clock' depinfo_86_iprovide_0='logger' depinfo_86_iafter_0='hwclock' depinfo_86_iafter_1='swclock' depinfo_86_ibefore_0='local' 4: depinfo_100_service='logger' depinfo_100_usesme_0='apache2' depinfo_100_usesme_1='dhcpd' depinfo_100_usesme_2='dhcrelay' depinfo_100_usesme_3='git-daemon' depinfo_100_usesme_4='gpm' depinfo_100_usesme_5='ip6tables' depinfo_100_usesme_6='iptables' depinfo_100_usesme_7='named' depinfo_100_usesme_8='pwcheck' depinfo_100_usesme_9='snmpd' depinfo_100_usesme_10='snmptrapd' depinfo_100_usesme_11='spamd' depinfo_100_usesme_12='sshd' depinfo_100_usesme_13='vixie-cron' depinfo_100_iafter_0='bootmisc' depinfo_100_iafter_1='net.intel' depinfo_100_iafter_2='net.realtek' depinfo_100_iafter_3='sysctl' depinfo_100_ibefore_0='cupsd' depinfo_100_needsme_0='exim' depinfo_100_providedby_0='syslog-ng' We can see that the manually added contraints are in place in the deptree. Assuming the numbering is the supposed order of execution (which would be plausible) we clearly see, that net.* should be startet before logger/syslog-ng. What puzzles me though is that, when logger has all the additional deps and syslog-ng is the provider of the service, why should syslog-ng have a lower order, Assuming the numbering is the priority. But indepently of the last question, the deptree suggests, that the logger is to be started AFTER net services, while it is started by openrc inbetween. Additional info, the deptree has net.lo and net.ppp0 as 50 and 51, thus putting them inbetween net.intel and net.realtek. net.lo is in a different level (boot) and therefore started before both of them, but it seems wrong, that net.lo is not before all other net devices in the tree.
Looking at the other posts, I am wondering too, why iptable's 'use' should take precedence over syslogger's 'need'. Thinking about this, a correct evaluation should start iptables (before net) which CAN use logger, followed by net (because it is needed by logger), then logger. Even when we consider iptables rules with LOG targets, the logging will take place (a little deferred) while having no logger at all is simply no option in daily use. The dependencies reflect this, since iptables only USEs logger, but the evaluated order seems to be borked ... And somebody stated PARALLEL startup is a precodition - I can not confirm this, as I am seeing the problem with non parallel startup here. (Assuming the setting is honored, though)
Another thing I would like to see you try is adding something like this to /etc/conf.d/syslog-ng: rc_need="!net net.int1 net.int2 net.int3 ..." where net.int* are the names of the individual network interface scripts that syslog-ng needs on your system for networking.
(In reply to comment #17) > Another thing I would like to see you try is adding something like this to > /etc/conf.d/syslog-ng: > > rc_need="!net net.int1 net.int2 net.int3 ..." > > where net.int* are the names of the individual network interface scripts that > syslog-ng needs on your system for networking. Adding the line, no change. Afterwards removing the stuff I added to rc.conf, no change either. What is weird is this: After (first) adding the line, running rc-update -u did not update the tree correctly (the stuff vom rc_need was not reflected in the syslog-ng entry within the deptree). After reboot the changes showed up in the deptree. Just to make sure I did another reboot. Anyhow, this is not really a nice thing (not starting syslogger + tests to get the issues fixed) to be done on a live/production system.
Created attachment 301081 [details] /tmp/0001-Only-the-loopback-interface-should-provide-net.patch All, I have proposed this patch to openrc on the -dev list. If everyone is comfortable with it, this will take care of this issue by requiring users to configure services to start after the interfaces that they depend on if they bind to a specific ip address.
(In reply to comment #19) Is it a good idea to refer to 'just all networking' with simple 'net' dependence? Just not to tune precise interfaces names in /etc/init.d/ when configuring application-level services (which are not required for net or syslog).
The other problem with syslog-ng having "need net" in the dependencies is that this makes syslog-ng stop when *any* network interface is stopped. This is not good for machines that have multiple network interfaces on different networks.
Created attachment 327252 [details] syslog-ng @mr_bones_: Here is the init script I recommend using for syslog-ng. You will want to add documentation to /etc/conf.d/syslog-ng to show users how to configure interfaces if they need them for networkloging. For example: #if using oldnet: rc_need="net.bla" #if using newnet and configuring the interface with the network script: rc_need="network" # if using dhcpcd, networkmanager, etc to configure interfaces: rc_need="servicename" #If they want to use stunnel, they can add: rc_use="stunnel" What are your thoughts?
Also, if they use include files in /etc/syslog-ng/syslog-ng.conf, they can add: rc_config="file1 file2 file3 ..." where the file names are full paths.
Are there any objections to this init script and possible updates to the conf.d file? If not, can I have permission to do the updates myself 24 hours from now?
Created attachment 332524 [details, diff] fix.patch This patch is a significant rewrite of the init script, and also documents one way to configure network logging in the syslog-ng conf.d file.
The patch in comment 25 works (quite) well for me. I have set: rc_need="net.eth0" in /etc/conf.d/syslog-ng I'm still having a problem with syslog-ng binding to an IPv6 interface during boot up. What is strange is that once the machine has finished booted up, syslog-ng then is able to start up without error. The error as logged on the console is: [Routes added above here, both IPv4 and IPv6 and static routes] * Checking your configfile (/etc/syslog-ng/syslog-ng.conf) ... * Starting syslog-ng ... Error binding socket; addr='AF_INET6([2001:44b8:3333:1310::20]:514)', error='Cannot assign requested address (99)' Error initializing source driver; source='net', id='net#0' Error initializing message pipeline; * start-stop-daemon: failed to start 'syslog-ng' * Failed to start syslog-ng * ERROR: syslog-ng failed to start * Starting clamd ... tornado syslog-ng # ifconfig eth0 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000 inet 192.168.10.20 netmask 255.255.255.0 broadcast 192.168.10.255 inet6 fe80::a236:9fff:fe00:f4aa prefixlen 64 scopeid 0x20<link> inet6 2001:44b8:3333:1310::23 prefixlen 64 scopeid 0x0<global> inet6 2001:44b8:3333:1310::22 prefixlen 64 scopeid 0x0<global> inet6 2001:44b8:3333:1310::21 prefixlen 64 scopeid 0x0<global> inet6 2001:44b8:3333:1310::20 prefixlen 64 scopeid 0x0<global> ether a0:36:9f:00:f4:aa txqueuelen 1000 (Ethernet) The console also shows that this interface along with all the IP addresses as above does start prior to syslog-ng. If I start syslog-ng manually after the machine has completed booting it works without error and listens correctly on this IP. Now I *think* this may be an issue that needs to be taken upstream but I'd like confirmation of this first. Then again, it shouldn't matter where in the init this service is started provided the relevant interfaces are up, should it? Apart from that issue, the latest proposed patch makes the configuration clearer and (otherwise) everything works well.
I guess the address is in tentative mode at the time and binding to tentative address is refused by kernel. Try investigating `ip addr show' output close (a few seconds) to the syslog failure.
Spot on Petr - I think you're right. Here's the (truncated) output of 'ip addr show' immediately before syslog-ng starts up: 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 9000 qdisc mq state DOWN qlen 1000 link/ether a0:36:9f:00:f4:aa brd ff:ff:ff:ff:ff:ff inet 192.168.10.20/24 brd 192.168.10.255 scope global eth0 inet 192.168.10.21/24 brd 192.168.10.255 scope global secondary eth0 inet 192.168.10.22/24 brd 192.168.10.255 scope global secondary eth0 inet6 2001:44b8:3333:1310::23/64 scope global tentative valid_lft forever preferred_lft forever inet6 2001:44b8:3333:1310::22/64 scope global tentative valid_lft forever preferred_lft forever inet6 2001:44b8:3333:1310::21/64 scope global tentative valid_lft forever preferred_lft forever inet6 2001:44b8:3333:1310::20/64 scope global tentative valid_lft forever preferred_lft forever Note "NO-CARRIER" on eth0, and "tentative" on the IPv6 addresses. At the end of the init script execution, link is up, and the addresses are no longer tentative any more. Presumably this is why this is no longer a problem. Given this is an Intel I350T2 card, I wonder if there is some delay before the port comes up properly. From a switching perspective both ports are set to access and spanning tree portfast is set (Cisco 3560-X) so I don't think it's the switch that is delaying things. I guess the key question is, in terms of this bugzilla entry, is this something that the init script for syslog-ng should be acting to workaround? Should the init script for syslog-ng be waiting briefly until link actually comes up and the addresses are no longer tentative before attempting to start, on account of IPv6 addresses bound to it not being available till some time later?
I remember I saw checks for tentative addresses in OpenRC net.lo script making net.* service available only after all(/any?) IPv6 addresses became DAD-verified and thus not tentative any more. I don't know if this is still true. AFAIK OpenRC has an option whether to wait on IP address on not. Thus I conclude net.* should wait on at least one address if the option requires an address. However any network daemon should be aware that bind can fail and especially in case the daemon auto-discovers new addresses at run time and binds to each of them separately it should cope with tentative addresses gracefully.
Going by the following two commits: http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git;a=commitdiff_plain;h=807e5d725086832b899ba03a2203824ecf296d8b http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git;a=commitdiff;h=444bdfbfc4d1a336233ccc5a29495cc1f523b5a3 and this bug report: https://bugs.gentoo.org/show_bug.cgi?id=433012 It looks like the problem is something in iproute2.sh which if I'm reading this correctly should not be allowing the boot up to proceed until the addresses are no longer tentative and linked up (my output above shows no carrier, yet openrc proceeds nonetheless). If this is the case then I'm thinking it's a problem with openrc and not syslog-ng. I would appreciate if someone can confirm. If my suggestion is right then I have no other issues with the proposed patch.
try it with syslog-ng-3.4.1 please.
the latest update seems to have corrected the issue for me. i rebooted my server and my remote hosts still log properly
use syslog-ng 3.4.x
I've updated to syslog-ng 3.4.2. Added 'rc_need="net.net0"' to /etc/conf.d/syslog-ng, according to comments there. Syslog-ng starts now. The solution seems satisfactory for me (as I have no need to stop net.net0).
