Gitea tries to use /usr/bin as run dir #4130

New Issue

2025-11-02T05:39:37-06:00

GiteaMirror commented

2025-11-02 05:39:37 -06:00

Originally created by @Martmists-GH on GitHub (Oct 17, 2019).

Gitea version (or commit ref): Latest
Git version: Latest
Operating system: Arch Linux x64
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 installed gitea from the repositories using pacman, but whatever I did it always seemed to use /usr/bin as working dir instead of /var/lib/gitea

Originally created by @Martmists-GH on GitHub (Oct 17, 2019). - Gitea version (or commit ref): Latest - Git version: Latest - Operating system: Arch Linux x64 - 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 ## Description I installed gitea from the repositories using pacman, but whatever I did it always seemed to use /usr/bin as working dir instead of /var/lib/gitea

GiteaMirror closed this issue

2025-11-02 05:39:37 -06:00

GiteaMirror commented

2025-11-02 05:39:39 -06:00

@zeripath commented on GitHub (Oct 17, 2019):

Unfortunately Gitea has non-fhs compliant expectations which mean that just building from source and placing the binary in /usr/bin will not work.

See "Changing the default CustomPath, CustomConf and AppWorkPath" in https://docs.gitea.io/en-us/install-from-source/ for how to set up the build environment to change the default locations so that Gitea will never look in the wrong place.

Or

Consider using the https://github.com/go-gitea/gitea/blob/master/contrib/fhs-compliant-script/gitea to shim the Gitea binary so that its environment is set up.

Or

Look at https://docs.gitea.io/en-us/specific-variables/ to see which environment variables you can set to tell Gitea to look elsewhere and/or https://docs.gitea.io/en-us/command-line/ to see the command line options.

Please could you advise your package maintainer change their package to use the LDFLAGS replacement trick described or the fhs compliant script in order to prevent further confusion.

Edit: the documentation is currently incorrect in calling this AppWorkDir it should be AppWorkPath.

@zeripath commented on GitHub (Oct 17, 2019): Unfortunately Gitea has non-fhs compliant expectations which mean that just building from source and placing the binary in /usr/bin will not work. See "Changing the default CustomPath, CustomConf and AppWorkPath" in https://docs.gitea.io/en-us/install-from-source/ for how to set up the build environment to change the default locations so that Gitea will never look in the wrong place. Or Consider using the https://github.com/go-gitea/gitea/blob/master/contrib/fhs-compliant-script/gitea to shim the Gitea binary so that its environment is set up. Or Look at https://docs.gitea.io/en-us/specific-variables/ to see which environment variables you can set to tell Gitea to look elsewhere and/or https://docs.gitea.io/en-us/command-line/ to see the command line options. Please could you advise your package maintainer change their package to use the LDFLAGS replacement trick described or the fhs compliant script in order to prevent further confusion. Edit: the documentation is currently incorrect in calling this AppWorkDir it should be AppWorkPath.

GiteaMirror commented

2025-11-02 05:39:40 -06:00

@zeripath commented on GitHub (Oct 17, 2019):

Hi @ArchangeGabriel @alucryd,

Looking at the arch Linux package information, I believe you are the maintainers of the Gitea package for arch Linux. If not I'm sorry for spamming you.

Gitea in its default build assumes that it is run from the root of its directory structure and doesn't comply with the FHS leading to confusion if the binary is placed in /usr/bin.

You can workaround this with using environment variables, or since 1.9 command line options but it's a little surprising for users that it doesn't work the way they expect.

Since 1.9, it's been possible to build Gitea in a way that means you can define these default directories within the binary file using an LDFLAGS at time of compile/link/make. We also now provide a FHS compliant script in contrib/ that you can use as /usr/bin/gitea whilst installing the Gitea binary as /usr/lib/gitea/gitea if you don't want to use that technique. (Please see the preceding comments for more information.)

Please could you update your package to use one of these techniques. Unfortunately we cannot change the default build of Gitea to be FHS compliant without breaking too many users, but I have tried hard to make it possible to build it in a compliant manner and/or be able to shim the binary so it appears compliant.

Thanks so much for continuing to package Gitea. Please do not hesitate to ask if you need further information.

@zeripath commented on GitHub (Oct 17, 2019): Hi @ArchangeGabriel @alucryd, Looking at the arch Linux package information, I believe you are the maintainers of the Gitea package for arch Linux. If not I'm sorry for spamming you. Gitea in its default build assumes that it is run from the root of its directory structure and doesn't comply with the FHS leading to confusion if the binary is placed in `/usr/bin`. You can workaround this with using environment variables, or since 1.9 command line options but it's a little surprising for users that it doesn't work the way they expect. Since 1.9, it's been possible to build Gitea in a way that means you can define these default directories within the binary file using an `LDFLAGS` at time of compile/link/make. We also now provide a FHS compliant script in `contrib/` that you can use as `/usr/bin/gitea` whilst installing the Gitea binary as `/usr/lib/gitea/gitea` if you don't want to use that technique. (Please see the preceding comments for more information.) Please could you update your package to use one of these techniques. Unfortunately we cannot change the default build of Gitea to be FHS compliant without breaking too many users, but I have tried hard to make it possible to build it in a compliant manner and/or be able to shim the binary so it appears compliant. Thanks so much for continuing to package Gitea. Please do not hesitate to ask if you need further information.

GiteaMirror commented

2025-11-02 05:39:40 -06:00

@ArchangeGabriel commented on GitHub (Oct 17, 2019):

@zeripath Thanks for pinging. So just to be sure, it means we should add -X \"code.gitea.io/gitea/modules/setting.AppWorkDir=/var/lib/gitea\" to our LDFLAGS, correct? Because I’ve just tried that and it did not worked (still telling /usr/bin as the default in gitea help).

@ArchangeGabriel commented on GitHub (Oct 17, 2019): @zeripath Thanks for pinging. So just to be sure, it means we should add `-X \"code.gitea.io/gitea/modules/setting.AppWorkDir=/var/lib/gitea\"` to our LDFLAGS, correct? Because I’ve just tried that and it did not worked (still telling `/usr/bin` as the default in `gitea help`).

GiteaMirror commented

2025-11-02 05:39:40 -06:00

@zeripath commented on GitHub (Oct 17, 2019):

Damn! It should be AppWorkPath not dir. I'll send a PR to the docs to fix that sorry.

@zeripath commented on GitHub (Oct 17, 2019): Damn! It should be AppWorkPath not dir. I'll send a PR to the docs to fix that sorry.

GiteaMirror commented

2025-11-02 05:39:40 -06:00

@ArchangeGabriel commented on GitHub (Oct 17, 2019):

OK, that did it. ;) I’ve pushed the new package. :)

@ArchangeGabriel commented on GitHub (Oct 17, 2019): OK, that did it. ;) I’ve pushed the new package. :)

GiteaMirror commented

2025-11-02 05:39:40 -06:00

@zeripath commented on GitHub (Oct 17, 2019):

Thanks @ArchangeGabriel sorry the documentation is incorrect.

In case you're interested the -X in the LDFLAGS simply changes the default value for the provided variable name.

In this case we do a delicate dance with this value, setting it when you set environment variables or command line options but if it remains empty then it is set in the end to the program location. By setting it with LDFLAGS you always ensure that it has a default value to fall back on.

Other go projects will likely be adjustable in similar ways even if their developers aren't aware of it.

Sorry once again that the documentation is incorrect.

@zeripath commented on GitHub (Oct 17, 2019): Thanks @ArchangeGabriel sorry the documentation is incorrect. In case you're interested the -X in the LDFLAGS simply changes the default value for the provided variable name. In this case we do a delicate dance with this value, setting it when you set environment variables or command line options but if it remains empty then it is set in the end to the program location. By setting it with LDFLAGS you always ensure that it has a default value to fall back on. Other go projects will likely be adjustable in similar ways even if their developers aren't aware of it. Sorry once again that the documentation is incorrect.

GiteaMirror commented

2025-11-02 05:39:40 -06:00