Ah that explains why I’ve not seen this crop up in previous builds, so not a regression.
I think forcing the error state here was a good call, at least it’s visible now and we can catch the preceding logs.
For now I’ll disable the dns plugin which is erroring out and causing the collectd restart.
If i find any other state changes that trigger the respawn I’ll report back.
As always, thank you
can you post the error for the dns plugin? + 'uci show luci_statistics | grep dns'
cheers 
dns-plugin inclusion was marginal... kinda useful when the dnsmasq bugfixes were going on... but enabling for all builds was probably beyond what i'd personally / guess majority of users would enable...
i'll disable the 'beta' autosetup for that I think ( leave it up to the user to manually enable )... unless anyone else has input...
Ah I don’t have persistent logs at the moment and rebooted to fix the last sqm script respawn. (I’ve not gotten around to piping them out to influxdb)
I’ve just re-enabled the dns plug-in and will catch the logs for you next time I see the sqm data drop off
this may work better (end prev/running duplicates)...
I had issues the first time as sqm_collectd.sh runs as nobody... ( hence the 2 spawn limit )
curl -sSL "https://raw.githubusercontent.com/wulfy23/rpi4/master/utilities/sqm_collectd.sh" > /usr/libexec/collectd/sqm_collectd.sh
Nice! I'll pull this down once I've caught collectd_dns misbehaving and give it a shot
wireguard users are advised that for the 101(r16076) build, I needed to remove 'wireguard' as the package did not exist... ( kmod and related packages are all included... I think the above was just a previous wrapper package? )
remember reading something somewhere about it being 'in kernel' in the future but thought that may have been from 5.10 onwards... which we are not on yet...
could be a wrapper rejig and wireguard is perfectly fine... could be an interim state...
Just have to ask and here is probably the right place to do so. In the upcoming OpenWRT 21.02 release is there a official Rpi support? And if so does it make building and maintaining easier?
yes
stable~reliable.... you wont get package incompatible with kernel errors or have to adjust customisations based on a moving target...
easier is subjective...
Finally happened again today,
Here's the output of logread -e collectd > collectd.log
Looks like there have been multiple respawns of collectd (I count 13) - it seems the last respawn before the more than 2 logs didn't exit normally, and is missing the following:
daemon.err collectd[2751]: Exiting normally.
daemon.err collectd[2751]: collectd: Stopping 2 read threads.
daemon.err collectd[2751]: collectd: Stopping 5 write threads.
These preceded the prior collectd restarts, but not for the one that appears to have multi-spawned sqm_collectd.sh
Here's the output of uci show luci_statistics | grep dns
luci_statistics.collectd_dns=statistics
luci_statistics.collectd_dns.enable='1'
luci_statistics.collectd_dns.Interfaces='eth0'
luci_statistics.collectd_dns.IgnoreSources='127.0.0.1'
luci_statistics.collectd_processes.Processes='uhttpd dnsmasq dropbear'
It does seem that the errors I saw thrown previously by the dns plugin were bad timing and possibly unrelated as they're not thrown here.
Let me know if there's anything else I can dig into!
Cheers
edit: grammar...
Just pulled this down (with multiple sqm_collectd.sh's running) and restarted collectd:
sh /etc/init.d/collectd stop
sh /etc/init.d/collectd start
Can confirm this killed the other instances logging has resumed
freikfunk feed has been removed from master I believe... this probably wont be present in newer (factory) distfeeds.conf files...
as these are carried across within sysupgrade data... users of existing builds are advised to disable the feed in '/etc/opkg/distfeeds.conf' preferrably prior to any upgrades (or if you restore a backup) as it will likely bork autorestore functionality;
#src/gz openwrt_freifunk https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a72/freifunk
Hi.
I've been pushing my rpi 4 a little too much with multiple jobs all over the day and I would like to overclock it.
However, when I try to do it, it appears the frequency does not change.
Isn't it enough to set in /boot/config.txt the lines:
over_voltage=3
arm_freq=1600
Thanks in advance
due to the various risks and complexities involved with overclocking...
on this build... the preferred method to 'overclock'(and 'underclock') is by tweaking the governor ( runtime within OS )...
/root/wrt.ini
POWERPROFILE="quickest"
try the above... ( check there is not a value already assigned i.e. a line that is uncommented... I may have set 'quick' as the default recently... cannot remember )
( in which case change that or duplicate and comment it out )
after changing this setting to apply without rebooting run;
/bin/rpi-perftweaks.sh
fyi, as your sending your collectd stuff to a server... technically you could/should do without the 'persistentlucistatistics' feature...
alas... I haven't cleanly checked/implemented a clean way to do this currently... i'd assume adding SERVICESDISABLED="persistentlucistatistics" to wrt.ini and commenting out the existing line in /etc/crontabs/root
# 0 */6 * * * /etc/init.d/persistentlucistatistics psave
/etc/init.d/persistentlucistatistics disable
/etc/init.d/cron restart
would be the logical way to do this... but probably better to not bother for a few builds (or at all if the workaround is ok)... I may get the chance to test/tidy over the next few builds...
basically... what these do is
hoping the 'end-existing' workaround largely resolves the fundamental issue for now ...
you can disable that cron script... although the firstboot logic may put it back each upgrade...
The next overclocking options will work if you have a good power source and enough cooling, of course:
# Overclocking to 1.75GHz
over_voltage=2
arm_freq=1750
# Overclocking to 2Ghz
over_voltage=6
arm_freq=2000
# Overclocking to 2.174GHz
over_voltage=6
arm_freq=2147
gpu_freq=750
Mine is running at 2Ghz for different reasons, since 8 weeks ago. If what you need is a quick ramp up of CPU frequency just go with @anon50098793's governor tweaks.
Is this installing rng-tools? Or, is it just executing echo 3800 > /proc/sys/kernel/random/write_wakeup_threshold? Pure curiosity.
yeah... it's a bit of an odd one... rngd/rng-tools@/dev/urandom seems to be the sweet spot... ( i'm sure something whacky gets switched out at a lower level )
$ecmd "hardcode workaround setting to urandom seems to sync all 3"
uci set system.@rngd[0].device='/dev/urandom' #NOPE uci del system.@rngd[0].device='/dev/urandom'
uci commit system
/etc/init.d/rngd enable; /etc/init.d/rngd restart
uci show system | grep rng
system.@rngd[0]=rngd
system.@rngd[0].enabled='1'
system.@rngd[0].device='/dev/urandom'
I will swap /dev/urandom with /dev/hwrng in the RPi4 and disable default urngd if you are up for a quick test. 
yup... pretty sure that's what I attempted first... but for some odd reason... doesn't seem to kick in properly...?
(edit: didn't test after this tho... may have helped the situation?)