"borg info --critical" makes troubleshooting difficult #1331

Closed
opened 2026-06-29 22:47:49 +00:00 by zewt · 5 comments

What I'd like to do and why

Currently, running borgmatic create runs "borg info" at --critical, which hides almost all output. In my case I was seeing this:

> borgmatic repo-create
borgbase: Error running actions for repository
borgbase: Command '/home/backup/backups/borg info --critical --log-json --json ssh://...repo/./repo' returned non-zero exit status 26.
/home/backup/.config/borgmatic/config.yaml: Error running configuration
/home/backup/.config/borgmatic/config.yaml: An error occurred

summary:
An error occurred
Error running actions for repository
Command '/home/backup/backups/borg info --critical --log-json --json ssh://...' returned non-zero exit status 26. 
Error running configuration

It's really determined that there's an error, but it just says "an error occurred" about seven times :)

The underlying issue showed up when I manually ran borg info with --warning:

{"type": "log_message", "time": 1782772019.4105656, "message": "Got unexpected RPC data format from server:\nThis service allows sftp connections only.\n", "levelname": "ERROR", "name": "borg.archiver", "msgid": "UnexpectedRPCDataFormatFromServer"}

which told me that borgbase apparently completely disables borg when sftp is enabled, but it took a while to figure that out. Having at least warnings make it to the output would make early failures like this a lot more obvious.

That's with borg 1.4.4. I guess another argument would be that this error should just be critical, but this is just a network error to borg and not data corruption, so "warning" probably makes sense.

Other notes / implementation ideas

No response

### What I'd like to do and why Currently, running borgmatic create runs "borg info" at --critical, which hides almost all output. In my case I was seeing this: ``` > borgmatic repo-create borgbase: Error running actions for repository borgbase: Command '/home/backup/backups/borg info --critical --log-json --json ssh://...repo/./repo' returned non-zero exit status 26. /home/backup/.config/borgmatic/config.yaml: Error running configuration /home/backup/.config/borgmatic/config.yaml: An error occurred summary: An error occurred Error running actions for repository Command '/home/backup/backups/borg info --critical --log-json --json ssh://...' returned non-zero exit status 26. Error running configuration ``` It's really determined that there's an error, but it just says "an error occurred" about seven times :) The underlying issue showed up when I manually ran borg info with --warning: ``` {"type": "log_message", "time": 1782772019.4105656, "message": "Got unexpected RPC data format from server:\nThis service allows sftp connections only.\n", "levelname": "ERROR", "name": "borg.archiver", "msgid": "UnexpectedRPCDataFormatFromServer"} ``` which told me that borgbase apparently completely disables borg when sftp is enabled, but it took a while to figure that out. Having at least warnings make it to the output would make early failures like this a lot more obvious. That's with borg 1.4.4. I guess another argument would be that this error should just be critical, but this is just a network error to borg and not data corruption, so "warning" probably makes sense. ### Other notes / implementation ideas _No response_
Owner

Thanks for filing this. So here's why that --critical flag is there: When Borg is allowed to log non-critical errors for borg info --json commands, then the "repo doesn't exist" case is considered an error and Borg creates an error log to that effect—which makes its way to the user, resulting in a confusing log message when borgmatic is simply probing for whether the repo exists before doing a repo-create.

So maybe borgmatic could omit --critical and then get more surgical about dealing with this case. With sufficiently recent versions of Borg (1.4+ IIRC), this "repo doesn't exist" case yields a specific exit code of 13. Perhaps borgmatic could look for that exit code and, if present, suppress error logs? Or even suppress the Repository [...] does not exist. message in particular so other errors still flow through to the user? Not sure how feasible that is.

I'm open to other ideas as well.

Thanks for filing this. So here's why that `--critical` flag is there: When Borg is allowed to log non-critical errors for `borg info --json` commands, then the "repo doesn't exist" case is considered an error and Borg creates an error log to that effect—which makes its way to the user, resulting in a confusing log message when borgmatic is simply probing for whether the repo exists before doing a `repo-create`. So maybe borgmatic could omit `--critical` and then get more surgical about dealing with this case. With sufficiently recent versions of Borg (1.4+ IIRC), this "repo doesn't exist" case yields a specific exit code of 13. Perhaps borgmatic could look for that exit code and, if present, suppress error logs? Or even suppress the `Repository [...] does not exist.` message in particular so other errors still flow through to the user? Not sure how feasible that is. I'm open to other ideas as well.
Author

Looks like there's a message ID for programmatic matching, so it could just hide Repository.DoesNotExist:

{"type": "log_message", "time": 1234, "message": "Repository foo does not exist.", "levelname": "ERROR", "name": "borg.archiver", "msgid": "Repository.DoesNotExist"}

Looks like there's a message ID for programmatic matching, so it could just hide Repository.DoesNotExist: {"type": "log_message", "time": 1234, "message": "Repository foo does not exist.", "levelname": "ERROR", "name": "borg.archiver", "msgid": "Repository.DoesNotExist"}
Owner

Good idea! I have a prototype now that suppresses logs just based on that ID, and only for repo-create. (We still want the error showing for plain borgmatic info.)

Good idea! I have a prototype now that suppresses logs just based on that ID, and only for `repo-create`. (We still want the error showing for plain `borgmatic info`.)
Owner

This is now fixed in main and will be part of the next release! Thanks again for the ticket.

This is now fixed in main and will be part of the next release! Thanks again for the ticket.
Owner

Released in borgmatic 2.1.7!

Released in borgmatic 2.1.7!
Sign in to join this conversation.
No milestone
No assignees
2 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#1331
No description provided.