You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When running the following dump command (from within a systemd unit running as the same user as the gitea process, everything is set up properly on that end), the dump appears to successfully create a backup archive, but the process logs errors and more importantly, exits non-zero.
systemd[1]: Starting Gitea Backup...
gitea-backup[3784944]: 2023/03/21 23:58:38 ...es/setting/server.go:328:loadServerFrom() [I] The provided APP_DATA_PATH: data is not absolute - it will be made absolute against the work path: /var/lib/gitea
gitea-backup[3784944]: 2023/03/21 23:58:38 ...dules/setting/log.go:331:initLogFrom() [I] Gitea Log Mode: Console(Console:info)
gitea-backup[3784944]: 2023/03/21 23:58:38 ...dules/setting/log.go:286:generateNamedLogger() [I] Router Log: Console(console:info)
gitea-backup[3784944]: 2023/03/21 23:58:38 ...les/setting/cache.go:75:loadCacheFrom() [I] Cache Service Enabled
gitea-backup[3784944]: 2023/03/21 23:58:38 ...les/setting/cache.go:90:loadCacheFrom() [I] Last Commit Cache Service Enabled
gitea-backup[3784944]: 2023/03/21 23:58:38 ...s/setting/session.go:74:loadSessionFrom() [I] Session Service Enabled
gitea-backup[3784944]: 2023/03/21 23:58:38 ...s/storage/storage.go:175:initAttachments() [I] Initialising Attachment storage with type: local
gitea-backup[3784944]: 2023/03/21 23:58:38 ...les/storage/local.go:45:NewLocalStorage() [I] Creating new Local Storage at /var/lib/gitea/data/attachments
gitea-backup[3784944]: 2023/03/21 23:58:38 ...s/storage/storage.go:165:initAvatars() [I] Initialising Avatar storage with type: local
gitea-backup[3784944]: 2023/03/21 23:58:38 ...les/storage/local.go:45:NewLocalStorage() [I] Creating new Local Storage at /var/lib/gitea/data/avatars
gitea-backup[3784944]: 2023/03/21 23:58:38 ...s/storage/storage.go:191:initRepoAvatars() [I] Initialising Repository Avatar storage with type: local
gitea-backup[3784944]: 2023/03/21 23:58:38 ...les/storage/local.go:45:NewLocalStorage() [I] Creating new Local Storage at /var/lib/gitea/data/repo-avatars
gitea-backup[3784944]: 2023/03/21 23:58:38 ...s/storage/storage.go:197:initRepoArchives() [I] Initialising Repository Archive storage with type: local
gitea-backup[3784944]: 2023/03/21 23:58:38 ...les/storage/local.go:45:NewLocalStorage() [I] Creating new Local Storage at /var/lib/gitea/data/repo-archive
gitea-backup[3784944]: 2023/03/21 23:58:38 cmd/dump.go:246:runDump() [I] Dumping local repositories... /var/lib/gitea/repos
gitea-backup[3784944]: Failed to dump LFS objects: LFS isn't enabled
gitea-backup[3784944]: 2023/03/22 00:08:15 cmd/dump.go:162:fatal() [F] Failed to dump LFS objects: LFS isn't enabled
systemd[1]: gitea-backup.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: gitea-backup.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Gitea Backup.
systemd[1]: gitea-backup.service: Consumed 9min 23.556s CPU time.
A workaround I am using now is to add --skip-lfs-data --skip-package-data to the dump command.
gitea doctor
A similar but not identical issue exists for the following gitea doctor command, where it logs errors but does exit zero:
systemd[1]: Starting Gitea Doctor: logs about whether there are config/db issues, etc....
gitea-doctor[3785590]: [1] Garbage collect LFS
gitea-doctor[3785590]: ERROR
gitea-doctor[3785590]: [2] Check paths and basic configuration
gitea-doctor[3785590]: - [I] Configuration File Path: "/etc/gitea/app.ini"
gitea-doctor[3785590]: - [I] Repository Root Path: "/var/lib/gitea/repos"
gitea-doctor[3785590]: - [I] Data Root Path: "/var/lib/gitea/data"
gitea-doctor[3785590]: - [I] Custom File Root Path: "/var/lib/gitea/custom"
gitea-doctor[3785590]: - [I] Work directory: "/var/lib/gitea"
gitea-doctor[3785590]: - [I] Log Root Path: "/var/log/gitea/"
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [3] Check if there are orphaned archives in storage
gitea-doctor[3785590]: - [I] Found 0 (0 B) repo archive(s)
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [4] Check if there are orphaned attachments in storage
gitea-doctor[3785590]: - [I] Found 0 (0 B) attachment(s)
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [5] Check if there are orphaned avatars in storage
gitea-doctor[3785590]: - [I] Found 1 (642 B) avatar(s)
gitea-doctor[3785590]: - [I] Found 0 (0 B) repo avatar(s)
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [6] Check if there are orphaned lfs files in storage
gitea-doctor[3785590]: - [E] Error whilst iterating LFS file storage: LFS isn't enabled
gitea-doctor[3785590]: ERROR
gitea-doctor[3785590]: [7] Check if there are orphaned package blobs in storage
gitea-doctor[3785590]: - [E] Error whilst iterating package blob storage: Packages isn't enabled
gitea-doctor[3785590]: ERROR
gitea-doctor[3785590]: [8] Check if there are orphaned storage files
gitea-doctor[3785590]: - [I] Found 0 (0 B) attachment(s)
gitea-doctor[3785590]: - [E] Error whilst iterating LFS file storage: LFS isn't enabled
gitea-doctor[3785590]: ERROR
gitea-doctor[3785590]: [9] Check Database Version
gitea-doctor[3785590]: - [I] Expected database version: 244
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [10] Check consistency of database
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [11] Check if user with wrong type exist
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [12] Check if OpenSSH authorized_keys file is up-to-date
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [13] Check if SCRIPT_TYPE is available
gitea-doctor[3785590]: - [I] ScriptType bash is on the current PATH at /usr/bin/bash
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [14] Check if hook files are up-to-date and executable
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [15] Recalculate Stars number for all user
gitea-doctor[3785590]: - [I] No check available for User Stars numbers (skipped)
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [16] Check old archives
gitea-doctor[3785590]: - [I] 0 old archives in repository need to be deleted
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [17] Check that all git repositories have receive.advertisePushOptions set to true
gitea-doctor[3785590]: - [I] Checked 17 repositories, 0 need updates.
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [18] Check for incorrectly dumped repo_units (See #16961)
gitea-doctor[3785590]: - [I] Found no broken repo_units
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [19] Recalculate merge bases
gitea-doctor[3785590]: - [I] All 0 PRs in 17 repos have a correct mergebase
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [20] Synchronize repo HEADs
gitea-doctor[3785590]: - [I] All 17 repos have their HEADs in the correct state
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [21] Check git-daemon-export-ok files
gitea-doctor[3785590]: - [I] Checked 17 repositories, 0 need updates.
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [22] Check commit-graphs
gitea-doctor[3785590]: - [I] Checked 17 repositories, 17 without commit-graphs.
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [23] Check if users has an valid email address
gitea-doctor[3785590]: - [I] All users have a valid e-mail.
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [24] Check if users have a valid username
gitea-doctor[3785590]: - [I] All users have a valid username.
gitea-doctor[3785590]: OK
systemd[1]: gitea-doctor.service: Succeeded.
systemd[1]: Finished Gitea Doctor: logs about whether there are config/db issues, etc..
There is no convenient workaround that eliminates the ERRORs from the log, but it's acceptable because I have to manually inspect the log anyway, and at least the process doesn't exit non-zero.
Expectations/desired behavior
The reason I think this is a bug, is that certainly for dump, I don't think any valid configuration should cause a standard gitea dump command to fail. It should not be necessary for the standard dump command to be modified just because of config.
IMO the same applies for gitea doctor --all, ideally it would mark as SKIP or even OK any tests that only ERROR because the relevant feature is turned off.
Also important to note, that this did not occur in 1.18.x versions.
Gitea Version
Gitea version 1.19.0 built with GNU Make 4.1, go1.20.2 : bindata, sqlite, sqlite_unlock_notify
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
git version 2.39.2
Operating System
Debian GNU/Linux 11 (bullseye)
How are you running Gitea?
Running the latest pre-built x86_64 release from go-gitea/gitea releases (i.e., using one of your downloads).
Running gitea itself in a systemd unit, and running both the backup and doctor commands in systemd units as well.
Close#23622
As described in the issue, disabling the LFS/Package settings will cause
errors when running `gitea dump` or `gitea doctor`. We need to check the
settings and the related operations should be skipped if the settings
are disabled.
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Closego-gitea#23622
As described in the issue, disabling the LFS/Package settings will cause
errors when running `gitea dump` or `gitea doctor`. We need to check the
settings and the related operations should be skipped if the settings
are disabled.
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Backport #23631Close#23622
As described in the issue, disabling the LFS/Package settings will cause
errors when running `gitea dump` or `gitea doctor`. We need to check the
settings and the related operations should be skipped if the settings
are disabled.
Description
My /etc/gitea/app.ini contains the following to disable LFS and packages:
gitea dump
When running the following dump command (from within a systemd unit running as the same user as the gitea process, everything is set up properly on that end), the dump appears to successfully create a backup archive, but the process logs errors and more importantly, exits non-zero.
Here is the log taken from journalctl output:
A workaround I am using now is to add
--skip-lfs-data --skip-package-data
to the dump command.gitea doctor
A similar but not identical issue exists for the following gitea doctor command, where it logs errors but does exit zero:
Log output:
There is no convenient workaround that eliminates the ERRORs from the log, but it's acceptable because I have to manually inspect the log anyway, and at least the process doesn't exit non-zero.
Expectations/desired behavior
The reason I think this is a bug, is that certainly for dump, I don't think any valid configuration should cause a standard
gitea dump
command to fail. It should not be necessary for the standard dump command to be modified just because of config.IMO the same applies for
gitea doctor --all
, ideally it would mark as SKIP or even OK any tests that only ERROR because the relevant feature is turned off.Also important to note, that this did not occur in 1.18.x versions.
Gitea Version
Gitea version 1.19.0 built with GNU Make 4.1, go1.20.2 : bindata, sqlite, sqlite_unlock_notify
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
git version 2.39.2
Operating System
Debian GNU/Linux 11 (bullseye)
How are you running Gitea?
Running the latest pre-built x86_64 release from go-gitea/gitea releases (i.e., using one of your downloads).
Running gitea itself in a systemd unit, and running both the backup and doctor commands in systemd units as well.
The gitea unit is primarily:
The backup and doctor units are essentially the same basic structure.
Database
SQLite
The text was updated successfully, but these errors were encountered: