Dump doesn't produce any output #4369

New Issue

GiteaMirror · 2025-11-02T05:48:24-06:00

GiteaMirror commented

2025-11-02 05:48:24 -06:00

Originally created by @Rychu-Pawel on GitHub (Nov 21, 2019).

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 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.

Originally created by @Rychu-Pawel on GitHub (Nov 21, 2019). - 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 - [x] MySQL - MariaDB 10.1 - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] 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` 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.

GiteaMirror closed this issue

2025-11-02 05:48:25 -06:00

GiteaMirror commented

2025-11-02 05:48:25 -06:00

@JacquesOfAllTrades commented on GitHub (Nov 26, 2019):

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.

@JacquesOfAllTrades commented on GitHub (Nov 26, 2019): 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.

GiteaMirror commented

2025-11-02 05:48:26 -06:00

@Rychu-Pawel commented on GitHub (Nov 27, 2019):

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?

@Rychu-Pawel commented on GitHub (Nov 27, 2019): 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?

GiteaMirror commented

2025-11-02 05:48:26 -06:00

@lunny commented on GitHub (Nov 28, 2019):

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

@lunny commented on GitHub (Nov 28, 2019): This issue could be closed and any document update PRs are welcome!

GiteaMirror commented

2025-11-02 05:48:26 -06:00

@Rychu-Pawel commented on GitHub (Nov 30, 2019):

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.

@Rychu-Pawel commented on GitHub (Nov 30, 2019): 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.

GiteaMirror commented

2025-11-02 05:48:26 -06:00

@guillep2k commented on GitHub (Dec 1, 2019):

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.

@guillep2k commented on GitHub (Dec 1, 2019): 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.

GiteaMirror referenced this issue

2025-11-02 12:33:10 -06:00

[PR #4369] [MERGED] Add default merge options when creating new repository #17348

GiteaMirror referenced this issue

2025-11-02 12:52:55 -06:00

[PR #4373] [MERGED] Add default merge options when adding new repository (#4369) #17351

Sign in to join this conversation.