UpdateAccessToken: unable to open database file: too many open files

Hi all,

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:

  1. 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```

permissions on app.ini seem fine to me:

-rw-rw----   1 gitea gitea   135 Jul  6  2022 app.ii
-rw-rw----   1 gitea gitea  1713 Apr 17 12:00 app.ini

any help would be appreciated :3 thanks in advance

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.

Possibly related to Too many open files (many image on readme) · Issue #19463 · go-gitea/gitea · GitHub.

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.

Thanks again for the help! Appreciate it.

No worries. Hopefully the upgrade/reboot fixes your issue. If not, let us know!

If it’s not caused by the too-low OS limit, then it might be some resource-leaking bug in Gitea, some files are opened, then not closed properly.

But I am not sure at the moment. Can you use lsof to see how many files are open in the Gitea process?

1 Like

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.

That’s another problem. Where is your config file (app.ini)? How do you make Gitea use it?


I guess, either:

  1. Go to Site Admin page:
    • Update the ‘.ssh/authorized_keys’ file with Gitea SSH keys.
    • Resynchronize pre-receive, update and post-receive hooks of all repositories. Run

– OR

  1. ln -s your-dir/app.ini /etc/gitea/app.ini
1 Like

our config file is and has always been in /etc/gitea/app.ini but I’ll check the other things you mentioned

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.

1 Like