[01:28:02]
<u/> can updates for yunohost run through cockpit?
[03:24:13]
<kevadesu> https://aria.im/_bifrost/v1/media/download/AXC4h36MLIPfaulUSAkt5mVMqIRni-LXaVVYgxFR0EZ-k_HO63hZUj_0F6y9h8FauoKXncS6lnk5xHyru8Fxmf9CeaLf6h0QAGdpdHRlci5pbS9hNTMwZTVjNDFjZTM2NDA3ZGNkOTE0NWJhOWFlZDE3ZDRiNjJhYzZhMTk4MzAxMTg5MTUzODAzNDY4OA
[03:24:18]
<kevadesu> does this also often appear for anyone else?
[07:29:32]
<err404> Yes, you can refresh the page
[09:17:04]
<orhtej2> > <@kevadesu:gitter.im> does this also often appear for anyone else?
This was triaged to potato cpu on my end, are you using low end vps like kimsurfi?
[20:45:10]
<Aleks (he/him/il/lui)> supposedly that has been reported by several people, typically for automatic-safety-backup-before-upgrade, we're thinking it's because the creation of the backup archive saturas the CPU usage of the yunohost process which is both responsible for the backup/upgrade and sending the logs to the webadmin, therefore the webadmin receives no message and things the yunohost api is down ... we need to find a way to separate both things such that this doesnt happen (assuming the explanation is the right one)
[20:54:30]
<selfhoster1312> that makes complete sense, that could be solved either by using a worker thread dedicated to operations with the web thread responding to requests, or by making everything async (which given the current architecture is probably a very unfeasible idea)
[20:54:55]
<selfhoster1312> but anecdotally i've also had this problem on a very recent and powerful CPU (though i don't remember which operation was involved precisely)
[23:48:36]
<trendless> I've had it happen on several 4-core VPS', 8 core VMs, and 12 core dedi's. I'll pay closer attention to CPU usage next time 👌