I noticed that with the alpha build that my ram usage spikes to 97% when installing skynet. Usually that doesn't happen until after 3 or 4 days of not rebooting. After a reboot my ram usage normally goes back down to 47% or 50%. Ram usage is normal when using 384.14.
I noticed that with the alpha build that my ram usage spikes to 97% when installing skynet. Usually that doesn't happen until after 3 or 4 days of not rebooting. After a reboot my ram usage normally goes back down to 47% or 50%. Ram usage is normal when using 384.14.
Thanks for the link, I think I've read this before. I was just wondering since usually after a reboot ram usage goes back down to about half of what it is now. I ran skynet with the previous alpha build for 14 days without rebooting with the ram at 97% without any problems. Thank you for a great program.
???????????
I just noticed this when my wife followed a link to the site and it loaded. Alibaba doesn't load, so not sure what's going on here. Unless ChinaDaily.com.cn is hosted on some other country's IP space?
???????????
I just noticed this when my wife followed a link to the site and it loaded. Alibaba doesn't load, so not sure what's going on here. Unless ChinaDaily.com.cn is hosted on some other country's IP space?
???????????
I just noticed this when my wife followed a link to the site and it loaded. Alibaba doesn't load, so not sure what's going on here. Unless ChinaDaily.com.cn is hosted on some other country's IP space?
At least for me (in US, using Comcast DNS), global.chinadaily.com.cn resolves to 153.185.145.162. That IP is hosted in the US, according to iplocation.net info.
???????????
I just noticed this when my wife followed a link to the site and it loaded. Alibaba doesn't load, so not sure what's going on here. Unless ChinaDaily.com.cn is hosted on some other country's IP space?
[RESOLVED] So I'm still having startup issues, at least I know what it is now. I have a race condition preventing skynet from starting. It always in the end detects a locked file and stops trying to start. If I ssh in and run the restart skynet from the ssh menu it will work. So I know it's a race condition, with what I have no idea the logs don't show anything wrong. Just after a reboot when I can login I see locked file detected.
My software environment is Skynet, Diversion and AMTM. I have the latest Alpha installed on my AX88U. I use DNSSEC and DoT, no time server, I use my ISP DNS at startup, I don't have a dnsmasq.conf.add file (not required here). I can't figure it out. I have a OVPN Server and OVPN Client set to start at reboot.
I should add that Skynet starts but has problems. SSH access shows that IPtables failed. I'm thinking because of a time sync in the race condition situation. As I said if i wait until Skynet half starts (without IPtables) then I ssh in and restart and it all works.
I should add that Skynet starts but has problems. SSH access shows that IPtables failed. I'm thinking because of a time sync in the race condition situation. As I said if i wait until Skynet half starts (without IPtables) then I ssh in and restart and it all works.
Please post or pm an extract of your syslog. There are only 3 places Skynet can fail during startup and all three have syslog output (NTP failure, USB error or connection error).
Please also post the full output of debug info while its "broken".
So its just the IOT rules which are missing that are based in the Forward chain in the FILTER table. During Skynets startup procedure there appears to be a restart 16s prior to it finishing triggered by AiMesh(?) which is flushing the IPTables ruleset;
Code:
Jan 19 05:26:02 rc_service: amas_lib 1456:notify_rc restart_firewall
I'll have to investigate further as to what triggers this restart event and the best way to work around it beyond increasing the delay.
So its just the IOT rules which are missing that are based in the Forward chain in the FILTER table. During Skynets startup procedure there appears to be a restart 16s prior to it finishing triggered by AiMesh(?) which is flushing the IPTables ruleset;
Code:
Jan 19 05:26:02 rc_service: amas_lib 1456:notify_rc restart_firewall
I'll have to investigate further as to what triggers this restart event and the best way to work around it beyond increasing the delay.