"NoneType" exception when creating archive under FreeBSD #355

New Issue

AriosThePhoenix · 2020-08-24T19:23:01Z

AriosThePhoenix commented

2020-08-24 19:23:01 +00:00

Quick preface: I'm not sure if FreeBSD is officially supported by borgmatic. If it isn't then an admin can close this issue.

What I'm trying to do and why

I'm attempting to create a backup to a local repository on a FreeBSD host. While repository initialization works, attempting to run borgmatic create results in a NoneType Error traceback, with the application exiting immediately. Creating backups with plain borg works fine, which leads me to believe that this is an issue with borgmatic.

Steps to reproduce (if a bug)

Create a FreeBSD host (tested with both the FreeBSD 11.4 image for Vagrant and a 11.4 Jail on a FreeNAS box). I've included my Vagrantfile below.
Install borgmatic via pkg (sudo pkg install -y py37-borgbackup py37-borgmatic) or pip (sudo pip install --user --upgrade borgmatic)
Create a config (see below) and initialize a repository (borgmatic init --encryption repokey)
Attempt to create a backup borgmatic create

Actual behavior (if a bug)

The task fails almost immediately with the following output:

root@freebsd11:~/borg-client # ~/.local/bin/borgmatic -c config.yml create --verbosity 2
Ensuring legacy configuration is upgraded
config.yml: No commands to run for pre-everything hook
config.yml: No commands to run for pre-backup hook
/var/test-repository: Creating archive
/var/test-repository: No postgresql_databases hook configured.
/var/test-repository: No mysql_databases hook configured.
/var/test-repository: No postgresql_databases hook configured.
/var/test-repository: No mysql_databases hook configured.
Traceback (most recent call last):
  File "/root/.local/bin/borgmatic", line 10, in <module>
    sys.exit(main())
  File "/root/.local/lib/python3.7/site-packages/borgmatic/commands/borgmatic.py", line 785, in main
    summary_logs = parse_logs + list(collect_configuration_run_summary_logs(configs, arguments))
  File "/root/.local/lib/python3.7/site-packages/borgmatic/commands/borgmatic.py", line 683, in collect_configuration_run_summary_logs
    results = list(run_configuration(config_filename, config, arguments))
  File "/root/.local/lib/python3.7/site-packages/borgmatic/commands/borgmatic.py", line 133, in run_configuration
    repository_path=repository_path,
  File "/root/.local/lib/python3.7/site-packages/borgmatic/commands/borgmatic.py", line 315, in run_actions
    stream_processes = [process for processes in active_dumps.values() for process in processes]
  File "/root/.local/lib/python3.7/site-packages/borgmatic/commands/borgmatic.py", line 315, in <listcomp>
    stream_processes = [process for processes in active_dumps.values() for process in processes]
TypeError: 'NoneType' object is not iterable

No archive is created.

Expected behavior (if a bug)

borgmatic runs and creates the archive.

Other notes / implementation ideas

Manually creating the archive with borg by calling sudo borg create /var/test-repository::archive1 /etc works as expected

Environment

borgmatic version: Tested with 1.5.9 and 1.5.10

borgmatic installation method: pkg package and pip installation

Borg version: 1.1.13

Python version: 3.7.8

operating system and version: FreeBSD 11.4

Additonal files

Configuration file:

consistency: {}
hooks:
    mysql_databases: null
    postgresql_databases: null
location:
    repositories:
    - /var/test-repository
    source_directories:
    - /etc
retention:
    keep_daily: 7
    keep_monthly: 6
    keep_weekly: 4
storage:
    encryption_passcommand: null
    encryption_passphrase: test-repository
    relocated_repo_access_is_ok: true
    ssh_command: ssh -i /root/borg-client/id_rsa

(I use ansible to template out the config file, hence the ugly YAML. I also tested a "cleaner" version without the null values and the result was the same)

borgmatic info output for the repo:

