| Summary: | Use Type=simple in systemd service unit | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Juan Orti <jorti> |
| Component: | borgmatic | Assignee: | Felix Kaechele <felix> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 35 | CC: | felix, julien.nicoulaud |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | borgmatic-1.6.0-1.fc34 borgmatic-1.6.0-1.fc35 borgmatic-1.6.0-1.fc36 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-05-04 13:13:39 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Juan Orti
2022-01-27 14:28:54 UTC
borgmatic.service is not intended to be run using systemctl start. It is intended to be used in conjunction with borgmatic.timer and it will be called by this. This is why you also cannot systemctl enable borgmatic. The service unit contains lots of optimizations that make it better suited for running backups as a background task. If you want to run an ad-hoc backup run, simply running "borgmatic" would effectively achieve the same thing. I've looked into this a bit nonetheless and found changing it from oneshot to simple would have the downside of not accurately being able to track failure states in systemd. While investigating I did find a bug I'm introducing by replacing the executable path in the sample systemd unit. By doing this I'm effectively eliminating the logic in the systemd unit that ensures no backups are run until after boot completes. So thanks for leading me down that path, I'm fixing it with the next update :) FEDORA-2022-d977ab8ff0 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-d977ab8ff0 FEDORA-2022-da97d56901 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-da97d56901 FEDORA-2022-d977ab8ff0 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-d977ab8ff0` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-d977ab8ff0 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2022-c772010c46 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-c772010c46` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-c772010c46 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2022-da97d56901 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-da97d56901` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-da97d56901 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2022-c772010c46 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2022-da97d56901 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2022-d977ab8ff0 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report. |