After upgrading Synology and Debian Server, my borgmatic no longer terminates with systemd #801
Labels
No Label
bug
data loss
design finalized
good first issue
new feature area
question / support
security
waiting for response
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: borgmatic-collective/borgmatic#801
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What I'm trying to do and why
Launch my borgbackup throught borgmatic with systemd service and timer
My /etc/borgmatic/config.yaml
My /etc/systemd/system/borgmatic.service
On the server side, it's a Synology with
Steps to reproduce
No response
Actual behavior
Run the command manually as root, create the backup correctly, perform the checks and finish successfully.
/usr/bin/borgmatic --verbosity 1
BUT
Starting the service manually never ends and remains inactive indefinitely
systemctl restart borgmatic.service &
Expected behavior
I don't understand the difference between the two and where I need to look to get my backup to work as it did before my upgrades on Synology and Server.
I think it's more a SystemD trouble but not sure ...
Other notes / implementation ideas
No response
borgmatic version
1.8.3
borgmatic installation method
Debian package
Borg version
1.2.7
Python version
Python 3.11.2
Database version (if applicable)
No response
Operating system and version
Debian GNU/Linux 12 (bookworm) + testing package for borg & borgmatic
My borgmatic does not terminate with systemdto My borgmatic no more terminate with systemd after Synology and Debian Server upgradeMy borgmatic no more terminate with systemd after Synology and Debian Server upgradeto After upgrading Synology and Debian Server, my borgmatic no longer terminates with systemdI'm not exactly sure what's going on here, but I do have some ideas:
LockPersonality
toCapabilityBoundingSet
, reload the service, and then try to reproduce the problem.I see that when you run borgmatic with systemd, the log ends with
Exiting due to TERM signal
. Is that you manually killing the process? Because if the process remains active indefinitely, I would not expect to see it exit.Indeed, when I comment out the postgres and mariadb lines in config.yaml, the systemd service terminates successfully
I've tried with each one separately, but as soon as there's a DB dump, cel skates around in a vacuum.
However, I don't understand why it works when I run the command manually.
I'll run it with a cron tonight and post the result
Thank you very much for this step forward.
Any other ideas for solving this problem?
Nothing change with this test
Yes, I killed -HUP the process
One difference I can see in the output is that the log entry for
Excluding special files to prevent Borg from hanging
shows many more files when you're running borgmatic manually compared to when you're running with systemd. That might indicate that some files that should be excluded to prevent hanging aren't being excluded. This file in particular looks pretty interesting:/root/recovery/tmp/borgmatic/postgresql_databases/localhost/all
. If it's an old named pipe that for whatever reason isn't getting excluded with systemd, that could cause Borg to hang.You were right !
I've deleted these broken elements and taken the opportunity to archive the unnecessary content.
Since then, the systemd service has been working perfectly.
(I won't close the ticket in case you need any further information, otherwise feel free to close this ticket)
Thank you very very much !
Glad to hear that did it for you! The one thing I don't understand though is why those problem files got auto-excluded when borgmatic was run manually but not when run under systemd. I'm fine closing this for now, but if this reoccurs again, please let me know and we can dive into how those various systemd service options may be impacting this. Thanks!