root@freebsd11:~/borg-client # ~/.local/bin/borgmatic -c config.yml info
/var/test-repository: Displaying summary info for archives
Repository ID: b48b0a562c217862b87fb85e7ea99ce631ba07911b4b4d55a8e5439ab131f673
Location: /var/test-repository
Encrypted: Yes (repokey)
Cache: /root/.cache/borg/b48b0a562c217862b87fb85e7ea99ce631ba07911b4b4d55a8e5439ab131f673
Security dir: /root/.config/borg/security/b48b0a562c217862b87fb85e7ea99ce631ba07911b4b4d55a8e5439ab131f673
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
All archives:                2.16 MB            721.83 kB            676.22 kB
                       Unique chunks         Total chunks
Chunk index:                     385                  387

(The repo contains a single archive that i created manually with borg. borgmatic fails whether this archive exists or not)

Vagrantfile for the FreeBSD VM:

Vagrant.require_version ">= 1.8.0"

Vagrant.configure(2) do |config|

  config.vm.define "freebsd_11" do |freebsd_11|
    freebsd_11.vm.box = "freebsd/FreeBSD-11.4-STABLE"
    # Custom parameters for a FreeBSD guest using the official box
    freebsd_11.vm.guest = :freebsd
    freebsd_11.vm.hostname = "freebsd11"
    freebsd_11.vm.base_mac = "080027D14C66"
    freebsd_11.ssh.shell = "sh"
    
    # Additional parameters for VirtualBox, needed to make FreeBSD work
    freebsd_11.vm.provider :virtualbox do |vb|
      vb.customize ["modifyvm", :id, "--memory", "1024"]
      vb.customize ["modifyvm", :id, "--cpus", "1"]
      vb.customize ["modifyvm", :id, "--hwvirtex", "on"]
      vb.customize ["modifyvm", :id, "--audio", "none"]
      vb.customize ["modifyvm", :id, "--nictype1", "virtio"]
      vb.customize ["modifyvm", :id, "--nictype2", "virtio"]
    end
  end
end

I'm be more than happy to supply additional information or logs if needed. Running borgmatic on FreeBSD would allow me to use one backup solution throughout my entire network, including for backing up FreeNAS hosts from within jails.

