Best way to run Borgmatic with caffeinate #338

Closed
opened 2020-07-01 06:40:27 +00:00 by Linux-cpp-lisp · 5 comments

What I'm trying to do and why

To prevent my Mac from sleeping while a long borgmatic operation is running, I run it with the caffeinate utility:

caffeinate -i borgmatic

I'd like to integrate this into my borgmatic configuration so that I can't forget to use caffeinate and have backups unexpectedly terminated.

before_everything/after_everything seems like the right way to go about this, but to do so, I'd need either:

  • A way for the before_everything command to access the PID of borgmatic to pass to caffeinate -w [PID], which waits for the given process to terminate and then stops caffeinate.
  • A way to pass state (the PID of caffeinate) from before_everything to after_everything in order to kill caffeinate in after_everything.

Another option would be doing just this:

before_everything:
  - caffeinate -i
after_everything:
  - killall caffeinate

While this should work for my case, it's not ideal: if a user is caffeinateing their computer for other reasons, a borgmatic run shouldn't interfere with that.

Another issue with any of these solutions is that they will only run if a create command is present since before_everything only runs under those circumstances. Ideally, a borgmatic prune ought to run under caffeinate too.

Other notes / implementation ideas

If there's an optimial method, it might be worth adding to the documentation.

Possibly add a "before_absolutely_everything" hook that is not specific to create commands? I'm sure a better name could be found.

Environment

macOS

#### What I'm trying to do and why To prevent my Mac from sleeping while a long `borgmatic` operation is running, I run it with the [`caffeinate` utility](https://ss64.com/osx/caffeinate.html): ``` caffeinate -i borgmatic ``` I'd like to integrate this into my `borgmatic` configuration so that I can't forget to use `caffeinate` and have backups unexpectedly terminated. `before_everything`/`after_everything` seems like the right way to go about this, but to do so, I'd need either: * A way for the `before_everything` command to access the PID of `borgmatic` to pass to `caffeinate -w [PID]`, which waits for the given process to terminate and then stops `caffeinate`. * A way to pass state (the PID of caffeinate) from `before_everything` to `after_everything` in order to kill `caffeinate` in `after_everything`. Another option would be doing just this: ``` before_everything: - caffeinate -i after_everything: - killall caffeinate ``` While this should work for my case, it's not ideal: if a user is `caffeinate`ing their computer for other reasons, a `borgmatic` run shouldn't interfere with that. Another issue with any of these solutions is that they will only run if a `create` command is present since `before_everything` only runs under those circumstances. Ideally, a `borgmatic prune` ought to run under `caffeinate` too. #### Other notes / implementation ideas If there's an optimial method, it might be worth adding to the documentation. Possibly add a "`before_absolutely_everything`" hook that is not specific to `create` commands? I'm sure a better name could be found. #### Environment macOS
Owner

Thank you for filing this! Interesting problem. The current way this is solved is in borgmatic's sample systemd configuration. The last line (systemd-inhibit specifically) takes out a lock that prevents shutdown.

Given that you're on macOS, I'm guessing that you're using launchd. If so, there might be a way to do something comparable and take out a lock to prevent shutdown. Or are you only running borgmatic manually on the command-line?

In any case, if caffeinate is the right solution, I'll have to think through the hooks as you described.

Thank you for filing this! Interesting problem. The current way this is solved is in borgmatic's [sample systemd configuration](https://projects.torsion.org/witten/borgmatic/raw/branch/master/sample/systemd/borgmatic.service). The last line (`systemd-inhibit` specifically) takes out a lock that prevents shutdown. Given that you're on macOS, I'm guessing that you're using [launchd](https://en.wikipedia.org/wiki/Launchd). If so, there might be a way to do something comparable and take out a lock to prevent shutdown. Or are you only running borgmatic manually on the command-line? In any case, if `caffeinate` is the right solution, I'll have to think through the hooks as you described.
Author

The great thing about borgmatic is that these are the only sorts of small issues I've been facing, so thank you.

While I assume that you're right and there is some way to prevent sleep through launchd, I'm not seeing anything in the man page for launchd.plist files. But more importantly, I'm running borgmatic manually in this case, so I would prefer to not be depdendent on a scheduled launchd job.

The great thing about `borgmatic` is that these are the only sorts of small issues I've been facing, so thank *you*. While I assume that you're right and there is some way to prevent sleep through `launchd`, I'm not seeing anything in the [man page](https://www.unix.com/man-page/mojave/5/launchd.plist/) for `launchd.plist` files. But more importantly, I'm running `borgmatic` manually in this case, so I would prefer to not be depdendent on a scheduled `launchd` job.

Late for the party… but maybe it helps someone:

If you can tolerate an icon in taskbar/menubar, have a look at amphetamine (Mac) or caffeinate-ng (Linux).

Late for the party… but maybe it helps someone: If you can tolerate an icon in taskbar/menubar, have a look at *amphetamine* (Mac) or *caffeinate-ng* (Linux).
Owner

Well, it's been a while.. But here's an idea. Once borgmatic is already executing, it can't really run itself with a different program wrapping it. (I suppose it could try to re-run itself, but that sounds kind of fragile.) So how about borgmatic running Borg with caffeinate or whatever other program you want to wrap it with?

The obvious way to do that would be to specify a Borg local path in borgmatic's existing configuration file like:

location:
   local_path: caffeinate borg

Unfortunately this won't work as-is today, because borgmatic would look for an executable called caffeinate borg and try (and fail) to run that. But it would be a pretty simple change to make borgmatic realize that the executable to run is only caffeinate and borg is just a parameter to it.

Does something like that sound like it would work for you? Assuming this is still a need.

Well, it's been a while.. But here's an idea. Once borgmatic is already executing, it can't really run itself with a different program wrapping it. (I suppose it could try to re-run itself, but that sounds kind of fragile.) So how about borgmatic running *Borg* with caffeinate or whatever other program you want to wrap it with? The obvious way to do that would be to specify a Borg local path in borgmatic's existing configuration file like: ```yaml location: local_path: caffeinate borg ``` Unfortunately this won't work as-is today, because borgmatic would look for an executable called `caffeinate borg` and try (and fail) to run that. But it would be a pretty simple change to make borgmatic realize that the executable to run is only `caffeinate` and `borg` is just a parameter to it. Does something like that sound like it would work for you? Assuming this is still a need.
Owner

I'm closing this ticket due to inactivity, but if this is still a need for anyone, please chime in and I'd be happy to reopen it.

I'm closing this ticket due to inactivity, but if this is still a need for anyone, please chime in and I'd be happy to reopen it.
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
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#338
No description provided.