openzfs
zfs-import-cache.service hangs boot
System information
| Type | Version/Name |
|---|---|
| Distribution Name | Mate Cinnamon |
| Distribution Version | 21 |
| Kernel Version | 6.1.9 |
| Architecture | x86_64 |
| OpenZFS Version | 2.1.9 |
Describe the problem you're observing
System with additional pool on a USB drive, LUKS encrypted, pool not clearly exported because kernel module panic'd over on-disk corruption of that pool.
Next boot hung as systemd waited for zfs-import-cache.service, which was waiting for a pool that could not show up (as cryptsetup.target is not configured to unlock it).
Had to boot from a rescue disk to nuke /etc/zfs/zpool.cache from the root filesystem.
Describe how to reproduce the problem
Have a pool that can't export, but is not available on next reboot.
Include any warning/errors/backtraces from the system logs
Something like Job zfs-import-cache.service is running (x/no timeout) in console,
with x incrementing till the heat-death of the universe, impossible to abort through ctrl-c or everything else I tried.
Suggestions to solve this:
- Do not enable zfs-import-cache.service by default, the runtime improvement this might give on PB-class servers do not happen on SOHO systems.
- Get rid of using zpool.cache as default and make it opt-in for systems that actually benefit from it.
https://github.com/openzfs/zfs/issues/14562 has more fun with systemd hanging forever.
Can we at least get reasonable timeouts?
I encountered this issue today as well. I'm on a laptop and I have one pool accessible over USB. ZFS somehow couldn't export this pool so I've shutdown the computer in case the kernel could recover cleanly from this.
It seems that the pool had not been exported, and next reboot the computer got stuck waiting for zfs-import-cache.service.
I'm using Linux Mint on a Dell XPS13, it took me three attempts to understand what was going on (because of the quiet and splash options, which hid useful information on the hang).
I don't understand why this is an opt-out rather than an opt-in. As far as I understand there is a incompatibility of use-cases : servers/SANs versus home users. The former expect their pool to be loaded at boot and the latter expect their (external) pool to behave like attached storage.
The "reasonable timeout" doesn't seems like a good idea : as a system administrator, I'd like my system to either boot properly, or not boot at all. The opt-in seems like a good idea. As a system administrator I'm well informed to know that I have to enable something, and as a home user I'm completely clueless about how ZFS behave "by default" (and when tinkering I expect to manually configure something, rather than have something configured automatically for me (by that I mean that importing a pool that wasn't there at boot time should not make that the system expect it to be here at next boot)).
I just ran into this on a Debian box.
In my case it's not zfs-import-cache.service that's actually hanging. It's the zpool import.
My pool ran completely out of space and was in the middle of a scrub. All ZFS-related stuff hanged as well as the reboot command. I power-cycled the server and it hanged at the zfs-import-cache.service. I rebooted again, set grub to use init=/bin/bash, got to a command prompt, and the moment I did zpool import tank it hanged. It's been attempting to import for several hours now. I can't even delete old snapshots to free up space. Lame.
I guess I'll see what things look like in the morning.
It took about 14 hours, but it finally finished booting. It's a bit unnerving it can take 14 hours to import a pool under whatever conditions caused that...
