github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-11 17:46:29 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

bug: working dir path its not fully honored with GITEA_WORK_DIR #2628

New Issue
Closed
opened 2025-11-02 04:42:44 -06:00 by GiteaMirror · 11 comments
GiteaMirror commented 2025-11-02 04:42:44 -06:00
Owner
Copy Link

Originally created by @mckaygerhard on GitHub (Dec 6, 2018).

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

Description

i setup my fles (either compile with bindata or not) in /srv/gitea and the binary in /usr/bin/gitea, then run using GITEA_WORK_DIR to set to /srv/gitea, as cgi or as daemon ...

seems due changes since #2192 due the issue #1419 the gitea assumes many files will be in current path from where are "invoked" the binary (in daemon case from nowhere, in others cases from users home) so some very non-dessire behaviour will happened:

  • a) so if a particular user runs the gitea binary the files will be "regenerated" (if where compiled with bindata) into the home path, and the files under GITEA_WORK_DIR will not be taken all in fact, by exampel the gitea db if are sqlite! its the most clear case as exposed in issue #3816 and maybe same proble root of #4672
  • b) in same case as "a" if non-bindata are compiled, a crash will happened!
  • c) if a fake user will run the binary will happened that db will not be created..
  • d) the work dir was set but inclusively if log was defined in the app.ini file (that are already existing in the work dir custon path) a new log file are created in current path directory, this happened due the "a" happened either if the app.ini file are located and readed!

using the variable of working dir gitea "reads" de db (with pingin) and later create it? as i can see in the log file seems that are very confused!

Log

root@venenux: /srv/gitea# GITEA_WORK_DIR=/srv/gitea/aaaa/ /usr/bin/gitea 
2018/12/06 14:40:41 [T] AppPath: /usr/bin/gitea
2018/12/06 14:40:41 [T] AppWorkPath:  /srv/gitea/aaaa/
2018/12/06 14:40:41 [T] Custom path:  /srv/gitea/aaaa/custom
2018/12/06 14:40:41 [T] Log path:  /srv/gitea/bin/log
2018/12/06 14:40:42 [I] Gitea v1.6.0-dev built with: sqlite, pam
2018/12/06 14:40:42 [I] Log Mode: Console(Trace)
2018/12/06 14:40:42 [I] Log Mode: File(Trace)
2018/12/06 14:40:42 [I] XORM Log Mode: Console(Trace)
2018/12/06 14:40:42 [I] XORM Log Mode: File(Trace)
2018/12/06 14:40:42 [I] Cache Service Enabled
2018/12/06 14:40:42 [I] Session Service Enabled
2018/12/06 14:40:42 [I] PING DATABASE sqlite3

later i can see that database are crated:

2018/12/06 14:40:42 [I] [SQL] SELECT sql FROM sqlite_master WHERE type='index' and tbl_name = ? [version]
2018/12/06 14:40:42 [I] [SQL] CREATE TABLE IF NOT EXISTS `user` (`id` INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, `lower_name` TEXT NOT NULL, `name` TEXT NOT NULL, `full_name` TEXT NULL, `email` TEXT NOT NULL, `keep_email_private` INTEGER NULL, `passwd` TEXT NOT NULL, `login_type` INTEGER NULL, `login_source` INTEGER DEFAULT 0 NOT NULL, `login_name` TEXT NULL, `type` INTEGER NULL, `location` TEXT NULL, `website` TEXT NULL, `rands` TEXT NULL, `salt` TEXT NULL, `language` TEXT NULL, `created_unix` INTEGER NULL, `updated_unix` INTEGER NULL, `last_login_unix` INTEGER NULL, `last_repo_visibility` INTEGER NULL, `max_repo_creation` INTEGER DEFAULT -1 NOT NULL, `is_active` INTEGER NULL, `is_admin` INTEGER NULL, `allow_git_hook` INTEGER NULL, `allow_import_local` INTEGER NULL, `allow_create_organization` INTEGER DEFAULT 1 NULL, `prohibit_login` INTEGER DEFAULT 0 NOT NULL, `avatar` TEXT NOT NULL, `avatar_email` TEXT NOT NULL, `use_custom_avatar` INTEGER NULL, `num_followers` INTEGER NULL, `num_following` INTEGER DEFAULT 0 NOT NULL, `num_stars` INTEGER NULL, `num_repos` INTEGER NULL, `description` TEXT NULL, `num_teams` INTEGER NULL, `num_members` INTEGER NULL, `diff_view_style` TEXT DEFAULT '' NOT NULL)
2018/12/06 14:40:42 [I] [SQL] CREATE UNIQUE INDEX `UQE_user_lower_name` ON `user` (`lower_name`)
2018/12/06 14:40:42 [I] [SQL] CREATE UNIQUE INDEX `UQE_user_name` ON `user` (`name`)
2018/12/06 14:40:42 [I] [SQL] CREATE INDEX `IDX_user_created_unix` ON `user` (`created_unix`)
2018/12/06 14:40:42 [I] [SQL] CREATE INDEX `IDX_user_updated_unix` ON `user` (`updated_unix`)
2018/12/06 14:40:42 [I] [SQL] CREATE INDEX `IDX_user_last_login_unix` ON `user` (`last_login_unix`)
2018/12/06 14:40:42 [I] [SQL] CREATE INDEX `IDX_user_is_active` ON `user` (`is_active`)
Originally created by @mckaygerhard on GitHub (Dec 6, 2018). - Gitea version (or commit ref): 1.6.0 - Git version: not relevant - Operating system: Linux and Mac - Database (use `[x]`): - [x] PostgreSQL - [ ] MySQL - [ ] MSSQL - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant ## Description i setup my fles (either compile with bindata or not) in /srv/gitea and the binary in /usr/bin/gitea, then run using GITEA_WORK_DIR to set to /srv/gitea, as cgi or as daemon ... seems **due changes since #2192 due the issue #1419** the gitea **assumes many files will be in current path from where are "invoked" the binary** (in daemon case from nowhere, in others cases from users home) so **some very non-dessire behaviour will happened**: * a) so if a particular user runs the gitea binary the files will be "regenerated" (if where compiled with bindata) into the home path, and the files under GITEA_WORK_DIR will not be taken all in fact, by exampel the gitea db if are sqlite! its the most clear case as exposed in issue #3816 and maybe same proble root of #4672 * b) in same case as "a" if non-bindata are compiled, a crash will happened! * c) if a fake user will run the binary will happened that db will not be created.. * d) the work dir was set but inclusively if log was defined in the app.ini file (that are already existing in the work dir custon path) a new log file are created in current path directory, this happened due the "a" happened either if the app.ini file are located and readed! using the variable of working dir gitea "reads" de db (with pingin) and later create it? as i can see in the log file seems that are very confused! ## Log ``` root@venenux: /srv/gitea# GITEA_WORK_DIR=/srv/gitea/aaaa/ /usr/bin/gitea 2018/12/06 14:40:41 [T] AppPath: /usr/bin/gitea 2018/12/06 14:40:41 [T] AppWorkPath: /srv/gitea/aaaa/ 2018/12/06 14:40:41 [T] Custom path: /srv/gitea/aaaa/custom 2018/12/06 14:40:41 [T] Log path: /srv/gitea/bin/log 2018/12/06 14:40:42 [I] Gitea v1.6.0-dev built with: sqlite, pam 2018/12/06 14:40:42 [I] Log Mode: Console(Trace) 2018/12/06 14:40:42 [I] Log Mode: File(Trace) 2018/12/06 14:40:42 [I] XORM Log Mode: Console(Trace) 2018/12/06 14:40:42 [I] XORM Log Mode: File(Trace) 2018/12/06 14:40:42 [I] Cache Service Enabled 2018/12/06 14:40:42 [I] Session Service Enabled 2018/12/06 14:40:42 [I] PING DATABASE sqlite3 ``` later i can see that database are crated: ``` 2018/12/06 14:40:42 [I] [SQL] SELECT sql FROM sqlite_master WHERE type='index' and tbl_name = ? [version] 2018/12/06 14:40:42 [I] [SQL] CREATE TABLE IF NOT EXISTS `user` (`id` INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, `lower_name` TEXT NOT NULL, `name` TEXT NOT NULL, `full_name` TEXT NULL, `email` TEXT NOT NULL, `keep_email_private` INTEGER NULL, `passwd` TEXT NOT NULL, `login_type` INTEGER NULL, `login_source` INTEGER DEFAULT 0 NOT NULL, `login_name` TEXT NULL, `type` INTEGER NULL, `location` TEXT NULL, `website` TEXT NULL, `rands` TEXT NULL, `salt` TEXT NULL, `language` TEXT NULL, `created_unix` INTEGER NULL, `updated_unix` INTEGER NULL, `last_login_unix` INTEGER NULL, `last_repo_visibility` INTEGER NULL, `max_repo_creation` INTEGER DEFAULT -1 NOT NULL, `is_active` INTEGER NULL, `is_admin` INTEGER NULL, `allow_git_hook` INTEGER NULL, `allow_import_local` INTEGER NULL, `allow_create_organization` INTEGER DEFAULT 1 NULL, `prohibit_login` INTEGER DEFAULT 0 NOT NULL, `avatar` TEXT NOT NULL, `avatar_email` TEXT NOT NULL, `use_custom_avatar` INTEGER NULL, `num_followers` INTEGER NULL, `num_following` INTEGER DEFAULT 0 NOT NULL, `num_stars` INTEGER NULL, `num_repos` INTEGER NULL, `description` TEXT NULL, `num_teams` INTEGER NULL, `num_members` INTEGER NULL, `diff_view_style` TEXT DEFAULT '' NOT NULL) 2018/12/06 14:40:42 [I] [SQL] CREATE UNIQUE INDEX `UQE_user_lower_name` ON `user` (`lower_name`) 2018/12/06 14:40:42 [I] [SQL] CREATE UNIQUE INDEX `UQE_user_name` ON `user` (`name`) 2018/12/06 14:40:42 [I] [SQL] CREATE INDEX `IDX_user_created_unix` ON `user` (`created_unix`) 2018/12/06 14:40:42 [I] [SQL] CREATE INDEX `IDX_user_updated_unix` ON `user` (`updated_unix`) 2018/12/06 14:40:42 [I] [SQL] CREATE INDEX `IDX_user_last_login_unix` ON `user` (`last_login_unix`) 2018/12/06 14:40:42 [I] [SQL] CREATE INDEX `IDX_user_is_active` ON `user` (`is_active`) ``` ```
GiteaMirror added the issue/staletype/bug labels 2025-11-02 04:42:44 -06:00
GiteaMirror commented 2025-11-02 04:42:45 -06:00
Author
Owner
Copy Link

