procd_lock problem starting background script from sqm itself
i've spent the last few hours on it and thought it was fixed but have not nailed it yet...
maybe someone else knows what's going on... basically when the autorate script is spawned via sqm itself... (child process or something?) it hangs procd_lock() (so no subsequent stop/start/restart actions will run) maybe because it never exits or something...
starting it manually is ok... so i'll probably give up trying to start/restart from sqm soon unless someone knows a way around the lock problem...
and create a separate 'service' that spawns the autorate.sh scripts themselves... (and associated hotplug / other background detection of sqm service state change / reload sort of thing)
edit: updated the tar file to include a service 'autorate'
if you unzip the tar from '/' and enable and start the service;
you can test it out... but it's very rough still in how it logs things etc. etc. ( it just runs sqm-autorate-init.sh start and sqm-auto-rate-init.sh stop but in silent mode... if you don't see something in ps wwww | grep autorate then just try those commands to start it yourself and see whats going on... it also has 'status' )
will likely take a week or so to properly iron out all the bugs...
I am curious how you managed this. Did you put in restart call within the sqm service script? I wondered about that to address changes in sqm caused by interface going down and hotplug even restarting sqm, which should then restart the autorate service.
@Nomid are you presently using this community build for your funky RPi4 LTE setup? And how are you managing SQM for that? I am wondering about getting RPi4 myself like you have done. To replace my B818-263. Thing is the B818-263 works pretty well - with location optimisation (on its side next to window), I get these amazing stats:
yeah, i've seen this too (r18161)... thought it was due to some things i've been working on maybe... (nothing major really mostly the autorate stuff)... will run some test builds today with 'stable(edit:done r18086 is working ok)'+'next(edit: done r18217 worked ok)' and the current file mods to try to pin down where it's coming from...
edit: re-testing with r18161 first worked and then didn't which could mean the above tests are now void and need to be repeated more thoroughly... (bugger)
for a workaround you can ssh in and run /etc/init.d/rpcd restart
Just a general report, I've gone backwards to stable after experiencing inherently average network performance. I can't put my finger on it, but the network would "stall" and then come back to life consistently. Going back to stable has rectified the issue. I can't guarantee it was the firmware, but just thought I'd report f anyone else has similar issues.
Just installed fresh this week on rpi4. One issue I have is if I issue a reboot takes 50 mins or more for the internet to come back online. I'm using ue300 dongle for lan and on board nic for wan. It's dhcp to fiber modem in bridge mode.
best to start by stating which build version you are running... and any other customizations that may be relavent...
this is good info... perhaps stating the ISP(company name) and modem version(model name) would also be relavent here...
probably a good time to remind peeps that 'current' is pretty experimental right now and has some known quirks (on my system they are relatively minor and managable but ymmv)
i've sort of been cheating for a while on github re: master version and only uploading the 'testing/current' so new users who have been downloading from github get 'current/testing'
this has generally been ok... but since r1806x-ish immediate downgrade/flash to 'stable'/'release' would be advised... (added benefit that your ROOTFS is expanded on the first upgrade anyway)
NOTE: the built in initial wrt.ini has UPGRADEsFLAVOUR set to 'stable' so you'd be prompted / track 'stable' if you click flash or check for updates[refresh] or whatnot anyway...
fyi... one upcoming feature that's been added worth mentioning, especially for people who might plug alot of external disks...
i've added a 'quasi' debian like /dev/disk-by linker...
it's mostly for show really and only really functionally useful for a quick look or manually mounting and unmounting from a command line (temporarily would not rely on it for anything automated just yet) but has potential to be expanded to do a few fancy things such as autobackups or restores and whatnot (disk hooks)
I am using "rpi4.64-21.02.1-27006-1.0.7-3-r16325". No other customizations really.
After some more digging. Every reboot grabs a new dhcp ip seems like behaviour might be starting from 21.02? I think perhaps my ISP is slow to allow a newly provisioned wan ip to route? I have a ticket open with them to investigate. I am coming from ubuiqiti edge router and it keeps the dhcp wan ip on reboots.
What would be the latest stable release? (maybe latest 19.x ?) I will switch to that and report findings.
i'd say the build you are on is best right now... especially for the issue described... (and it's technically also the latest stable release)
definately see what the isp has to say about what's going on... i've not come across a situation where openwrt receives valid wan addresses and won't route (but once had an issue on another device where all addresses were up but could not get traffic past the isp gateway but as mentioned it was a different device and quite a while ago but sound similar to the sort of issues you are experiencing)
Wulfy23: is there a cron job for automatic rebooting or software updating preconfigured?
Because I am experiencing Internet breakup at around 6am or few minutes before that. After may be some 5 minutes that Internet is there again!!!
Is it only with me or known bug?
I am on latest stable release from you ( not snapshot).
ok... so your asking about any recurring automated stuff in the build...
(note: most things that happen in the build log something... so the quick answer to your question is just to check logread and dmesg from after this occurence once or twice)
it's a good question actually...
of course these things might vary depending on what INI options are enabled and whatnot... but it's good to give a brief overview of them anyway...
there is a cronjob that saves the above data every... need to check... probably 3-5hours... initially it worked really well without cronjob (had a shutdown hook) but if power suddenly is lost it didn't capture stuff so a cronjob was implemented...
there is a cronjob that saves the logread ringbuffer...
there are two cronjobs, backup/tasks which don't really do anything... (but the latest build has an updated tasks that works)
well, well, well I though most of the jobs would be around midnight-3:30am but looking at my crontabs... the 'not working' backup/tasks are right on 5:59am (mondays only maybe)...
In case this is helpful my LTE modem drops eth0 (NO-CARRIER using ip monitor) about every 48 hours as is apparent from checking the modem log and this needs to be detected and managed. Think this means udhcpc kill commands to release and renew.
On my RT3200 using the recent snapshots this is already correctly handled.
I wrote this script for Asus-Wrt Merlin:
ip monitor link dev eth0 | while read event; do
logger "maintain-wan-lease detected eth0 event: "$event
case $event in
if [ $renew_wan_lease -eq 0 ]; then
logger "maintain-wan-lease detected eth0 state change to: 'NO-CARRIER', so forcing udhcpc to release wan lease."
killall -SIGUSR2 udhcpc
if [ $renew_wan_lease -eq 1 ]; then
logger "maintain-wan-lease detected eth0 state change from: 'NO-CARRIER' to: 'LOWER_UP', so forcing udhcpc to renew wan lease."
killall -SIGUSR1 udhcpc
This meant keeping my internet connectivity after the modem refreshes. Whereas otherwise internet connectivity would be lost until reboot.
May be worth just ruling this out.
Alternatively could this behaviour explain the constant refreshing IP?
be my guest (from a purely investigative perspective...) but keep in mind...
a) those jobs don't really do anything
b) you'll probably have to do it again after your next upgrade... I have some INI variables to turn that stuff off... but they need more testing... and as those jobs don't really do much... it hasn't been a priority as yet... (however in the new builds with the fixed tasks... there will be a NOTASKS or something like that which will work)
c) commenting out/removing any line with psave may interfere with luci-statistics / nlbwmon / logs if you lose power (someone who is uber paranoid about sdcard writes like if your router is in antarctica or something might benefit from those being switched off)