I set up an old dual boot laptop that was gathering dust with PRTG and dedicated it as a network monitor mainly to monitor SNMP stats from the router along with additional sensors monitoring certain aspects of other connected devices, and it’s worked quite well.
I was looking for a bit more granularity specifically to traffic so I set up a netflow sensor in PRTG to look for netflow data on routerIP:5555 and installed softflowd and nfdump.
I use softflowd to export flows into an ELK stack where I use Elastiflow to give me nice pretty dashboards. For some reason (I can't remember why as I set it up literally years ago), I don't use the init script that ships with the package. It might be that the switches it uses didn't work for me.
Remember, though, that you need to leave it running for a while before it expires flows and sends them to the server. It won't happen immediately.
EDIT: if you use this script just remove the line with taskset on it. I have a multi-core router, so I use this to pin softflowd to the second core. It uses a lot of machine resources on gigabit links
That was another question I had “can I offload to cpu2”, but first things first - get it running.
Your script caught my eye with reference to the softflowd.ctl file. It just doesn’t get created. Something to look at.
It won't happen immediately.
2 hours now and naught.
Seems that’s now three of us with the same conclusion - it doesn’t complain, but it sure doesn’t work per the docs.
Thank you kindly for your pointers and scripts. Gives me some focus as to where to look. My brain is getting so fried trying so many different approaches to get it working that I’m repeating previous failed attempts
You can pin a process to a specific core with the taskset utility, which is part of util-linux, although it's not included in Openwrt. You can add it with this patch (which also adds the renice utility, another useful thing)
but, it won't run in anything other than debug mode (-D Command line switch). All the other CL options match correctly to the /etc/config/softflowd config file.
Setting it to run as a daemon on boot puts it into a crash loop. ie
Reboot router
Verify daemon status
root@MyDomain:~# /etc/init.d/softflowd status
running
Verify the socket is created
root@MyDomain:~# ls -ltr /var/run/soft*
srwxr-xr-x 1 root root 0 Jun 26 10:59 softflowd.ctl
root@MyDomain:~# logread -e softflowd
Fri Jun 26 10:12:37 2020 daemon.info procd: Instance softflowd::instance1 s in a crash loop 6 crashes, 0 seconds since last crash
Fri Jun 26 11:35:19 2020 daemon.info procd: Instance softflowd::instance1 s in a crash loop 7 crashes, 0 seconds since last crash
Fri Jun 26 14:49:20 2020 daemon.info procd: Instance softflowd::instance1 s in a crash loop 6 crashes, 0 seconds since last crash
So
root@MyDomain:~# /etc/init.d/softflowd stop
root@MyDomain:~# /etc/init.d/softflowd status
inactive
Both @lleachii and I use almost identical command line options and neither of us use the -D flag and it seems to work fine this way. I also get the softflowd.ctl file created
root@openwrt:~# ls -l /var/run/soft*
-rw-r--r-- 1 root root 5 Jun 12 02:01 /var/run/softflowd.pid
srwxr-xr-x 1 root root 0 Jun 12 02:01 /var/run/softflowd.ctl
If you really want it controlled by procd just use the script I posted and change the block
Incidentally, you almost certainly don't want to run multiple instances. It's a real resource hog. On a gigabit flow it uses a substantial amount of CPU
Yes, I understood what you were saying - just invoke the instance through rc.local and be done with it. Unfortunately, I'm a bit of a mule when it comes to things that don't work. I am currently using your workaround in fact until I can figure out why it doesn't work in daemon mode (crash loop).
The config "enable" switch was set to 1 in the config so when the process initially was called, it set it up to run as a daemon on boot (init.d). It was running as a service so it needs to be explicity referenced to control the service. No messing with init.d to run it from CLI, rather only to control the already existing process.
Reboot router
Verify daemon status (init.d)
Verify the socket is created (init.d)
Check that the socket is collecting
Stop the process (init.d)
Verify the process is stopped (init.d)
Invoke the process from CLI in debug mode to watch process on stdout
That's what started this whole thing Gents.
Invoking it from /usr/sbin by starting it with 'softflowd' on the command line, will use the /etc/config/softflowd - doesn't work.
Invoking it from the command line without the -D switch - doesn't work @dl12345 's modded script works @lleachii 's rc.local example works
Invoking it from the command line with the -D switch - works
Very,very true. Just noting the docs say it is so.
...I'm not sure why you don't option enabled '0'...(I guess that's the in you so OK).
Try a stable release of OpenWrt and see if it happens. I've only had issues like that on snapshots (and it changes from one release to the next, so upgrading snapshots may work too).
It was simply copy/pasted from the online docs, where it is boldfaced.
The post was a comment to @RuralRoots that a procd service isn't meant to be run in the background anyway, since he's been talking about it not working when run in the background.
Just for my own information, I wanted to see the impact of adding additional flows so I added another flow to the rc.local and performed a re-boot. Only the first flow shows up in ‘top’ - ????
I added echo commands into the rc.local to track the process and logread -e “echo-value” sure enough indicates clearly both instances were invoked, but again only the first instance appears in the process tree - ?????
Finally logread -e “instance2 interface-name” returns “instance2 interface-name” doesn’t exist (yet).
Adding sleep 1m before instance2 in the rc.local fixed that and all is good.
So, I turned my attention to the init.d script and the first thing that hit me was that it had a start priority of ‘50’. It was running prior to the existence of the target interface and thus failing. Changed start priority to ‘99’ and all is good - I see both instances in ‘top’ and both collectors are now receiving data.
So, my original issue is solved - thank you all for adding to my personal KB.
Now, I’ve come across another issue - same subject.
Occasionally the instance2 interface restarts based on ‘some’ trigger and instance2 terminates. Is there any way of re-invoking instance2 based on an IFUP of the instance2 interface? In the case of this particular application at least, it would make sense to start the flow acquisition whenever the target interface comes up.
I am also coming up with a dearth of information relating to script interpreters - softflowd script for example uses rc.common as it’s interpreter. Any hints where I can find out more how parameters are passed, placeholder variables get their values, interpreter syntax, . . .
Effectively, I would like to learn how to “step through the process flow if that makes sense.
in you 
so OK).