Quick preface: I'm not sure if FreeBSD is officially supported by borgmatic. If it isn't then an admin can close this issue. #### What I'm trying to do and why I'm attempting to create a backup to a local repository on a FreeBSD host. While repository initialization works, attempting to run `borgmatic create` results in a NoneType Error traceback, with the application exiting immediately. Creating backups with plain borg works fine, which leads me to believe that this is an issue with borgmatic. #### Steps to reproduce (if a bug) 1. Create a FreeBSD host (tested with both the [FreeBSD 11.4 image for Vagrant](https://app.vagrantup.com/freebsd/boxes/FreeBSD-11.4-STABLE) and a 11.4 Jail on a FreeNAS box). I've included my Vagrantfile below. 2. Install borgmatic via pkg (`sudo pkg install -y py37-borgbackup py37-borgmatic`) or pip (`sudo pip install --user --upgrade borgmatic`) 3. Create a config (see below) and initialize a repository (`borgmatic init --encryption repokey`) 4. Attempt to create a backup `borgmatic create` #### Actual behavior (if a bug) The task fails almost immediately with the following output: ``` root@freebsd11:~/borg-client # ~/.local/bin/borgmatic -c config.yml create --verbosity 2 Ensuring legacy configuration is upgraded config.yml: No commands to run for pre-everything hook config.yml: No commands to run for pre-backup hook /var/test-repository: Creating archive /var/test-repository: No postgresql_databases hook configured. /var/test-repository: No mysql_databases hook configured. /var/test-repository: No postgresql_databases hook configured. /var/test-repository: No mysql_databases hook configured. Traceback (most recent call last): File "/root/.local/bin/borgmatic", line 10, in <module> sys.exit(main()) File "/root/.local/lib/python3.7/site-packages/borgmatic/commands/borgmatic.py", line 785, in main summary_logs = parse_logs + list(collect_configuration_run_summary_logs(configs, arguments)) File "/root/.local/lib/python3.7/site-packages/borgmatic/commands/borgmatic.py", line 683, in collect_configuration_run_summary_logs results = list(run_configuration(config_filename, config, arguments)) File "/root/.local/lib/python3.7/site-packages/borgmatic/commands/borgmatic.py", line 133, in run_configuration repository_path=repository_path, File "/root/.local/lib/python3.7/site-packages/borgmatic/commands/borgmatic.py", line 315, in run_actions stream_processes = [process for processes in active_dumps.values() for process in processes] File "/root/.local/lib/python3.7/site-packages/borgmatic/commands/borgmatic.py", line 315, in <listcomp> stream_processes = [process for processes in active_dumps.values() for process in processes] TypeError: 'NoneType' object is not iterable ``` No archive is created. #### Expected behavior (if a bug) borgmatic runs and creates the archive. #### Other notes / implementation ideas Manually creating the archive with borg by calling `sudo borg create /var/test-repository::archive1 /etc` works as expected #### Environment **borgmatic version:** Tested with 1.5.9 and 1.5.10 **borgmatic installation method:** pkg package and pip installation **Borg version:** 1.1.13 **Python version:** 3.7.8 **operating system and version:** FreeBSD 11.4 #### Additonal files **Configuration file:** ``` consistency: {} hooks: mysql_databases: null postgresql_databases: null location: repositories: - /var/test-repository source_directories: - /etc retention: keep_daily: 7 keep_monthly: 6 keep_weekly: 4 storage: encryption_passcommand: null encryption_passphrase: test-repository relocated_repo_access_is_ok: true ssh_command: ssh -i /root/borg-client/id_rsa ``` (I use ansible to template out the config file, hence the ugly YAML. I also tested a "cleaner" version without the null values and the result was the same) **borgmatic info output for the repo:** ``` root@freebsd11:~/borg-client # ~/.local/bin/borgmatic -c config.yml info /var/test-repository: Displaying summary info for archives Repository ID: b48b0a562c217862b87fb85e7ea99ce631ba07911b4b4d55a8e5439ab131f673 Location: /var/test-repository Encrypted: Yes (repokey) Cache: /root/.cache/borg/b48b0a562c217862b87fb85e7ea99ce631ba07911b4b4d55a8e5439ab131f673 Security dir: /root/.config/borg/security/b48b0a562c217862b87fb85e7ea99ce631ba07911b4b4d55a8e5439ab131f673 ------------------------------------------------------------------------------ Original size Compressed size Deduplicated size All archives: 2.16 MB 721.83 kB 676.22 kB Unique chunks Total chunks Chunk index: 385 387 ``` (The repo contains a single archive that i created manually with `borg`. borgmatic fails whether this archive exists or not) **Vagrantfile for the FreeBSD VM:** ``` Vagrant.require_version ">= 1.8.0" Vagrant.configure(2) do |config| config.vm.define "freebsd_11" do |freebsd_11| freebsd_11.vm.box = "freebsd/FreeBSD-11.4-STABLE" # Custom parameters for a FreeBSD guest using the official box freebsd_11.vm.guest = :freebsd freebsd_11.vm.hostname = "freebsd11" freebsd_11.vm.base_mac = "080027D14C66" freebsd_11.ssh.shell = "sh" # Additional parameters for VirtualBox, needed to make FreeBSD work freebsd_11.vm.provider :virtualbox do |vb| vb.customize ["modifyvm", :id, "--memory", "1024"] vb.customize ["modifyvm", :id, "--cpus", "1"] vb.customize ["modifyvm", :id, "--hwvirtex", "on"] vb.customize ["modifyvm", :id, "--audio", "none"] vb.customize ["modifyvm", :id, "--nictype1", "virtio"] vb.customize ["modifyvm", :id, "--nictype2", "virtio"] end end end ``` I'm be more than happy to supply additional information or logs if needed. Running borgmatic on FreeBSD would allow me to use one backup solution throughout my entire network, including for backing up FreeNAS hosts from within jails.

