Description of problem: When starting the borgmatic service, systemctl doesn't return until the backup has finished, which could be hours. During all the backup the service unit is in state "activating". Using Type=simple in the systemd service unit makes more sense. Version-Release number of selected component (if applicable): borgmatic-1.5.21-1.fc35.noarch How reproducible: Always Steps to Reproduce: 1. systemctl start borgmatic.service Actual results: The systemctl doesn't return until the backup has finished. The service unit is in status activating. Expected results: systemctl should return immediately after the borgmatic process has been forked. Additional info:
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.