Summary: | net-firewall/shorewall-common-4.2.11-r1: rc-status not shown as "started" | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Boney McCracker <brendlerjg> |
Component: | Current packages | Assignee: | Tony Vroon (RETIRED) <chainsaw> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | burcheri.massimo+bugs-gentoo, netmon |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | bootchart (svg) |
Description
Boney McCracker
2010-04-17 15:02:59 UTC
twister ~ # rc-status Runlevel: default dnsmasq [ started ] ez-ipupdate [ started ] hydrophone [ started ] ipset [ started ] local [ started ] net.eth0 [ started ] net.eth1 [ started ] net.eth2 [ started ] ntpd [ started ] samba [ started ] shorewall [ stopped ] <---- Note sshd [ started ] syslog-ng [ started ] udev-postmount [ started ] uptimed [ started ] vixie-cron [ started ] John, from what I see now, somebody had managed to include a "use logger" dependency in net-firewall/shorewall-common-4.2.11-r1. Since you are using syslog-ng, could you manually comment out "need net" from within the depend() function in /etc/init.d/syslog-ng and see if the inconsistency persists? Also, which openrc version are you using, and are you using the "rc_parallel" or the "rc_depend_strict" option in /etc/rc.conf? (In reply to comment #2) The "net" dependency of syslog-ng is conditional upon the presence of "net" or "udp" in one or more uncommented syslog-ng.conf "source" or "destination" statements. I have two such statements, but they are commented-out. The relevant portion of /etc/init.d/syslog-ng: ------------------------------------------------------------------------------ # 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 use stunnel ;; esac ------------------------------------------------------------------------------- So, to implement your suggestion, I have commented out the entire block of code shown above and rebooted the machine. Unfortunately, it seems to have had no effect: ------------------------------------------------------------------------------- twister ~ # rc-status Runlevel: default dnsmasq [ started ] ez-ipupdate [ started ] hydrophone [ started ] ipset [ started ] local [ started ] net.eth0 [ started ] net.eth1 [ started ] net.eth2 [ started ] ntpd [ started ] samba [ started ] shorewall [ stopped ] <---- :( sshd [ started ] syslog-ng [ started ] udev-postmount [ started ] uptimed [ started ] vixie-cron [ started ] ------------------------------------------------------------------------------- I have the uneasy feeling this is due to some configuration error of my own (i.e. PEBKAC), so I will keep looking at it. If no one else has reported this, it must be me. Thanks for the suggestion, though. (In reply to comment #2) > Also, which openrc version are you using, and are you using the "rc_parallel" > or the "rc_depend_strict" option in /etc/rc.conf? As noted above, I am not using openrc on this machine. This is a baselayout1 machine. It is ACCEPT_KEYWORDS="x86" (not "~x86), except for those keyworded packages noted above. However, in /etc/conf.d/rc (which roughly corresponds to /etc/rc.conf on an openrc machine), potentially relevant variables are: RC_PARALLEL_STARTUP="no" RC_HOTPLUG="no" RC_COLDPLUG="no" RC_PLUG_SERVICES="!*" RC_NET_STRICT_CHECKING="yes" Created attachment 228705 [details]
bootchart (svg)
Here is a bootchart for the system (a firewall/router running on a Pentium III).
As you can see, syslog is starting before shorewall, but it is not causing the net.* services to do so. It all seems to be starting in the proper sequence.
ipset
shorewall
network interfaces
network-dependent services
They mystery is why the rc system says shorewall is "stopped" when it's not.
*** Bug 316327 has been marked as a duplicate of this bug. *** Tom Eastep said he is going to consider implementing a two-stage startup approach similar to SuSEFirewall for 4.4.10, in order to conform to the Gentoo police. I hope for this reason that this version is going into Portage soon, given that Portage is still on 4.2. Seems to be fixed from version 4.4.10+ |