witten commented

2020-08-24 20:45:37 +00:00

First of all, thank you for supplying all the excellent detail with this ticket! It certainly helps.

Quick preface: I’m not sure if FreeBSD is officially supported by borgmatic. If it isn’t then an admin can close this issue.

I don't use FreeBSD myself, so it's probably fair to say FreeBSD is "less supported" than, say, Linux. But borgmatic is "just Python", so I'm also happy to try to make it work on FreeBSD insofar as I can.

Also, FWIW, I got an exact repro on Linux when using your configuration! So this issue doesn't appear to be FreeBSD-specific.

But when I comment out the entire hooks section (which is composed entirely of null values in your example), borgmatic create works just fine. No errors.

(I use ansible to template out the config file, hence the ugly YAML. I also tested a “cleaner” version without the null values and the result was the same)

What does that "cleaner" version look like? Have you tried commenting out the hooks section entirely?

Even if this issue is "caused" by the null values, I'm still marking this as a bug because borgmatic should never give a traceback based on an invalid configuration file.

First of all, thank you for supplying all the excellent detail with this ticket! It certainly helps. > Quick preface: I’m not sure if FreeBSD is officially supported by borgmatic. If it isn’t then an admin can close this issue. I don't use FreeBSD myself, so it's probably fair to say FreeBSD is "less supported" than, say, Linux. But borgmatic is "just Python", so I'm also happy to try to make it work on FreeBSD insofar as I can. Also, FWIW, I got an exact repro on Linux when using your configuration! So this issue doesn't appear to be FreeBSD-specific. But when I comment out the entire `hooks` section (which is composed entirely of `null` values in your example), `borgmatic create` works just fine. No errors. > (I use ansible to template out the config file, hence the ugly YAML. I also tested a “cleaner” version without the null values and the result was the same) What does that "cleaner" version look like? Have you tried commenting out the `hooks` section entirely? Even if this issue is "caused" by the `null` values, I'm still marking this as a bug because borgmatic should never give a traceback based on an invalid configuration file.

witten added the

bug

label 2020-08-24 20:45:48 +00:00

AriosThePhoenix commented

2020-08-24 21:05:18 +00:00

Thanks for the quick reply! I just tried commenting out the entire hooks section myself, and indeed, the backup runs just fine. Seems like the empty mysql/psql_databases keys are confusing borgmatic in some way?

The "cleaner" version just had the "null" values removed, but I did not comment out the keys. Probably should have played around with that a little more before opening this issue, hah.

There is some more weirdness here though - the original config does work fine on some systems for me, notably a Ubuntu 20.04 Vagrant VM. That's why I assumed that my config was fine, as I would have expected an error/quirk in the config to affect all systems:

root@ubuntu-focal:~/borg-client# cat config.yml 
consistency: {}
hooks:
    mysql_databases: null
    postgresql_databases: null
location:
    repositories:
    - /var/test-repository
    source_directories:
    - /etc
retention:
    keep_daily: 7
    keep_monthly: 6
    keep_weekly: 4
storage:
    encryption_passcommand: null
    encryption_passphrase: test-repository
    relocated_repo_access_is_ok: true
    ssh_command: ssh -i /root/borg-client/id_rsa
root@ubuntu-focal:~/borg-client# borgmatic -c config.yml 
root@ubuntu-focal:~/borg-client# echo $?
0

Software versions for the Ubuntu VM:
- borgmatic: 1.5.1
- borg: 1.11.1
- Python: 3.8.2

I guess my original issue can be considered resolved - but I agree that a config error probably shouldn't result in a traceback. And it's weird that it still works on some systems - I guess that could be caused by a different borgmatic or library version?

