Connection works but softwareupdate freeze for 17 minutes to start server

What is the problem?
Connection works nice, but softwareupdate freeze for 10 minutes to start server

What did you already try to solve it?
Disable octoprint.plugins.softwareupdate and octoprint.plugins.announcements

Logs (syslog, dmesg, ... no logs, no support)
2022-02-02 16:54:37,652 - octoprint.util.connectivity.connectivity_checker - INF - - if you see the time, after some exceptions, the octoprint try to load octoprint.plugins.softwareupdate and octoprint.plugins.announcements and use alot time

Additional information about your network (Hardware you are trying to connect to, hardware you are trying to connect from, router, access point, used operating systems, ...)
I'm using rpi2, with usb wifi working well. Tests on octoprint config page show and test things alot fast

I dont now what do anymore. Disabling update and announcements and using safe mode, still freezing on trying fetch data from update channel

pinging (domain for Important OctoPrint Announcements) working nice
pinging working nice

Can you guys help me to do any others tests?
ps: sorry for my english

You've changed the connectivity check IP to an internal one - are you a custom/non-standard DNS configuration on the Pi that made you change this? Or is it all running out of the box standard?

Hello Charlie, thank you for your reply.

I'm using a internal PiHole as DNS, but I've tested with Cloudflare DNS with the same problem

Do you think use Google DNS as default can change anything?

I think this is barking up the wrong tree here.

2022-02-02 16:56:51,143 - octoprint.server.preemptive_cache - INFO - Preemptively caching / (ui _default) for {'base_url': '', 'path': '/', 'query_string': 'l10n=en'}
2022-02-02 16:58:08,139 - octoprint.plugins.pluginmanager - INFO - Loaded plugin notices data from
2022-02-02 16:58:18,067 - octoprint.plugins.pluginmanager - INFO - Loaded notice data from disk, was still valid
2022-02-02 17:03:52,710 - octoprint.server.preemptive_cache - INFO - ... done in 421.57s

Based on this, the initial attempt to pre-render and cache the page takes 7min. No external requests happen in this process (unless somehow caused by misbehaving plugins). What I also see though is a GCODE analysis running which takes 12min right during startup, and right in parallel to the attempt at caching:

2022-02-02 16:55:29,911 - octoprint.filemanager.analysis - INFO - Starting analysis of local:base-y.gcode
2022-02-02 17:07:46,435 - octoprint.filemanager.analysis - INFO - Analysis of entry local:base-y.gcode finished, needed 736.52s

On a Pi 2 I could see the more limited system resources being a factor here.

Judging by the log (next time please share a system info bundle though) the issue here is that stuff that preemptive caching, something that usually should take no longer than half a minute, is taking a whopping 7min here. Since you already tried safe mode without success, the only guess I have right now is your system is simply at its limits during bootup. I don't see this freezing due to update or announcement checks in your log, those complete/fail way before the large time gaps in the log.

Hello foosel. Good to see you here. Thank you for your reply

Good analysis that you see on cache. Now i can agree with you. I've seen the exceptions and focussing in this plugins, but you are right

I'm new with octoprint, i've downloaded the last img from github, and no printed anythink yet. So i dont think there are so much things to cache

I'm working now, but i'll try upload Systeminfo Bundle

Anyway, can i manual clean this caches and try recreate everything, with safety?

You could try (temporarily) renaming your upload folder so OctoPrint doesn't have to analyse what appear to be some larger files right on startup, restart and see if it helps:

mv ~/.octoprint/uploads ~/.octoprint/uploads.bck
sudo service octoprint restart

For some reason there are at least three files in there it should have analysed right after upload, never did though and now is attempting to do that on startup.

Also, please be advised that the recommended minimum hardware when it comes to running OctoPrint on a Pi is a Pi 3. The 2 is quite old and low powered in comparison & not recommended for that reason, so don't expect winning any performance championships with one.

ah! yes, i know about pi 2. I'm installing octoprint because this pi is abandoned for long time. But my printer has no LCD, so octoprint will be nice for basic usage as upload code and send print without PC connection

ok, i've alot tests to do at night, i'll post the results. Thank you guys, you are the best community

Moved the upload cache does not help. Strange because on webUI, only one file are showing, but there are 2 on folder. btw, removing it does not help (62.9 KB)

Now I see that the octoprint.server.preemptive_cache is leaving 3 minutes to run

I think that SD problem, but it's new, class 4, and i've tested on a orangepi and its fine

I dont know what can i do anymore, any idea?

Thank you

class 4 (C4) is pretty slow though I can't definitively say it's the problem here.

Yeh! I know, but works fine with another OSs. I flash raspbian and do a test writing and reading, and this is acceptable

What if you stop OctoPrint then have a top session open. Then while top is open start Octoprint. Hows the iowait?

I always run with htop openned. All the slow time CPU run in 100%. Only after 10 or 15 minutes, CPU is down, and i open WebUI

Memory is OK, but CPU is 100%

I cannot do a print for you now, because I'm flashing debian again. I'll try run it on docker or manual install. Let's see if change anything

Once you can I'd definitely be interested in knowing what iowait (wa) is like when starting OctoPrint

Because i dont have to much luck with my hw and octoprint, i'll test another I've found.

I'll close the thread for now, but thank you for you all for the fast reply