Project

General

Profile

Bug #17467

Control path for lz4c for non-FreeNAS replication targets.

Added by Chris Heerschap over 3 years ago. Updated almost 2 years ago.

Status:
Resolved
Priority:
Nice to have
Assignee:
William Grzybowski
Category:
Middleware
Target version:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:

HP N54L MicroServer

ChangeLog Required:
No

Description

I have my FreeNAS box replicating to a CentOS box running the latest version of ZFS on linux (0.6.5.7-1.el7.centos)

I had to reload the OS on the CentOS box, and was still having replication issues, when I noticed this in the FreeNAS /var/log/debug.log:

Sep 10 18:01:53 nas autorepl.py: [tools.autorepl:157] Replication result: bash: /usr/local/bin/lz4c: No such file or directory

The FreeNAS box assumes lz4c is installed under /usr/local/bin on the remote end, which is fine when replicating to another FreeNAS box, but the CentOS box installs lz4c under /usr/bin/lz4c.

Obvious fix - create a symlink from /usr/bin/lz4c to /usr/local/bin/lz4c on the CentOS box, and this does indeed fix the problem. What would be nice to have is a way to control where FreeNAS looks for the remote executables so I don't have to put in one-off hacks like this.

Thank you!

Associated revisions

Revision b34c054d (diff)
Added by William Grzybowski about 3 years ago

fix(repl): do not absolute paths for decompression bins This will let it work with linux, for instance. Ticket: #17467

Revision ae31feec (diff)
Added by William Grzybowski about 3 years ago

fix(repl): do not absolute paths for decompression bins This will let it work with linux, for instance. Ticket: #17467 (cherry picked from commit b34c054dbeabdb93a1c9298863faefa100229516)

Revision dfddc92a (diff)
Added by William Grzybowski about 3 years ago

fix(repl): do not absolute paths for decompression bins This will let it work with linux, for instance. Ticket: #17467 (cherry picked from commit b34c054dbeabdb93a1c9298863faefa100229516)

History

#1 Updated by Heather Ownby about 3 years ago

  • Assignee set to William Grzybowski

#2 Updated by William Grzybowski about 3 years ago

  • Tracker changed from Feature to Bug
  • Status changed from Unscreened to Screened
  • Target version changed from 9.10-STABLE-201606270534 to 9.10.2
  • Seen in set to 9.10-STABLE-201606270534

#3 Updated by William Grzybowski about 3 years ago

  • Status changed from Screened to Needs Developer Review

#4 Updated by William Grzybowski about 3 years ago

  • Assignee changed from William Grzybowski to Suraj Ravichandran

#5 Updated by Suraj Ravichandran about 3 years ago

  • Status changed from Needs Developer Review to Reviewed
  • Assignee changed from Suraj Ravichandran to William Grzybowski
  • % Done changed from 0 to 100

See comment on github commit page.

#6 Updated by Vaibhav Chauhan about 3 years ago

  • Status changed from Reviewed to Ready For Release

#7 Updated by Chris Heerschap about 3 years ago

Not important and no reason beyond my own curiosity - but how do I find the commit associated with this?

Thank you!

#8 Updated by William Grzybowski almost 3 years ago

Chris Heerschap wrote:

Not important and no reason beyond my own curiosity - but how do I find the commit associated with this?

Thank you!

its right here in the ticket: "Associated revisions"

#9 Updated by Dru Lavigne almost 2 years ago

  • Status changed from Ready For Release to Resolved

Also available in: Atom PDF