Skip to content
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

Chown command running issue when gitea starts #4425

Closed
5 tasks
sunsongxp opened this issue Jul 11, 2018 · 4 comments
Closed
5 tasks

Chown command running issue when gitea starts #4425

sunsongxp opened this issue Jul 11, 2018 · 4 comments

Comments

@sunsongxp
Copy link

sunsongxp commented Jul 11, 2018

  • Gitea version (or commit ref): v1.4.3
  • Git version:
  • Operating system: Docker Mac
  • Database (use [x]):
    • [X ] PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
    • [X ] Not relevant
  • Log gist:

Description

Gitea container was down due to maintenance, then I restart the container, the container is up without problem, but the gitea is not running. I went to inside the container using docker exec, I found that it is all because the container is running chown -R git:git /data/gitea /app/gitea /data/git on every start. Let's say I have quite a number of projects with large repositories, this command will take a long time to finish. After it has finished, gitea is up again without problem.

https://hub.docker.com/r/gitea/gitea/tags/

So here is solution, remove chown step when start, please do not run chown to the whole data folder in any circumstance, it is not a scalable way to manage the data folder

@sunsongxp
Copy link
Author

It also happens at version v1.5

@fabian-braun
Copy link
Contributor

We encountered the same issue having the respective folders on a slow NFS.
I created a small PR to illustrate how it could be fixed. I'm not a bash expert, don't hesitate to suggest changes / improvements.
Especially I'm not sure if checking the ownership only on the top-level directory is sufficient.

@captn3m0
Copy link

I'm on 1.5.0-rc1 and facing the same issue.

@captn3m0
Copy link

I found that the step was hung for me because of a huge sessions directory. I'd long back switched sessions to redis, however the old sessions directory was still taking up 400MB of disk space, and the chown was taking too much time because of that. Deleting the directory, and upgrading to 1.5.2 helped.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants