Ctrl-C-ing borgmatic doesn't terminate Borg #1015

Closed
opened 2025-03-02 16:57:12 +00:00 by witten · 2 comments
Owner

What I'm trying to do and why

As per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1095980, pressing ctrl-C while borgmatic is running Borg does not terminate Borg. This seems like a regression, in that I'm pretty sure older versions of borgmatic used to terminate Borg. It's also possible although less likely that this is a Borg regression rather than anything wrong with borgmatic.

I reproduced this behavior on both borgmatic 1.9.3 and borgmatic main.

Steps to reproduce

  • Put some sizable directories into source_directories so that the borgmatic run isn't too fast to ctrl-C.
  • Run a create: borgmatic -c test.yaml create -v 2 --list (similar behavior for check)
  • Once Borg is running, press Ctrl-C.

Actual behavior

  • borgmatic exits
  • Borg is still running:
# ps xua | grep borg
root     2535625  4.6  0.0   2732  1968 pts/3    S    08:50   0:00 /root/borg1.4.0 create --patterns-from /tmp/borgmatic-xt9v7v3c/borgmatic/tmprfkon7tk --list --filter AMEx- --debug --show-rc 1.2.borg::{hostname}-{now:%Y-%m-%dT%H:%M:%S.%f}
root     2535626 98.3  0.7  92172 60364 pts/3    R    08:50   0:05 /root/borg1.4.0 create --patterns-from /tmp/borgmatic-xt9v7v3c/borgmatic/tmprfkon7tk --list --filter AMEx- --debug --show-rc 1.2.borg::{hostname}-{now:%Y-%m-%dT%H:%M:%S.%f}
root     2535683  0.0  0.0   6404  4008 pts/3    S+   08:50   0:00 grep borg

Expected behavior

Borg isn't running.

Other notes / implementation ideas

No response

borgmatic version

1.9.3 and main

borgmatic installation method

pipx install --editable

Borg version

1.4.0

Python version

3.13.1

Database version (if applicable)

No response

Operating system and version

No response

### What I'm trying to do and why As per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1095980, pressing ctrl-C while borgmatic is running Borg does not terminate Borg. This seems like a regression, in that I'm pretty sure older versions of borgmatic used to terminate Borg. It's also possible although less likely that this is a Borg regression rather than anything wrong with borgmatic. I reproduced this behavior on both borgmatic 1.9.3 and borgmatic main. ### Steps to reproduce * Put some sizable directories into `source_directories` so that the borgmatic run isn't too fast to ctrl-C. * Run a create: `borgmatic -c test.yaml create -v 2 --list` (similar behavior for `check`) * Once Borg is running, press Ctrl-C. ### Actual behavior * borgmatic exits * Borg is still running: ```bash # ps xua | grep borg root 2535625 4.6 0.0 2732 1968 pts/3 S 08:50 0:00 /root/borg1.4.0 create --patterns-from /tmp/borgmatic-xt9v7v3c/borgmatic/tmprfkon7tk --list --filter AMEx- --debug --show-rc 1.2.borg::{hostname}-{now:%Y-%m-%dT%H:%M:%S.%f} root 2535626 98.3 0.7 92172 60364 pts/3 R 08:50 0:05 /root/borg1.4.0 create --patterns-from /tmp/borgmatic-xt9v7v3c/borgmatic/tmprfkon7tk --list --filter AMEx- --debug --show-rc 1.2.borg::{hostname}-{now:%Y-%m-%dT%H:%M:%S.%f} root 2535683 0.0 0.0 6404 4008 pts/3 S+ 08:50 0:00 grep borg ``` ### Expected behavior Borg isn't running. ### Other notes / implementation ideas _No response_ ### borgmatic version 1.9.3 and main ### borgmatic installation method pipx install --editable ### Borg version 1.4.0 ### Python version 3.13.1 ### Database version (if applicable) _No response_ ### Operating system and version _No response_
Author
Owner

This has been "fixed" in main by sending SIGINT followed by a SIGTERM to Borg whenever borgmatic receives a SIGINT (ctrl-C). The delta from prior versions is the addition of the SIGTERM. I made this change because I determined via strace that borgmatic was forwarding SIGINT to Borg correctly, but in some cases Borg is ignoring it or just not taking action right away. I considered that maybe it'd be best to leave that decision to Borg, but then again it makes for a pretty poor user experience if a background Borg process just continues chewing CPU (and leaving a repository lock in place) after the user pretty clearly expressed their interest in interrupting both borgmatic and Borg. So I decided to give Borg a little extra encouragement in the form of a bonus SIGTERM.

Note that this change applies across the board to all child processes (database clients, filesystem snapshot executables, etc.).. Not just Borg.

This will be part of the next release.

This has been "fixed" in main by sending SIGINT followed by a SIGTERM to Borg whenever borgmatic receives a SIGINT (ctrl-C). The delta from prior versions is the addition of the SIGTERM. I made this change because I determined via strace that borgmatic *was* forwarding SIGINT to Borg correctly, but in some cases [Borg is ignoring it](https://github.com/borgbackup/borg/issues/7893) or just not taking action right away. I considered that maybe it'd be best to leave that decision to Borg, but then again it makes for a pretty poor user experience if a background Borg process just continues chewing CPU (and leaving a repository lock in place) after the user pretty clearly expressed their interest in interrupting both borgmatic and Borg. So I decided to give Borg a little extra encouragement in the form of a bonus SIGTERM. Note that this change applies across the board to all child processes (database clients, filesystem snapshot executables, etc.).. Not just Borg. This will be part of the next release.
Author
Owner

Released in borgmatic 1.9.13!

Released in borgmatic 1.9.13!
Sign in to join this conversation.
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
borgmatic-collective/borgmatic#1015
No description provided.