Holger Amann

Should be fixed in hamann/gdash@7441c0564572f681f8145232644b4283b642fd39 @Corni does that work for you?

@kamilc Is there a reason to have different results? Writing code with tests and matching against result isn't possible because of this

The lxc guys created a [ruby binding](https://github.com/lxc/ruby-lxc) for lxc, and it works. Don't know if it makes sense to investigate more work on this issue.

Yes, disabling exception based on command return codes would resolve it. Thanks!

What's about raising an exception when stderr isn't empty?

[mixlib-shellout](https://github.com/opscode/mixlib-shellout) e.g. has a method 'error!' which does exactly that, raise an exception when stderr isn't empty, but that has to be called explicitly, bound to the command called before....

I get the same result `bad status` for a websocket check  ``` - alerts: - type: slack conditions: - '[CONNECTED] == true' interval: 60s...

The SSH check tests if the barman user is allowed to ssh into postgres instance. That's different to postgres connection. Could you try to run `ssh barman@dev-gb-gal-pg11-01` as barman user?

Yes, you're right!. Some time has passed since I last setup a backup server. If your ssh_command in the barman.conf looks something like this ```txt ssh_command = ssh [email protected] ```...

I see! There's no line anymore like `ssh: OK` which is parsed here https://github.com/sauspiel/rbarman/blob/89723b5e051bafb1c30848e4f431b9d058871e3f/lib/rbarman/cli_command.rb#L181-L182 This is what my `check` command reports: ```txt $ barman -v 1.3.3 $ barman check foo...