dump creates empty zip file

[muellert]

• Gitea version (or commit ref): 1.9.5
• Git version: 2.11
• Operating system: Debian 9.9 amd64
• 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

When I try to create a backup, I run 'gitea dump -c /path/to/app.ini -t /var/tmp' because there is not enough space on /tmp.

The result is a directory in /var/tmp. Example (I have repeated this several times):

$ ls -al /var/tmp/gitea-dump-508575557
total 232284
drwx------ 2 _gitea _gitea 4096 Nov 12 23:30 ./
drwxrwxrwt 10 root root 4096 Nov 12 23:29 ../
-rw-r--r-- 1 _gitea _gitea 1362032 Nov 12 23:30 gitea-db.sql
-rw-r--r-- 1 _gitea _gitea 236244910 Nov 12 23:30 gitea-repo.zip
$

The command exits silently with an exit code of 1.

In the directory, from where I started the command, there is an empty zip file, which just has the header:

$ ls -l gitea-dump-1573597794.zip
-rw-r--r-- 1 _gitea _gitea 22 Nov 12 23:29 gitea-dump-1573597794.zip
$

...

Screenshots

[JacquesOfAllTrades]

Gitea: 1.9.5
Git: 2.17.1
OS: Ubuntu Server 18.04.3 LTS
Database: PosgreSQL

Same problem here, with or without the --tempdir option.

The command I'm running, with relevant output (paths changed for privacy):

$ gitea dump -c /jacques/git/home/custom/conf/app.ini -f "gitea-20191126.zip" -V
2019/11/26 17:15:47 ...dules/setting/git.go:83:newGit() [I] Git Version: 2.17.1
Adding dir.../jacques/git/repositories/jacques
Adding dir.../jacques/git/repositories/jacques/jacques-website.git
Adding file.../jacques/git/repositories/jacques/jacques-website.git/config
[...lines cut for brevity...]
Adding dir.../jacques/git/repositories/user1
Adding dir.../jacques/git/repositories/user2
$ 

There's no error logged, but the result is an empty .zip file:

$ ls -l
-rw-rw-r-- 1 git git        22 Nov 26 17:15 gitea-20191126.zip

Meanwhile, the contents of the dump are left in the temp directory:

$ ls -l /tmp
drwx------ 2 git  git  4096 Nov 26 17:16 gitea-dump-745428022
$ ls -l /tmp/gitea-dump-745428022/
-rw-rw-r-- 1 git git   1163586 Nov 26 17:16 gitea-db.sql
-rw-rw-r-- 1 git git 859719475 Nov 26 17:16 gitea-repo.zip

The same dump command worked fine with Gitea 1.9.1.

Thanks for all your work, devs! I've been using Gitea since about 1.5 and am very happy overall.

[JacquesOfAllTrades]

Additional info: The problem occurs with or without the -f/--file option. Without -f, I just end up with an empty ZIP file with the default name. :)

[JacquesOfAllTrades]

Aaaand the relevant snippet from /var/log/gitea/gitea.log:

2019/11/26 17:15:47 ...dules/setting/log.go:269:newLogService() [I] Gitea Log Mode: File(File:info)
2019/11/26 17:15:47 ...les/setting/cache.go:42:newCacheService() [I] Cache Service Enabled
2019/11/26 17:15:47 ...s/setting/session.go:45:newSessionService() [I] Session Service Enabled
2019/11/26 17:15:47 ...es/setting/mailer.go:105:newMailService() [I] Mail Service Enabled
2019/11/26 17:15:47 ...es/setting/mailer.go:116:newRegisterMailService() [I] Register Mail Service Enabled
2019/11/26 17:15:47 ...es/setting/mailer.go:127:newNotifyMailService() [I] Notify Mail Service Enabled
2019/11/26 17:15:47 cmd/dump.go:76:runDump() [I] Creating tmp work dir: /tmp/gitea-dump-745428022
2019/11/26 17:15:47 cmd/dump.go:86:runDump() [I] Packing dump files...
2019/11/26 17:15:47 cmd/dump.go:96:runDump() [I] Dumping local repositories.../jacques/git/repositories
2019/11/26 17:16:40 cmd/dump.go:110:runDump() [I] Dumping database...
2019/11/26 17:16:41 cmd/dump.go:122:runDump() [I] Adding custom configuration file from /jacques/git/home/custom/conf/app.ini
2019/11/26 17:22:55 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT "id", "lower_name", "name", "full_name", "email", [...]

The last relevant line is "Adding ... app.ini". Interestingly, after the dump command exits, the temp directory contains the repository and database dumps, but it doesn't contain app.ini. So it seems that step must have caused the dump to abort, but without any error being logged.

[JacquesOfAllTrades]

Well, I'm at a loss. It's working now, and damned if I know what I did to fix it.

The only persistent changes that I made relate to the host system and really don't explain how the issue might've been fixed:

• Ran some system updates (about 20 packages updated) and rebooted, but the dump did not work after that.
• Freed up some space on the root partition, dumps were still failing afterwards. (The Gitea installation, DB, repos, and backup destination are all on a /jacques partition with tons of space, and I was using -t to put the temp files on that partition as well).
• Disabled the swapfile and gave the system a couple more GB of RAM (it's a virtual machine). Dumps began working around the time I changed the swap settings, but it makes no sense that that would be related unless dump has some crazy sensitivity to timing.

I didn't change app.ini (or any other config files aside from a couple related to swapfile settings), I'm using the same Gitea executable as before, and I'm running dump with the same parameters as before.

The whole thing is completely baffling. I can only guess that there could've been multiple issues compounding to cause the failure, but at this point I'm just happy that it's working again. I'll have to wait and see if the dump succeeds when run by the weekly cron job later in the week.

[JacquesOfAllTrades]

I've got a new theory on the cause of my problem: At the time when the dump was failing for me, I had a copy of app.ini (named something like app-20191123.bak) in the .../git/home/custom/conf directory, but it was owned by root:root instead of git:git. Thus, when gitea dump tried to back up the conf directory, it didn't have permission to copy that file, and so the dump failed. (I haven't tried to recreate the problem, but I'm happy with this explanation.)

Due to issue #9218, Gitea didn't output any error message to indicate why it aborted the operation, so I was unable to identify my own mistake. Maybe the OP could be in a similar situation that can be resolved once the logging fix is deployed.

[muellert]

This is an interesting theory, and yes, I have lot of files like that as well, since I install and upgrade gitea via Ansible, and, for safety reasons, have Ansible keep backup files of the configurations. These end up being owned by root:root and named eg. "app.ini.22648.2019-08-03@13:18:47~". I don't think the presence of such files should break the backup. Maybe the backup should be restricted to files which are actually required for restoring a running gitea - ie, ignore those backup files? I am not sure.

[AndreasSummer]

Have the same issue with windows and administrator rights. Got an temp folder with an sql an a zip file with all the repository in it.

C:\gitea\gitea.exe dump -c C:\Gitea\custom\conf\app.ini -tempdir D:\backup\gitea -f D:\backup\gitea\backup.zip

[GAS85]

Try this theory and seems it does not work for me, I also have had backup file of app.ini owned by root, changing ownership to git does not help me at all. Even I move out backup file form the config directory, but it does not help too.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

[stale]

This issue has been automatically closed because of inactivity. You can re-open it if needed.