Thanks for the quick reply! I just tried commenting out the entire hooks section myself, and indeed, the backup runs just fine. Seems like the empty mysql/psql_databases keys are confusing borgmatic in some way? The "cleaner" version just had the "null" values removed, but I did not comment out the keys. Probably should have played around with that a little more before opening this issue, hah. There is some more weirdness here though - the original config *does* work fine on some systems for me, notably a Ubuntu 20.04 Vagrant VM. That's why I assumed that my config was fine, as I would have expected an error/quirk in the config to affect all systems: ``` root@ubuntu-focal:~/borg-client# cat config.yml consistency: {} hooks: mysql_databases: null postgresql_databases: null location: repositories: - /var/test-repository source_directories: - /etc retention: keep_daily: 7 keep_monthly: 6 keep_weekly: 4 storage: encryption_passcommand: null encryption_passphrase: test-repository relocated_repo_access_is_ok: true ssh_command: ssh -i /root/borg-client/id_rsa root@ubuntu-focal:~/borg-client# borgmatic -c config.yml root@ubuntu-focal:~/borg-client# echo $? 0 ``` Software versions for the Ubuntu VM: - borgmatic: 1.5.1 - borg: 1.11.1 - Python: 3.8.2 I guess my original issue can be considered resolved - but I agree that a config error probably shouldn't result in a traceback. And it's weird that it still works on some systems - I guess that could be caused by a different borgmatic or library version?

witten commented

2020-08-25 01:38:56 +00:00

Thanks for the quick reply! I just tried commenting out the entire hooks section myself, and indeed, the backup runs just fine. Seems like the empty mysql/psql_databases keys are confusing borgmatic in some way?

Yup, and that's the bug that needs fixing IMO.

The “cleaner” version just had the “null” values removed, but I did not comment out the keys. Probably should have played around with that a little more before opening this issue, hah.

No worries! I'm glad there is a work-around for you with the current version.

There is some more weirdness here though - the original config does work fine on some systems for me, notably a Ubuntu 20.04 Vagrant VM. That’s why I assumed that my config was fine, as I would have expected an error/quirk in the config to affect all systems: ...

I guess my original issue can be considered resolved - but I agree that a config error probably shouldn’t result in a traceback. And it’s weird that it still works on some systems - I guess that could be caused by a different borgmatic or library version?

Just by looking at changelogs, I'm 90% sure the traceback/regression was introduced in borgmatic 1.5.3. That's when database dumps were changed to be streaming rather than temporary files on disk. Given that you're using borgmatic 1.5.1 on the Linux systems and borgmatic 1.5.9+ on FreeBSD, that could explain the difference you're seeing.

> Thanks for the quick reply! I just tried commenting out the entire hooks section myself, and indeed, the backup runs just fine. Seems like the empty mysql/psql_databases keys are confusing borgmatic in some way? Yup, and that's the bug that needs fixing IMO. > The “cleaner” version just had the “null” values removed, but I did not comment out the keys. Probably should have played around with that a little more before opening this issue, hah. No worries! I'm glad there is a work-around for you with the current version. > There is some more weirdness here though - the original config does work fine on some systems for me, notably a Ubuntu 20.04 Vagrant VM. That’s why I assumed that my config was fine, as I would have expected an error/quirk in the config to affect all systems: ... > I guess my original issue can be considered resolved - but I agree that a config error probably shouldn’t result in a traceback. And it’s weird that it still works on some systems - I guess that could be caused by a different borgmatic or library version? Just by looking at changelogs, I'm 90% sure the traceback/regression was introduced in borgmatic 1.5.3. That's when database dumps were changed to be streaming rather than temporary files on disk. Given that you're using borgmatic 1.5.1 on the Linux systems and borgmatic 1.5.9+ on FreeBSD, that could explain the difference you're seeing.

👍 1

witten referenced this issue from a commit

2020-10-07 22:43:30 +00:00

Fix traceback when a database hook value is null in a configuration file (#355).

witten commented

2020-10-07 22:43:48 +00:00

Fixed in master!

👍 1

witten closed this issue

2020-10-07 22:43:48 +00:00

witten commented

2020-11-19 18:00:53 +00:00