Arch Linux

vic_acid

Member

Registered: 2016-12-05

Posts: 13

[SOLVED] systemd errors when trying to start gitea

(Moved my previous version of this post from "Applications & Desktop Environments" to here since this seems like the better section of the forum)

I'm running into what look like systemd service errors when trying to start a fresh installation of gitea on a rebuilt server. I'm just using the built-in sqlite database backend for right now.

When I run

sudo systemctl start gitea

here's what I see in the journal:

Aug 10 18:17:07 new-alexandria systemd[1]: Started Gitea (Git with a cup of tea).
Aug 10 18:17:07 new-alexandria (gitea)[13701]: gitea.service: Failed to set up mount namespacing: /run/systemd/mount-rootfs/etc/gitea/app.ini: No such file or directory
Aug 10 18:17:07 new-alexandria (gitea)[13701]: gitea.service: Failed at step NAMESPACE spawning /usr/bin/gitea: No such file or directory
Aug 10 18:17:07 new-alexandria systemd[1]: gitea.service: Main process exited, code=exited, status=226/NAMESPACE
Aug 10 18:17:07 new-alexandria systemd[1]: gitea.service: Failed with result 'exit-code'.
Aug 10 18:17:09 new-alexandria systemd[1]: gitea.service: Scheduled restart job, restart counter is at 1.

This repeats until I stop the service.

For reference I'm using the latest arch kernel (6.4.9), the latest systemd (254.1), and the latest gitea (1.20.2), all from the arch repos.

gitea has worked in the past for me, and I ran it in an nspawn container then. I initially tried that for this and saw these same errors, so now I'm trying to install it directly on my server rather than in a container. However, as you can see, I'm still seeing these errors even when directly installed on the server.

Could this be an issue with the various privacy/sandboxing settings in the service file conflicting with something in version 254 of systemd? Is anyone else running into this?

Thanks in advance for any help or ideas you have.

Last edited by vic_acid (2023-08-11 05:18:10)

vic_acid

Member

Registered: 2016-12-05

Posts: 13

Re: [SOLVED] systemd errors when trying to start gitea

Think I figured out the issue: the package gitea.service specifies a file and not a directory:

ReadWritePaths=/etc/gitea/app.ini

which causes the service to fail with:

Aug 10 18:17:07 new-alexandria (gitea)[13701]: gitea.service: Failed to set up mount namespacing: /run/systemd/mount-rootfs/etc/gitea/app.ini: No such file or directory
Aug 10 18:17:07 new-alexandria (gitea)[13701]: gitea.service: Failed at step NAMESPACE spawning /usr/bin/gitea: No such file or directory
Aug 10 18:17:07 new-alexandria systemd[1]: gitea.service: Main process exited, code=exited, status=226/NAMESPACE
Aug 10 18:17:07 new-alexandria systemd[1]: gitea.service: Failed with result 'exit-code'.

when /etc/gitea/app.ini doesn't yet exist, such as when running the service for the first time to configure gitea to create app.ini.

Changing the service line to the directory (and not to the file):

ReadWritePaths=/etc/gitea/

will allow the gitea.service to start successfully.

Last edited by vic_acid (2023-08-11 05:19:46)

vic_acid

Member

Registered: 2016-12-05

Posts: 13

Re: [SOLVED] systemd errors when trying to start gitea

One more thing:

You can also append a minus (-) sign in front of the ReadWritePaths file name value in the package gitea.service:

ReadWritePaths=-/etc/gitea/app.ini

(per the systemd.exec(5) man page)

This will also allow the service to start successfully when /etc/gitea/app.ini doesn't exist yet, such as during initial setup.

loqs

Member

Registered: 2014-03-06

Posts: 18,224

Re: [SOLVED] systemd errors when trying to start gitea

Please consider opening a bug report on the Arch bugtracker so that the supplied service can be adjusted and others may benefit from your work.

vic_acid

Member

Registered: 2016-12-05

Posts: 13

Re: [SOLVED] systemd errors when trying to start gitea

Please consider opening a bug report on the Arch bugtracker so that the supplied service can be adjusted and others may benefit from your work.

Just submitted a bug report with a link to this post. Thanks for the prompting to do it