Dump doesn't produce any output

[Rychu-Pawel]

• Gitea version: Gitea version 1.9.3 built with GNU Make 4.1, go1.12.9 : bindata, sqlite, sqlite_unlock_notify
• Git version: 2.17.1
• Operating system: Ubuntu server 18.04.3
• Database:
  • PostgreSQL
  • MySQL - MariaDB 10.1
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:

2019/11/21 19:09:58 ...dules/setting/log.go:269:newLogService() [I] Gitea Log Mode: File(File:info)
2019/11/21 19:09:58 ...les/setting/cache.go:42:newCacheService() [I] Cache Service Enabled
2019/11/21 19:09:58 ...s/setting/session.go:45:newSessionService() [I] Session Service Enabled
2019/11/21 19:09:58 ...es/setting/mailer.go:105:newMailService() [I] Mail Service Enabled
2019/11/21 19:09:58 ...es/setting/mailer.go:116:newRegisterMailService() [I] Register Mail Service Enabled
2019/11/21 19:09:58 ...es/setting/mailer.go:127:newNotifyMailService() [I] Notify Mail Service Enabled
2019/11/21 19:09:58 cmd/dump.go:76:runDump() [I] Creating tmp work dir: /tmp/gitea-dump-586735121
2019/11/21 19:09:58 cmd/dump.go:86:runDump() [I] Packing dump files...

Description

I started to configure the backup of my gitea instance. Unfortunatly dump command

sudo -u git /usr/local/bin/gitea dump -c /etc/gitea/app.ini -f ./gitea.zip -V

gives me only one line of output:

2019/11/21 19:09:58 ...dules/setting/git.go:83:newGit() [I] Git Version: 2.17.1

I can find more info in the log file (above) but this doesn't give me any hints neither. It looks like it just stopped in the middle.
When setting up the server I had to deal with this issue regarding barracuda and innodb_large_prefix #2979 and also now I found this similar issue report #8941 where missing migrations were the problem. I feel like this is a hint to my case but need help connecting all the dots.

[JacquesOfAllTrades]

Coincidentally, I just encountered the same behavior when using the --tempdir <my_temp_dir> argument, when the directory <my_temp_dir> didn't exist. Once I fixed that, the output shows all the expected "Adding file..." and "Adding dir..." progress messages before hitting a different failure. :/

Anyway, you might want to check that /tmp exists and is world-writable, that the partition isn't full, etc. Just an idea--your problem could be entirely unrelated.

[EDIT] I'm using Gitea 1.9.5.

[EDIT 2] I agree that Gitea should print an error rather than silently stopping the dump. That may be a secondary bug.

[Rychu-Pawel]

Thanks for the hint I found the issue and it was connected to your finding! Thanks!
The problem was so obvious... I was running this command from my user's directory so user git didn't have rights to create and write to a zip file there. Changed the command to
sudo -u git /usr/local/bin/gitea dump -c /etc/gitea/app.ini -f /tmp/gitea.zip -V
and everything went well!

There definitely should be an error message saying what's wrong. Should I close this issue or keep it open as a placeholder for adding an error message discussion?

[lunny]

This issue could be closed and any document update PRs are welcome!

[Rychu-Pawel]

I looked at this a bit and the issue is that log.Fatalf doesn't make it to flush the buffor before the application exits in line 88 of dump.go. There was even a discussion regarding that here golang/go#21751
For me this is my day 1 with golang but I guess there is not much we can do about this missing error log.

[guillep2k]

But we could have our own replacement for log.Fatalf(), so maybe take care of this. These seem to be calls from dump.go, not something buried in the nth call of a third-party library.