@mckaygerhard commented on GitHub (Dec 26, 2018):

version 1.6.1 released !! i can understand that this issue are not easy to solve but...

@mckaygerhard commented on GitHub (Dec 26, 2018): version 1.6.1 released !! i can understand that this issue are not easy to solve but...
GiteaMirror commented 2025-11-02 04:42:45 -06:00
Author
Owner
Copy Link

@mathong commented on GitHub (Jan 19, 2019):

I had the same issue (v1.6.4). And the binary's path is written in some files like repositories hooks and authorized_keys.

I ended up moving the binary in a writeable directory, and sedding the previously mentioned files to update the path...

@mathong commented on GitHub (Jan 19, 2019): I had the same issue (v1.6.4). And the binary's path is written in some files like repositories hooks and authorized_keys. I ended up moving the binary in a writeable directory, and sedding the previously mentioned files to update the path...
GiteaMirror commented 2025-11-02 04:42:45 -06:00
Author
Owner
Copy Link

@mckaygerhard commented on GitHub (Jan 19, 2019):

I ended up moving the binary in a writeable directory, and sedding the previously mentioned files to update the path...

this still does not work for other webservers using reverse proxy and also for binary distribution.. again more features = more bugs

@mckaygerhard commented on GitHub (Jan 19, 2019): > I ended up moving the binary in a writeable directory, and sedding the previously mentioned files to update the path... this still does not work for other webservers using reverse proxy and also for binary distribution.. again more features = more bugs
GiteaMirror commented 2025-11-02 04:42:45 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Jan 19, 2019):

I think this might not be so hard to fix and I'd put a PR in to do so, but I don't understand what the problem is exactly from the above comments.

Can you for each problem file:

  • Tell me what the path is currently.
  • Give me a some idea of what you think that path is in terms of Gitea app.ini variables or working paths.
  • Tell me what it should be.
@zeripath commented on GitHub (Jan 19, 2019): I think this might not be so hard to fix and I'd put a PR in to do so, but I don't understand what the problem is exactly from the above comments. Can you for each problem file: * Tell me what the path is currently. * Give me a some idea of what you think that path is in terms of Gitea app.ini variables or working paths. * Tell me what it should be.
GiteaMirror commented 2025-11-02 04:42:46 -06:00
Author
Owner
Copy Link

@harleypig commented on GitHub (Jan 29, 2019):

I'm not sure if this is related to this issue or not. If not, I'll create a new one.

I am using Arch Linux installation of gitea, which is using this service file.

After updating to 1.7.0, the service fails to start and the following can be found from the status command.

$ systemctl status gitea
...
Jan 29 01:35:00 harleypig.com gitea[17175]: 2019/01/29 01:35:00 [...s/setting/setting.go:882 NewContext()] [E] Failed to create '/home/git/.ssh': mkdir /home/git: permission denied

If I run the followng as root gitea starts with no errors, but I'm unable to access anything ssh related. Logs show that it is a permissions error to /home/git/.ssh.

GITEA_WORK_DIR=/var/lib/gitea sudo -u gitea --preserve-env='GITEA_WORK_DIR' /usr/bin/gitea web -c /etc/gitea/app.ini

@harleypig commented on GitHub (Jan 29, 2019): I'm not sure if this is related to this issue or not. If not, I'll create a new one. I am using Arch Linux installation of gitea, which is using this [service file](https://git.archlinux.org/svntogit/community.git/tree/trunk/gitea.service?h=packages/gitea). After updating to 1.7.0, the service fails to start and the following can be found from the status command. ``` $ systemctl status gitea ... Jan 29 01:35:00 harleypig.com gitea[17175]: 2019/01/29 01:35:00 [...s/setting/setting.go:882 NewContext()] [E] Failed to create '/home/git/.ssh': mkdir /home/git: permission denied ``` If I run the followng as root gitea starts with no errors, but I'm unable to access anything ssh related. Logs show that it is a permissions error to /home/git/.ssh. `GITEA_WORK_DIR=/var/lib/gitea sudo -u gitea --preserve-env='GITEA_WORK_DIR' /usr/bin/gitea web -c /etc/gitea/app.ini`
GiteaMirror commented 2025-11-02 04:42:46 -06:00
Author
Owner
Copy Link

@harleypig commented on GitHub (Jan 29, 2019):

So, my original app.ini had SSH_ROOT_PATH set to /home/git/.ssh. I changed it to be null and gitea service started up.

@harleypig commented on GitHub (Jan 29, 2019): So, my original app.ini had SSH_ROOT_PATH set to /home/git/.ssh. I changed it to be null and gitea service started up.
GiteaMirror commented 2025-11-02 04:42:46 -06:00
Author
Owner
Copy Link

@mckaygerhard commented on GitHub (Mar 6, 2019):

now we have 1.7.3 and this problem still persist!

@mckaygerhard commented on GitHub (Mar 6, 2019): now we have 1.7.3 and this problem still persist!
GiteaMirror commented 2025-11-02 04:42:47 -06:00
Author
Owner
Copy Link

@techknowlogick commented on GitHub (Mar 6, 2019):

@mckaygerhard we are unable to assist you and solve the issue if we don't have all the information about your problem. Are you able to respond to @zeripath's questions?

@techknowlogick commented on GitHub (Mar 6, 2019): @mckaygerhard we are unable to assist you and solve the issue if we don't have all the information about your problem. Are you able to respond to @zeripath's questions?
GiteaMirror commented 2025-11-02 04:42:47 -06:00
Author
Owner
Copy Link

@mckaygerhard commented on GitHub (Mar 7, 2019):

@zeripath and @techknowlogick all are obviously posted in the original iisue request, but well let's posted that wants you here in detail again:

Tell me what the path is currently.

can you see in the original request: root@venenux: /srv/gitea# GITEA_WORK_DIR=/srv/gitea/aaaa/ /usr/bin/gitea

Give me a some idea of what you think that path is in terms of Gitea app.ini variables or working paths.

i setup in gitea ini a "xxxx" path .. whatever path i setup , no matter what, i set at command line GITEA_WORK_DIR=/srv/gitea/aaaa/ so then IT SUPPOST to that gitea search to the ini file at "/srv/gitea/aaaa/custom" right? well all that happened are in the original post in this issue, can you see that log said that the gitea does not find the database, and so then due tyhat try to re-create again? that means that the ini files does not are readed!

Tell me what it should be.

no re-creates database again (sqlite) and read ini file (where i setup database to mysql or sqlite, no matter what i setup or environment variable i set, it's not honored)

@mckaygerhard commented on GitHub (Mar 7, 2019): @zeripath and @techknowlogick all are obviously posted in the original iisue request, but well let's posted that wants you here in detail again: > Tell me what the path is currently. can you see in the original request: `root@venenux: /srv/gitea# GITEA_WORK_DIR=/srv/gitea/aaaa/ /usr/bin/gitea ` > Give me a some idea of what you think that path is in terms of Gitea app.ini variables or working paths. i setup in gitea ini a "xxxx" path .. whatever path i setup , no matter what, i set at command line `GITEA_WORK_DIR=/srv/gitea/aaaa/` so then IT SUPPOST to that gitea search to the ini file at "/srv/gitea/aaaa/custom" right? well **all that happened are in the original post in this issue, can you see that log said that the gitea does not find the database, and so then due tyhat try to re-create again? that means that the ini files does not are readed!** > Tell me what it should be. no re-creates database again (sqlite) and read ini file (where i setup database to mysql or sqlite, no matter what i setup or environment variable i set, it's not honored)
GiteaMirror commented 2025-11-02 04:42:47 -06:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (May 6, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (May 6, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.
GiteaMirror commented 2025-11-02 04:42:47 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (May 13, 2019):

Hmm... I think this is solved already.

@zeripath commented on GitHub (May 13, 2019): Hmm... I think this is solved already.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label issue/stale type/bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#2628
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?