After upgrading packages recently ruby was increased from v2.0 to v2.1. zfstools installs its library files in /usr/local/lib/ruby/site_ruby/2.0/ which the new version of ruby does not inspect, and so the library files cannot be found.
Installing the ruby20 package restores the old ruby version but with the new binary /usr/local/bin/ruby20.
Modifying the zfstools scripts /usr/local/sbin/zfs-(auto-snapshot|cleanup-snapshots|snapshot-mysql) to "#! /usr/bin/env ruby20" in place of "#! /usr/bin/env ruby" resolved this issue for me, but maybe the correct solution is to move the libraries into ruby v2.1
It does work. Pkg is the problem. You have to manually reinstall zfstools and you'll get a fixed version using the right paths.
pkg install -f zfstools
By the way, I had the exact same issue and was pretty upset with Pkg for not handling it properly.
A commit references this bug:
Date: Fri May 1 04:13:35 UTC 2015
New revision: 385080
Force a rebuild for newer Ruby.
Pkg is not properly reinstalling this when ruby is upgraded which
causes this to break since it is left around in the old ruby
Ok, this has resolved the issue for me, thanks.
I did check the version of the zfstools package before posting this bug report and the version hasn't changed. I'm not sure of the versioning of the ports/packages system but should the version change from 0.3.2_1 to 0.3.2_2 (I've assumed the number after the _ is related to ports/packages changes rather than upstream changes).
(In reply to Duane from comment #4)
> Ok, this has resolved the issue for me, thanks.
> I did check the version of the zfstools package before posting this bug
> report and the version hasn't changed. I'm not sure of the versioning of
> the ports/packages system but should the version change from 0.3.2_1 to
> 0.3.2_2 (I've assumed the number after the _ is related to ports/packages
> changes rather than upstream changes).
That's part of the problem. Zfstools didn't change, but it was rebuilt
when Ruby was upgraded. However zfstools wasn't reinstalled as expected
by pkg. I bumped the revision so that the version will go up and a new
package will be built in a few days to ensure no one else hits this issue.
Happened again with the 2.1 -> 2.2 version bump in Ruby.
I don't understand how the dependency on Ruby works but it seems to dynamically track the current version since a re-install shifts the dependency, but would it be possible to have the script's #! target the dynamic version. Then when upgrading Ruby the script would continue to work against the older version until it was reinstalled and then it would target the later version.
Obviously it would be nice if pkg recognised the dynamic version dependency, but in the absence of that having a reliable workaround is important (and is there any risk that the dynamic dependency could lead to a compatibility problem where a later version of Ruby breaks zfstools and it isn't detected?).
Maybe, overcome by events. We have Ruby24 as default version.
There's been a few ruby upgrades since this was reopened and I haven't had any problems. It seems pkg is handling it fine now.