From what I read this indicates a maximum process limitation, not something I can reproduce on my end though so it must be unique to the AC86U. Try update to v5.4.2
If its still causing issues, I'll have to see if I can manually increase this limit (and find out what it currently sits at).
You can ignore that failed message, above it there was probably a notice that there was a locked process meaning Skynet hadn't fully booted up. This takes 20-40 seconds.
As for the error, the process limit is slightly lower on the AC86U. Try force update and see if the patch I just uploaded makes a difference, I increased this number to 3000.
Interesting that the fix worked for you and not @.TT. ... Maybe when he updated it hadn't propagated on githubs servers yet so he only got the old version still?
Also that run time is damn fast on the AC86U 12s vs 40s on the AC68U
@.TT. try run the force update command again and see if it works.
@RMerlin Any ideas on this one? I can't find the specific error online, but those types of errors seem to point to process/resource limitations. I see a post from 2016 where you mention this could be a ram limitation, but considering the AC86U has twice that of a AC68U I doubt its running out. At its peak the script only increases ram usage by 20MB for around 2 seconds.
With that being said, this error is unique to the AC86U, all other models have no problem running the function. The code specifically causing the issue on this model is;
Code:
cd /tmp/skynet || exit 1
while IFS= read -r "domain"; do
/usr/sbin/curl -fs "$domain" -O &
done < /jffs/shared-Skynet-whitelist
wait
Which basically just downloads a list of 32 small files in parallel. Is there some sort of limit possibly that was increased in the old codebase?
There's just too much that got changed with this new platform, and I don't fully understand even half of it yet. Sometimes it causes weird issues such as the iptables one that I fixed earlier this week (I actually sent that fix upstream to Asus since it seemed potentially serious). That was was caused by GCC > 4.7.
I know that there's a problem related to the toolchain and forking that affected Asus's own code as well (the router would suddenly fail to fork() anything, it was a large part of what made the GT-AC5300 half-unusable during its first few months on the market). All they told me is there was a bug in the BCM toolchain, and they had to work their way around it. I was unable to obtain any further details when I asked them. Maybe the same issue is also affecting you, or it could be something different. The symptoms do look similar (failure to fork() ).
There's just too much that got changed with this new platform, and I don't fully understand even half of it yet. Sometimes it causes weird issues such as the iptables one that I fixed earlier this week (I actually sent that fix upstream to Asus since it seemed potentially serious). That was was caused by GCC > 4.7.
I know that there's a problem related to the toolchain and forking that affected Asus's own code as well (the router would suddenly fail to fork() anything, it was a large part of what made the GT-AC5300 half-unusable during its first few months on the market). All they told me is there was a bug in the BCM toolchain, and they had to work their way around it. I was unable to obtain any further details when I asked them. Maybe the same issue is also affecting you, or it could be something different. The symptoms do look similar (failure to fork() ).
That's a bummer. I'll disable the parallel downloads for the time being on the AC86U, not sure if it affects other models on the .382 codebase but if it does I will disable it for them all. Hopefully Asus find the cause in the next few GPL drops (or document how to avoid it).
@.TT.@SeaConn this change is live in v5.4.3. Unfortunately it will be slightly slower on the "Consolidating Blacklist" step, but at this time its unavoidable. Thanks again to you guys for helping me work the bugs out of the new platform. Hopefully I make some progress in the near future contacting Asus.
This is really strange, especially now the issue is occurring during single download. Seems like its curl in general causing the issue?
Perhaps updating to 7.56.1 would resolve the issue @RMerlin
EDIT; It actually looks like RMerlin ported over the curl 7.54.1 from the AM380 codebase, as Asus have curl-7.21.7 by default which is even older again. Maybe that's where the issue lies