-
-
Notifications
You must be signed in to change notification settings - Fork 5.8k
Gitea on FreeBSD enters a CPU busy loop (sched_yield()) before ultimately crashing #14815
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I dumped from sqlite to postgresql, and the time before gitea spun into a busy loop seemed to take a lot longer, but still eventually fell over. |
Any logs? You've not given us anything to work on - I don't know if it's potentially a scheduled task or something like a leak in go's waits. Does pprof yield anything? What version of go are you building with? Are you building with the absolute latest? Are you running bleve code indexing? Do you have mirrors? But seriously give us some logs and ensure you're using the latest go version. |
Go 1.15.8, as far as log goes there's nothing that indicates any problem.
That's the last entry from the log after this process crashed last night. I do have code indexing and mirrored repositories in this environment. |
Those queries are taking a very very long time 750.404_s ! Can you please read https://docs.gitea.io/en-us/logging-configuration/#debugging-problems and adjust your logging to give us a bit more detail. In your case the SQL logs would be actually helpful. I'll need a bit more context than three lines though - clearly all of those are very wrong so we need to see the OK lines first. (One other thing is consider changing your default password algorithm as argon2 might be the problem if you're running out of memory.) I would also check if you have an appropriate robots.txt in case you're being crawled and that is what the issue is. |
I hadn't noticed this comment @zeripath, thanks for some pointers! I just noticed this evening that the gitea process looks like it's leaking gigabytes of memory before crashing, so will definitely try to do some tinkering this weekend |
It seems the version on pkg of Freebsd is broken because of missing assets. |
Last snippets of the log now that I've been running with more debugging. Unfortunately nothing is jumping out to me, but I can upload an even longer log if that's helpful. |
This looks like a problem with sqlite - look at the time those queries are taking. I don't know what is happening but they shouldn't be taking that long. It may be worth examining your sqlite database - perhaps it needs vacuuming perhaps there's additional information that can be gleaned from it but the problem doesn't seem to be at the go layer. But really we need more logs - none of those values are normal. I need to see when it normal and when it stopped being normal. A good marker for the point of change will be the timestamp at that end of a line containing xorm being listed in _s rather than _ms. |
@zeripath The backing database is PostgreSQL 13 in this case on the same host. I've gone and run a vacuum anyways and we'll see what happens. Because there's PII in this full log file, I would prefer not to share it with the whole wide word, I'm happy to email it along to you @zeripath however (i'm |
Sorry it's taken me so long to get back to you - I've sent you an email. |
OK so it turns out the _s are actually µs so those are normal! What was the configuration of your logging you had for those logs? I think LOG_SQL can now be set to false. I don't see any GET or POST requests logs in your logs but yet I do see template 404 - so I'm not seeing the router logs. I need to see those too. It might be in the Could you also update to 1.13.6 - there's a really stupid bug in 1.13.2 that was fixed in 1.13.3 in #14598 I wonder if that might be the issue. |
My logging configuration is:
This is with 1.13.6, but I'm not sure I'm doing this right since the logs don't look too impressive to me (sent via email) |
Please see: https://docs.gitea.io/en-us/logging-configuration I need the router logs too. If you want to use files rather than redirecting the console do:
If you're able to redirect the console then:
|
Even with the following, I don't believe i'm getting router logs out of this daemon 😕
Would it be possible that some build flag might have caused this to be functionality to be disabled? |
Is it possible you have
What is the contents of your app.ini as relates to |
My log section is here: [log]
ROOT_PATH = /var/log/gitea
MODE = file
LEVEL = debug
ROUTER = , And Honestly I'm quite perplexed as to why no router logs are showing up. |
I think this is #15826 |
Oooo, I'll keep an eye on that 😄 |
Just jumped to 0.14.3 and still see the issue, but it looks like one of the related fixes is slated for 0.15 🤞 |
which one? |
1.14.3 should contain that and another fix for it. So it's not that unfortunately. We still need to see those routers logs. It may be that you find that 1.15 fixes this though. |
Outdated, please open a new issue if there is still any problem |
[x]
):Description
I had migrated the sqlite database and repositories from a Linux machine to a FreeBSD machine (both amd64 of course) and have found that the Gitea daemon will be up and running for 10-20 minutes before it goes into consuming all CPU. I attached truss (like strace) and found that the daemon was just spinning and spinning on sched_yield().
I cannot find any reproduction case, but the web UI goes completely unresponsive. Eventually, usually after I go to bed 😄 , the daemon seems to crash entirely
I'm honestly not sure how to make this a better report, if there's any useful debugging or flags I can fiddle with I'm happy to try.
Screenshots
The text was updated successfully, but these errors were encountered: