Failed to get home directory: Cannot specify home directory because it's empty

[chaosmonk1]

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

Description

I have installed Gitea on Debian 10, mostly following these instructions, deviating in the following ways:

• I installed the FSH-compliant wrapper script to /usr/bin

• I installed the Gitea 1.10.1 binary to /usr/lib/gitea/gitea, since that's where the wrapper script expects it to be.

• I am using SysVinit rather than systemd, so instead of the systemd unit file I used this init script, changing DAEMON=/usr/local/bin/$NAME to DAEMON=/usr/bin/$NAME in order to point to the FHS wrapper script.

I ran sudo service gitea start, and at first everything seemed fine. I was able to install Gitea via the web interface, create a user, and push several repos. However, upon making some changes to /etc/gitea/app.ini and running sudo service gitea restart, I got the following warning and error:

2019/12/30 03:01:29 ...s/setting/setting.go:517:NewContext() [W] Custom config '/var/lib/gitea/custom/"/etc/gitea/app.ini"' not found, ignore this if you're running first time
2019/12/30 03:01:29 ...s/setting/setting.go:523:NewContext() [F] Failed to get home directory: Cannot specify home directory because it's empty

Although Gitea restarted successfully, I found that my changes to app.ini had not taken effect. These messages also appeared when I ran Gitea for the first time, but I did not pay close attention to them at the time.

The first message appears to be an issue of "/etc/gitea/app.ini" getting appended to the custom config path. My suspicion was that this is because of the line DAEMON_ARGS="web -c /etc/$NAME/app.ini", and that the -c argument might be redundant with the wrapper script. I tried changing it to DAEMON_ARGS="web", and restarted Gitea.

This time, I only got the second message: Failed to get home directory: .... However, Gitea no longer worked properly. Many pages gave a 500 error. I then reverted my change to the init script and restarted, but still got the 500 errors. I tried hacking at the init and wrapper scripts for a while, but could not get back to where I was, let alone fix the original problem. I gave up, deleted all Gitea files, and started fresh.

I am now back to where I was, with the same two messages and my changes to app.ini not taking effect. This time I don't want to mess with anything before I understand exactly what's going on. Can anyone provide some insight? Thanks.

[zeripath]

The FHS compliant script wasn't really intended to be used with special inits like that - rather it was just to make normal working practice work - with that init it's intended that you just point it to the Gitea binary.

(The purpose of the FHS compliant script is to allow one to use standard scripts without special adjustments. I'm also not certain how start-stop-daemon reacts to a script in exec - it may work but you likely need to use the pid option on the Gitea command and adjust accordingly.)

However let's look at what went wrong:

1. The config value: this is a weird failure - the FHS script shouldn't have failed like that as it tries to spot -c arguments. I suspect what has happened is that you have ended up with two -c on the resulting command but I'm not sure why the FHS script has done that. I think it's the DAEMON_ARGS here:

gitea/contrib/init/debian/gitea

Line 44 in d59536c

--exec $DAEMON -- $DAEMON_ARGS"

I suspect that DAEMON_ARGS is being passed as a single argument and not being split by field when it's passed to exec. I suspect that line should use ${DAEMON_ARGS} instead to ensure that the arguments are split. (No surrounding quotes and I'm not sure if that's the right syntax.)

Some judicious use of echo should be able to prove my suspicions.

2. The home directory issue is quite interesting... The code it's eventually calling is this:

https://github.com/unknwon/com/blob/da59b551951d50441ca26b7a8cd81317f34df87f/path.go#L63-L80

If this returns an error then you get the log message you're seeing.

Basically it looks like the HOME environment variable isn't set.

That's very odd as if it's in the environment for the FHS script then it should be in the environment for the Gitea command, leading to the conclusion that:

gitea/contrib/init/debian/gitea

Lines 42 to 44 in d59536c

	sh -c "USER=$USER HOME=/home/$USER GITEA_WORK_DIR=$WORKINGDIR start-stop-daemon --start --quiet --pidfile $PIDFILE --make-pidfile \\
	--background --chdir $WORKINGDIR --chuid $USER \\
	--exec $DAEMON -- $DAEMON_ARGS"

Is not passing the HOME variable to Gitea

A quick look at stack overflow confirms my suspicion, start-stop-daemon does not pass the environment:

https://serverfault.com/questions/128389/can-start-stop-daemon-use-environmental-variables

The exec command would need to be --exec "/usr/bin/env HOME=/home/$USER $DAEMON" - I guess you could also try sticking an export HOME in the init script somewhere? (I'd avoid sticking the HOME in the FHS script as it's likely to be the wrong thing in general.) Similarly for the rest of the variables.

So although the problem looked like it was with the FHS script and the interaction with the init script at the start - I suspect it's more a few bugs with the init script. See if you can fix the two things I've mentioned and if restart works properly with the FHS script in place - if not you might need to point the init script directly at the shadowed Gitea binary but keep in touch with us and we can update the contrib script with your findings.

[chaosmonk1]

@zeripath

Thanks for your response, and for being willing to provide support for my nonstandard configuration.

I suspect that DAEMON_ARGS is being passed as a single argument and not being split by field when it's passed to exec. I suspect that line should use ${DAEMON_ARGS} instead to ensure that the arguments are split. (No surrounding quotes and I'm not sure if that's the right syntax.)

I replaced $DAEMON_ARGS with ${DAEMON_ARGS}, although if I understand correctly, the braces are only necessary to clarify $foobar versus ${foo}bar and I don't think will make a difference here.

The exec command would need to be --exec "/usr/bin/env HOME=/home/$USER $DAEMON" - I guess you could also try sticking an export HOME in the init script somewhere? (I'd avoid sticking the HOME in the FHS script as it's likely to be the wrong thing in general.) Similarly for the rest of the variables.

This seems to conflict with the previous change, as it omits $DAEMON_ARGS or ${DAEMON_ARGS} entirely. Also, in the original script the double quotes are around the whole three lines beginning from sh -c, whereas you have them starting after --exec, so I am a little confused. I going to guess that that I should replace --exec $DAEMON -- $DAEMON_ARGS with --exec /usr/bin/env HOME=/home/$USER $DAEMON -- ${DAEMON_ARGS}, but let me know if that's not what you meant. I've done that, and restarting the daemon gives me the same two errors.

So although the problem looked like it was with the FHS script and the interaction with the init script at the start - I suspect it's more a few bugs with the init script. See if you can fix the two things I've mentioned and if restart works properly with the FHS script in place - if not you might need to point the init script directly at the shadowed Gitea binary but keep in touch with us and we can update the contrib script with your findings.

I tried reverting the changes I just made to the init script, setting DAEMON=/usr/lib/gitea/gitea, and restarting, and I get the same two errors. That's not what I expected. I thought I'd get a different error, which made me wonder if these changes are really taking effect, so I ran sudo service gitea stop, and got the output

Stopping Gitea - Git with a cup of tea gitea

but then went back to my browser and am still able to browse Gitea. If it's still running then stop doesn't work, which means that restart likely doesn't work either, and so I haven't really been testing the changes I've made to the script. Now that I think about it, the 500 errors might have appeared after a reboot, and after reverting my changes I only used restart to attempt to get back to where I was. I'm afraid to reboot now...

I am not particularly committed to using the init script or the FSH script. Those are just the things I tried. What do you think is the path of least resistance to a working setup with SysVinit?

[chaosmonk1]

I'm afraid to reboot now...

Okay, I did try rebooting with the init script pointing directly to the binary in /usr/lib/gitea/gitea. Gitea did not start automatically, so I ran sudo service gitea start, and got the same two errors as usual, but once Gitea started, my changes to app.ini did take effect. So things are sort of working in the sense that I could get by like this, but not in a way I feel in control of.

[zeripath]

Ok. Redrop the -c from Daemon args and stick into the Gitea FHS script:

if [ -z "$HOME" ]; then
	export HOME="/home/$USER"
fi

(That's assuming that user gets set otherwise you could just export HOME=/home/git.)

I'm still concerned that the arguments are being passed as a single argument not as separate arguments. You could test that by adding an echo in the appropriate place in the script. That could be the fault of the start-stop-daemon script.

As I said above I would worry that stop and restart aren't going to work properly with execing a script - you likely need to make Gitea make it's own pid file --pid or, and I'm guessing here, change the FHS script to use exec on the last line (you want the pid of the script to become the pid of the binary - I think that's the way to do it.)

In terms of actual Gitea issues here - I think we should reconsider if we really need the HOME environment set. We probably do because of git and gpg but I'll have a think.

Finally why are you using sysvinit? It really does require a lot of shell knowledge.

[chaosmonk1]

Thanks. You put me on the right track, and I think I have everything working now. I decided to give up on the FSH wrapper, accept that Gitea looks for everything in its own directory, and wherever that annoys me to give Gitea a symlink to my preferred location.

• I got rid of the wrapper script, and just placed the Gitea binary in /usr/lib/gitea/.

• I made /usr/lib/gitea/custom/conf/app.ini a symlink to /etc/gitea/app.ini.

• I'm using this as my init script:

#!/bin/sh
### BEGIN INIT INFO
# Provides:          gitea
# Required-Start:    $syslog $network
# Required-Stop:     $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: A self-hosted Git service written in Go.
# Description:       A self-hosted Git service written in Go.
### END INIT INFO

# Author: Danny Boisvert

# Do NOT "set -e"

# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin
DESC="Gitea - Git with a cup of tea"
NAME=gitea
SERVICEVERBOSE=yes
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
WORKINGDIR=/var/lib/$NAME
DAEMON=/usr/lib/$NAME/$NAME
DAEMON_ARGS="web"
USER=git
USERBIND=""
# If you want to bind Gitea to a port below 1024 uncomment
# the line below
#USERBIND="setcap cap_net_bind_service=+ep"
STOP_SCHEDULE="${STOP_SCHEDULE:-QUIT/5/TERM/1/KILL/5}"

# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME

# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0

do_start()
{
    start-stop-daemon --start --quiet --pidfile $PIDFILE --make-pidfile --background --chdir $WORKINGDIR --chuid $USER --exec /usr/bin/env HOME="/home/git" $DAEMON -- $DAEMON_ARGS
}

do_stop()
{
    start-stop-daemon --stop --quiet --retry=$STOP_SCHEDULE --pidfile $PIDFILE --name $NAME --oknodo
    rm -f $PIDFILE
}

do_status()
{
    if [ -f $PIDFILE ]; then
        if kill -0 $(cat "$PIDFILE"); then
            echo "$NAME is running, PID is $(cat $PIDFILE)"
        else
            echo "$NAME process is dead, but pidfile exists"
        fi
    else
        echo "$NAME is not running"
    fi
}

case "$1" in
    start)
        echo "Starting $DESC" "$NAME"
        do_start
        ;;
    stop)
        echo "Stopping $DESC" "$NAME"
        do_stop
        ;;
    status)
        do_status
        ;;
    restart)
        echo "Restarting $DESC" "$NAME"
        do_stop
        do_start
        ;;
    *)
        echo "Usage: $SCRIPTNAME {start|stop|status|restart}" >&2
        exit 2
        ;;
esac

exit 0

Gitea now runs with no errors and respects /etc/gitea/app.ini, and stop and restart work. After running update-rc.d gitea defaults, Gitea also starts upon rebooting.

Thanks for all your help. Closing.