On my (OpenWRT) router, I have an "/etc/init.d/shorewall-lite restart" (which effectively is shorewall-lite restore) executed during an "interface transition" (i.e. up/down) event. This is to allow shorewall to adjust the rules and/or routing when an interface changes state. TBH, I don't so much care about the interface down event as much as I care about an interface coming up when shorewall was restarted with an interface being down. But I digress.
The ugly side effect of this is that when the router initially boots, lots of "interface up" events are triggered and thus many "overlapping"/parallel shorewall-lite restore commands are run. This is silly of course[1]. My knee-jerk reaction is to simply have shorewall-lite exit if there is an instance running already, but given more thought, that seems backwards. The earlier instance might have already assessed the interface for which the new instance is being called and thus, the earlier instance has a stale view of the interface status. So it seems the right thing to do is for the new instance to kill the earlier instance before it (the new instance) starts doing it's thing. This would continue to happen until the last of the initial boot "interface up" events runs to completion. Thots? b. [1] It might seem pretty harmless to have a number of parallel executing shorewall-lite restore processes running given that I recall seeing some locking/timeout code in there to prevent more than one from actually going through their processing in parallel but on a limited memory machine, it would seem that the effect of this is ooms. :-(
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
