Fix For ProxMox 5.x

[pbucher]

I'm not sure if this is the current way to fix this or not. I'm not a Perl programmer at all and this is mostly Greek to me.

That said I've been using ZnapZend for ages without issue under OmniOS and when I moved to proxmox 5.x(aka Debian Stretch with a custom kernel) ZnapZend stopped working. It may have worked on 4.x but I made the switch just has 5.x was released so I never ran production on 4.x.

Anyways, I traced the issue down to section of code under '#spawn event' never coming to life. The remote recv process fires up without issue but the local send command never happens and any debug statements inside $fc->on( spawn => sub { never get called.

My fix is to add the the one_tick() call. I've been running this for a year now with great results. I was using the .19 release branch and recently moved to head, which out issue. I tested head first without my fix and got the same results as before.

Thank you for making this great little script.

[coveralls]

Coverage increased (+0.009%) to 87.313% when pulling 7e97b968426ce4b65ad503263cc19f96c3bb2313 on pbucher:master into 69b7a71b572f1bdb477d90710db52e4bab847904 on oetiker:master.

[coveralls]

Coverage increased (+0.009%) to 87.313% when pulling 7e97b968426ce4b65ad503263cc19f96c3bb2313 on pbucher:master into 69b7a71b572f1bdb477d90710db52e4bab847904 on oetiker:master.

[pbucher]

See Issue #229 for additional background

[redmop]

I'm using this on Proxmox 5 (before this PR) and it works fine. I have it going on 9 different servers spread across 3 clients. What are you fixing here?

Edit: If this is for the mbuffer port thing, I'm not doing that, I'm just using SSH.

[pbucher]

Are you using it with remote destinations? I've tried this on several different Proxmox 5 servers and have always had the issue that the local thread never wakes up and executes the local send command. The remote server gets the recv command and is running waiting for the send that never comes.

I build the package using https://github.com/Gregy/znapzend-debian

Also here is my znapzend config for reference:

dst_a=root@zback:rpool/backupz/bbsc/ocean_rpool dst_a_plan=1days=>15minutes,5days=>1days,1years=>1weeks enabled=on feature=sudo,compressed mbuffer=/usr/bin/mbuffer:13871 mbuffer_size=2G post_znap_cmd=off pre_znap_cmd=off recursive=on src=rpool/data src_plan=3days=>15minutes,30days=>1days tsformat=%Y-%m-%d-%H%M%S

[redmop]

I have 1 local to external USB HDD. It's been ok.

Edit: I'm pretty busy today. Tomorrow, I'll spin up a Proxmox in a VM with 2 disks and test is out (unless someone beats me).

[Beneter]

Mojo::IOLoop::ForkCall was deprecated in favour of Mojo::IOLoop::Subprocess. If I had the time I would like to try if this issue still persists with the latter.

[oetiker]

what we especially need is a way for the subprocess to report stderr output from ssh back to the master process so that logging works properly.

[pbucher]

I'm happy to report the problem no longer exists on Proxmox 6.x. I'm not 100% sure what the root cause was with Promox 5.x. If I ever get a few spare cycles maybe I'll give a shot at switching things over to Mojo::IOLoop::Subprocess.