"borg info --critical" makes troubleshooting difficult #1331
Labels
No labels
blocked
breaking
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#1331
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
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'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:
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:
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
Thanks for filing this. So here's why that
--criticalflag is there: When Borg is allowed to log non-critical errors forborg info --jsoncommands, 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 arepo-create.So maybe borgmatic could omit
--criticaland 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 theRepository [...] 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.
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"}
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 plainborgmatic info.)This is now fixed in main and will be part of the next release! Thanks again for the ticket.
Released in borgmatic 2.1.7!