borgmatic does not treat database dump command exit code 1 as error #310

New Issue

witten · 2020-05-14T22:27:51Z

witten commented

2020-05-14 22:27:51 +00:00

What I'm trying to do and why

Since #258 if a database dump command errors (e.g. pg_dump returns exit code 1), borgmatic no longer treats that as an error.

Steps to reproduce

Using any valid borgmatic configuration file at test.yaml:

borgmatic -c test.yaml create -v 2 --override "hooks.postgresql_databases=[{'name': 'test', 'username': 'notrealuser', 'password': 'pass'}]"

Actual behavior

pg_dump clearly errors in the logs:

pg_dump: error: connection to database "test" failed: could not connect to server: No such file or directory
	Is the server running locally and accepting
	connections on Unix domain socket "/run/postgresql/.s.PGSQL.5432"?

But borgmatic doesn't error:

summary:
test.yaml: Successfully ran configuration file

Expected behavior

borgmatic errors when pg_dump does.

Other notes / implementation ideas

The reason this is happening is because of the way that #258 is executing both dumps and Borg create within a single function now: execute_command_with_processes(). That function takes a single error_on_warnings parameter now, which is False in the create action call, which means that exit code 1 for both borg create and for pg_dump are considered non-error.

The fix is to somehow still consider pg_dump exit code 1 as an error. The error_on_warnings=False flag was originally introducing as a way for execute_command*() callers to effectively say: "This is Borg. Treat it special."

Environment

borgmatic version: 1.5.3

borgmatic installation method: pip install --user

Borg version: 1.1.11

Python version: 3.8.2

Database version (if applicable): 12.2

operating system and version: Manjaro 20.0

#### What I'm trying to do and why Since #258 if a database dump command errors (e.g. `pg_dump` returns exit code 1), borgmatic no longer treats that as an error. #### Steps to reproduce Using any valid borgmatic configuration file at `test.yaml`: ```bash borgmatic -c test.yaml create -v 2 --override "hooks.postgresql_databases=[{'name': 'test', 'username': 'notrealuser', 'password': 'pass'}]" ``` #### Actual behavior `pg_dump` clearly errors in the logs: ```bash pg_dump: error: connection to database "test" failed: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/run/postgresql/.s.PGSQL.5432"? ``` But borgmatic doesn't error: ```bash summary: test.yaml: Successfully ran configuration file ``` #### Expected behavior borgmatic errors when `pg_dump` does. #### Other notes / implementation ideas The reason this is happening is because of the way that #258 is executing both dumps and Borg create within a single function now: `execute_command_with_processes()`. That function takes a single `error_on_warnings` parameter now, which is False in the `create` action call, which means that exit code 1 for both `borg create` and for `pg_dump` are considered non-error. The fix is to somehow still consider `pg_dump` exit code 1 as an error. The `error_on_warnings=False` flag was originally introducing as a way for `execute_command*()` callers to effectively say: "This is Borg. Treat it special." #### Environment **borgmatic version:** 1.5.3 **borgmatic installation method:** `pip install --user` **Borg version:** `1.1.11` **Python version:** `3.8.2` **Database version (if applicable):** 12.2 **operating system and version:** Manjaro 20.0

witten added the

bug

label 2020-05-14 22:27:58 +00:00

witten commented

2020-05-14 22:55:27 +00:00

It possible that the database restore functionality has the opposite problem: Because the database restore command and the borg extract command are executed in the same borgmatic function, any borg extract warnings (exit code 1) are interpreted as errors. But they should really be considered warnings and not cause borgmatic to error.

It possible that the database restore functionality has the opposite problem: Because the database restore command and the `borg extract` command are executed in the same borgmatic function, any `borg extract` warnings (exit code 1) are interpreted as errors. But they should really be considered warnings and not cause borgmatic to error.

witten referenced this issue from a commit

2020-05-15 05:49:02 +00:00

Fix legitimate database dump command errors (exit code 1) not being treated as errors by borgmatic (#310).

witten commented

2020-05-15 17:17:31 +00:00

Fixed in 1.5.4.

witten closed this issue

2020-05-15 17:17:34 +00:00

Sign in to join this conversation.