Well, turns out I made a big newbie mistake. Changed the init.d script start priority, but failed to clear out the rc.local script. The init.d script instances both go into a crash loop, but the rc.local runs which gave me a false assurance issue was resolved.
I apparently don’t read so well either. @dl12345 gave me what I needed to answer most of what my last post requested, soooooo off I went down the rabbit hole.
I found service_trigger()
, RESPAWN parameter, procd.sh, rc.common, functions.sh, PROCD_DEBUG=1
, and INIT_TRACE=1 /etc/init.d/softflowd $action
all involved in the process.
Putting it all together I was able to determine the softflow init script was properly populating the command line And the rc.common wrapper was properly responding to the /etc/init.d/softflowd $action
command.
I added PROCD_DEBUG=1
to the script and as sparse as it’s output is, it reinforced my conclusion through my step-through of the softflowd init script, config, and rc.common that the fault wasn’t arising there.
So, I tried INIT_TRACE=1 /etc/init.d/softflowd start
to see if I could glean anthything from that. Way beyond my abilities!!!!!
So I configured a third interface in the softflowd config, echoed the procd_set_param command
values and did a straight CP into rc.local. It all works - big sigh.
Then I remembered the inference that it could be the snapshot build I was using.
I went back to my previous build on the other partition, installed softflowd, copied the config file from my latest build and ran it. All three interfaces loaded without a hitch. Going a little further, I ran diff
against the config, init script, rc.common, procd.sh, functions.sh, verified checksum match on the binaries. Identical between the builds.
Arghhhh!!!
[quote="lleachii, post:13, topic:67755"]
I've only had issues like that on snapshots
[/quote]. It isn’t the SOLUTION it’s the CAUSE
All in all it’s been a good exercise. I got good advice, helpful insights, and challenges. I’ve learned a lot and have a much better perspective of the whole process but I won’t be writing any init scripts anytime soon. rc.local works in the interim, and I’m attempting to use @dl12345’s script as a foundation to try and accommodate 2 instances. Thanks all. It’s been enlightening.
On a final note, I was surprised at the router cpu utilization impact even with 4 flows running (I like to push the envelope at times). Significant spikes when flows expired, but otherwise little overall. The monitor station on the other hand was put to it’s knees trying to handle the flow data from 4 flows.
As well, the softflowd init script appends what appears to be a superfluous iteration of the -p pid parameter at the end of the generated command
softflowd -d -v 5 -i tun0 -n 10.10.1.100:5556 -c /var/run/tun0.ctl -p /var/run/tun0.pid -T full -p /var/run/tun0.pid
with
procd_set_param command /usr/sbin/softflowd -d $args${pid_file:+ -p $pid_file}
Removing ${pid_file:+ -p $pid_file}
has zero effect and doesn’t make sense at least to me.