Running btrbk with -q produces "At subvol..." output about btrbk HOT 6 CLOSED

Re ran btrbk with these settings:

sudo /usr/sbin/btrbk -q -v -l info -c /etc/btrbk/btrbk-#####.conf run 

This is the first part of the output:

btrbk command line client, version 0.19.3  (Thu Jul  9 11:04:04 2015)
Using configuration: /etc/btrbk/btrbk-#######.conf
Creating subvolume snapshot for: /mnt/btr_system/@
>>> /mnt/btr_system/btrbk_snapshots/@.20150709_4
Creating subvolume snapshot for: /mnt/btr_system/@home
>>> /mnt/btr_system/btrbk_snapshots/@home.20150709_4
Creating subvolume snapshot for: /mnt/btr_system/@vms
>>> /mnt/btr_system/btrbk_snapshots/@vms.20150709_4
Checking for missing backups of subvolume "/mnt/btr_system/@" in: {#######}/mnt/btrfs/btrbk/#####/
No missing backups found
Creating subvolume backup (send-receive) for: /mnt/btr_system/@
Receiving from snapshot: /mnt/btr_system/btrbk_snapshots/@.20150709_4
Incremental from parent snapshot: /mnt/btr_system/btrbk_snapshots/@.20150709_3
>>> {#######}/mnt/btrfs/btrbk/#####/@.20150709_4
At subvol /mnt/btr_system/btrbk_snapshots/@.20150709_4

It seems to be occurring after sending an incremental snapshot to my server.

from btrbk.

Even with the latest btrfs-progs, you will still see the At subvol ... messages. These are generated by btrfs send on stderr, which btrbk does not catch and process. This is an issue and I won't fix this on btrbk, since we want to see the real errors on stderr if something fails. I will try to provide patches to btrfs-progs for disabling this, but for now we all have to live with it...

The -q option only disables the summary display at the end of processing, and does not affect stderr output (btrbk messages as well as output from btrfs commands).

from btrbk.

I fixed this logging problem by catching and filtering stderr from external commands (btrfs-progs). It's on the "open3" branch, and I will merge this to master as soon as I performed some more testing on several error cases.

I would apreciate if you (and also my GitHub followers reading this) could give it a try, I'm especially interested on how this behaves on old Perl versions (I'm using perl-5.20.2, which comes with IPC::Open3 v1.16 included on my system).

from btrbk.

Will do

from btrbk.

After digging deeper into the perl and file descriptor hell, I rewrote the stderr catching code, which is now in the "run_cmd_open3" branch (the old "open3" branch got deleted).
I did much testing, and it still produces deadlocks in some special test cases. I could not observe deadlocks with normal btrbk calls though, but as long as I'm not convinced that everything is correct I will not merge this.

from btrbk.

fixed in btrbk-0.21.0

from btrbk.