Just a gitea newbie in here. I have a self-hosted gitea image that’s hitting the following error constantly, backing up my logs:
2023/04/17 20:31:10 ...vices/auth/oauth2.go:109:userIDFromToken() [E] UpdateAccessToken: unable to open database file: too many open files
2023/04/17 20:31:10 ...vices/auth/oauth2.go:109:userIDFromToken() [E] UpdateAccessToken: unable to open database file: too many open files
2023/04/17 20:31:10 ...vices/auth/oauth2.go:109:userIDFromToken() [E] UpdateAccessToken: unable to open database file: too many open files
So far I have:
checked that the gitea user/pid can have a large file limit via ulimit:
8192```
2. restarted the service
3. checked sqlite3 for issues via PRAGMA integrity_check
4. restarted the service (again)
but I can't seem to get to the bottom of this issue, I'm also unable to find helpful information online. Gitea is mostly up but a friend of mine is unable to access it (500 errors) and gets the following when trying to do a git pull:
```2023/04/17 18:44:55 ...s/setting/setting.go:1168:CreateOrAppendToCustomConf() [F] error saving to custom config: open /etc/gitea/app.ini: permission denied```
Is this unable to open database happening intermittently or always? If it’s happening intermittently, what actions tend to trigger it (git pulls, viewing readme, viewing profile page, etc.)?
I see you mentioned your friend having issues pulling, is the repository they’re pulling fairly large in terms of number of files?
You can try editing /etc/systemd/system.conf and /etc/systemd/user.conf and changing #DefaultLimitNOFILE=1024:524288 to something large like DefaultLimitNOFILE=65535:524288. Note removal of hashtag and only modify the first number. This change will take effect after a reboot.
it’s happening always, all the time, restarting the service does nothing. I did check out the other related issue that you mention and now hope that upgrading the binary will fix it all, thanks for the advice.
I think the issue with my friend is that he has an SSH key to use the platform with, all the rest of us are just pulling without it. Don’t think it’s related to a specific repo since it happens from the command line with all the repos.
I was holding off on doing a reboot since I don’t have physical access to the machine but I will probably do that if the upgrade doesn’t work.
lsof showed gitea had a lot of files opened, but it seems like an upgrade to 1.19.1 fixed it. at least for the 2 hours it’s been up. thanks for the help!
spoke too soon, we are just testing the new version out and while the ‘too many open files’ issue has been cleared up we are still seeing the following when trying to clone/pull a repo:
2023/04/20 16:28:22 ...s/setting/setting.go:260:newFileProviderFromConf() [F] Unable to find configuration file: "/etc/gitea/app.ini".
Ensure you are running in the correct environment or set the correct configuration file with -c.
fatal: Could not read from remote repository.
kind of a super late update but the issue was that the gitea user wasn’t part of the gitea group so it couldn’t access the /etc/gitea folder. I didn’t create the original config but apparently the install was done by following the instructions to install from binary. Perhaps the instructions were old or they weren’t followed properly, who knows. I do see that now we create a group for the git user. Anyway, thanks to all for helping me solve this mystery.