Note that for bionic as of this week the behavior is now different. This
particular problem doesn't surface for zfs-import-cache.service (because
the ConditionPathExists expression is back in the unit).

It's not all good news, however, as that one failed unit has been
replaced with:

$ systemctl --failed
● zfs-mount.service loaded failed failed Mount ZFS filesystems
● zfs-share.service loaded failed failed ZFS file system shares
● zfs-zed.service   loaded failed failed ZFS Event Daemon (zed)

All because the zfs kernel module is now no longer being loaded. So,
it's related to this bug in that the zfs-import-cache.service was
loading the zfs kernel module because it was running unconditionally.
Now that this unit is no longer running do to ConditionPathExists, other
zfs units fail now.

I'm fairly certain we ran into this same issue back in xenial, I'll see
if I can track down the launchpad # for it. Thanks!

You received this bug notification because you are a member of Kernel
Packages, which is subscribed to zfs-linux in Ubuntu.

  zfs-import-cache.service fails on startup

Status in zfs-linux package in Ubuntu:
  In Progress

Bug description:
  I just noticed on my test VM of artful that zfs-import-cache.service
  does not have a ConditionPathExists=/etc/zfs/zpool.cache. Because of
  that, it fails on startup, since the cache file does not exist.

  This line is being deleted by 
debian/patches/ubuntu-load-zfs-unconditionally.patch. This patch seems to exist 

  This patch still exists in bionic, so I assume it will be similarly

  If the goal of the patch is to load the module (and only that), I
  think it should create a third unit instead:

   ^^ runs modprobe zfs

  zfs-import-cache.service & zfs-import-scan.service
    ^^ per upstream minus modprobe plus Requires=zfs-load-module.service

  I have tested this manually and it works. I can submit a package patch
  if this is the desired solution.

  Interestingly, before this change, zfs-import-scan.service wasn't
  starting. If started manually, it worked. I had to give it a
  `systemctl enable zfs-import-scan.service` to create the Wants
  symlinks. Looking at the zfsutils-linux.postinst, I see the correct
  boilerplate from dh_systemd, so I'm not sure why this wasn't already
  done. Can anyone confirm or deny whether zfs-import-scan.service is
  enabled out-of-the-box on their system?

  Is the zfs-import-scan.service not starting actually the cause of the
  original bug? The design is that *either* zfs-import-cache.service or
  zfs-import-scan.service starts. They both call modprobe zfs.

To manage notifications about this bug go to:

Mailing list:
Post to     :
Unsubscribe :
More help   :

Reply via email to