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...
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
https://github.com/go-gitea/gitea/issues/2979 and also now I found this similar issue report https://github.com/go-gitea/gitea/issues/8941 where missing migrations were the problem. I feel like this is a hint to my case but need help connecting all the dots.
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.
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?
This issue could be closed and any document update PRs are welcome!
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 https://github.com/golang/go/issues/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.
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.
Most helpful comment
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 tosudo -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?