Have a hook firing when the process exits because of CTRL+C. #434

New Issue

Closed

opened 2021-07-22 17:05:12 +00:00 by ams_tschoening · 2 comments

ams_tschoening commented 2021-07-22 17:05:12 +00:00

Copy Link

What I'm trying to do and why

I'm in the process of setting up various backups using BorgMatic in a setup where there's one server hosting BorgMatic and fetching contents using SSHFS from remote systems. Additionally I'm testing backing up Postgres file based by issuing pg_start_backup and pg_stop_backup. All of my use cases have in common that there's some state handling necessary: E.g. before a backup some snapshots need to be taken using BTRFS/ZFS, some dirs need to be mounted, pg_start_backup called etc. A corresponding hook after_backup or on_error are available already to clean things up properly.

Though, from my understanding those only fire in case everything works and finishes as expected. But during my setup I need to test a lot of things and am simply aborting backups soon after they have started to test further. Waiting for the backup to finish would simply take too long and is wasted time. The problem seems to be that when I simply kill the process using STRG+C, neither after_backup nor on_error fire, so things are not cleaned up.

I try to take that into account when executing the backup again by e.g. first unmounting probably already mounted dirs, deleting prbably already available snapshots etc. But that makes the before_backup-hook more complex than necessary in theory and requires to start a new backup. Without that a snapshots might be kept around far longer as necessary or Postgres would stay in backup mode.

Having CTRL+C catched and mapped to some hook like on_abort|exit|kill|... or alike would allow me to run the same cleanup like after_backup or on_error in theory.

Thanks for considering!

Environment

borgmatic version: 1.5.15
borgmatic installation method: PIP, system wide
Borg version: 1.1.16
Python version: 3.8.10
operating system and version: Ubuntu 20.04

#### What I'm trying to do and why I'm in the process of setting up various backups using BorgMatic in a setup where there's one server hosting BorgMatic and fetching contents using SSHFS from remote systems. Additionally I'm testing backing up Postgres file based by issuing `pg_start_backup` and `pg_stop_backup`. All of my use cases have in common that there's some state handling necessary: E.g. before a backup some snapshots need to be taken using BTRFS/ZFS, some dirs need to be mounted, `pg_start_backup` called etc. A corresponding hook `after_backup` or `on_error` are available already to clean things up properly. Though, from my understanding those only fire in case everything works and finishes as expected. But during my setup I need to test a lot of things and am simply aborting backups soon after they have started to test further. Waiting for the backup to finish would simply take too long and is wasted time. The problem seems to be that when I simply kill the process using STRG+C, neither `after_backup` nor `on_error` fire, so things are not cleaned up. I try to take that into account when executing the backup again by e.g. first unmounting probably already mounted dirs, deleting prbably already available snapshots etc. But that makes the `before_backup`-hook more complex than necessary in theory and requires to start a new backup. Without that a snapshots might be kept around far longer as necessary or Postgres would stay in backup mode. Having CTRL+C catched and mapped to some hook like `on_abort|exit|kill|...` or alike would allow me to run the same cleanup like `after_backup` or `on_error` in theory. **Thanks for considering!** #### Environment **borgmatic version:** 1.5.15 **borgmatic installation method:** PIP, system wide **Borg version:** 1.1.16 **Python version:** 3.8.10 **operating system and version:** Ubuntu 20.04

witten commented 2023-03-27 19:10:06 +00:00

Owner

Copy Link

What about simply firing on_error when ctrl-C is pressed? Would that work for you use case? Or do you really need a separate hook with different logic?

What about simply firing `on_error` when ctrl-C is pressed? Would that work for you use case? Or do you really need a separate hook with different logic?

witten added the

good first issue

label 2023-03-27 19:10:14 +00:00

witten commented 2023-06-28 18:44:17 +00:00

Owner

Copy Link

I'm closing this one for now due to inactivity, but I'd be happy to open it up again if you have further thoughts. Thank you!

I'm closing this one for now due to inactivity, but I'd be happy to open it up again if you have further thoughts. Thank you!

witten closed this issue 2023-06-28 18:44:17 +00:00

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

spot-check

1.8.10

1.8.9

1.8.8

1.8.7

1.8.6

1.8.5

1.8.4

1.8.3

1.8.2

1.8.1

1.8.0

1.7.15

1.7.14

1.7.13

1.7.12

1.7.11

1.7.10

1.7.9

1.7.8

1.7.7

1.7.6

1.7.5

1.7.4

1.7.3

1.7.2

1.7.1

1.7.0

1.6.6

1.6.5

1.6.4

1.6.3

1.6.2

1.6.1

1.6.0

1.5.24

1.5.23

1.5.22

1.5.21

1.5.20

1.5.19

1.5.18

1.5.17

1.5.16

1.5.15

1.5.14

1.5.13

1.5.12

1.5.11

1.5.10

1.5.9

1.5.8

1.5.7

1.5.7.dev0

1.5.6

1.5.5

1.5.4

1.5.3

1.5.2

1.5.1

1.5.0

1.4.22

1.4.21

1.4.20

1.4.19

1.4.18

1.4.17

1.4.16

1.4.15

1.4.14

1.4.13

1.4.12

1.4.11

1.4.10

1.4.9

1.4.8

1.4.7

1.4.6

1.4.5

1.4.4

1.4.3

1.4.2

1.4.1

1.4.0

1.3.26

1.3.25

1.3.24

1.3.23

1.3.22

1.3.21

1.3.20

1.3.19

1.3.18

1.3.17

1.3.16

1.3.15

1.3.14

1.3.13

1.3.12

1.3.11

1.3.10

1.3.9

1.3.8

1.3.7

1.3.6

1.3.5

1.3.4

1.3.3

1.3.2

1.3.1

1.3.0

1.2.18

1.2.17

1.2.16

1.2.15

1.2.14

1.2.13

1.2.12

1.2.11

1.2.10

1.2.9

1.2.8

1.2.7

1.2.6

1.2.5

1.2.4

1.2.3

1.2.2

1.2.1

1.2.0

1.1.15

1.1.14

1.1.13

1.1.12

1.1.11

1.1.10

1.1.9

1.1.7

1.1.6

1.1.5

1.1.4

1.1.3

1.1.2

1.1.1

1.1.0

1.0.3

1.0.2

1.0.1

1.0.0

0.1.8

0.1.7

0.1.6

0.1.5

0.1.4

0.1.3

0.1.2

0.1.1

0.1.0

0.0.7

0.0.6

0.0.5

0.0.4

0.0.3

0.0.2

Labels

Clear labels   

bug

  

data loss

  

design finalized

  

good first issue

  

new feature area

  

question / support

  

security

  

waiting for response

No Label

bug

data loss

design finalized

good first issue

new feature area

question / support

security

waiting for response

Milestone

Clear milestone

No items

No Milestone

Assignees

Clear assignees

No Assignees

2 Participants

Notifications

Subscribe

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#434

No description provided.