Bug 2047289

Summary: Use Type=simple in systemd service unit
Product: [Fedora] Fedora Reporter: Juan Orti <jorti>
Component: borgmaticAssignee: Felix Kaechele <felix>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 35CC: 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
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:

Comment 1 Felix Kaechele 2022-02-04 19:22:06 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 :)

Comment 2 Fedora Update System 2022-04-27 01:52:14 UTC
FEDORA-2022-d977ab8ff0 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-d977ab8ff0

Comment 3 Fedora Update System 2022-04-27 01:52:15 UTC
FEDORA-2022-da97d56901 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-da97d56901

Comment 4 Fedora Update System 2022-04-27 08:24:06 UTC
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.

Comment 5 Fedora Update System 2022-04-27 09:14:48 UTC
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.

Comment 6 Fedora Update System 2022-04-27 09:32:01 UTC
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.

Comment 7 Fedora Update System 2022-05-04 13:13:39 UTC
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.

Comment 8 Fedora Update System 2022-05-04 13:51:48 UTC
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.

Comment 9 Fedora Update System 2022-05-07 04:33:08 UTC
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.