https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275336
Bug ID: 275336
Summary: Processes exiting with SIGSEGV on shutdown on ZFS
systems
Product: Base System
Version: 14.0-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: [email protected]
Reporter: [email protected]
When shutting down both two of my machines, I see output like the following on
the console:
Waiting (max 60 seconds) for system process `vnlru' to stop... done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining... 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0
done
All buffers synced.
newnfs: server 'argon' error: fileid changed. fsid 0:0: expected fileid
0x1e9d81, got 0x2. (BROKEN NFS SERVER OR MIDDLEWARE)
pid 215 (autounmountd), jid 0, uid 0: exited on signal 11 (no core dump - other
error)
pid 6323 (mosh-server), jid 0, uid 1001: exited on signal 11 (no core dump -
too large)
pid 6615 (tmux), jid 0, uid 1001: exited on signal 11 (no core dump - other
error)
pid 10836 (sudo), jid 0, uid 0: exited on signal 11 (no core dump - bad
address)
pid 7032 (csh), jid 0, uid 0: exited on signal 11 (no core dump - too large)
pid 6611 (tmux), jid 0, uid 1001: exited on signal 11 (no core dump - other
error)
pid 10837 (sudo), jid 0, uid 0: exited on signal 11 (no core dump - bad
address)
pid 10789 (tcsh), jid 0, uid 1001: exited on signal 11 (no core dump - other
error)
pid 10838 (csh), jid 0, uid 0: exited on signal 11 (no core dump - too large)
pid 7027 (sudo), jid 0, uid 0: exited on signal 11 (no core dump - bad address)
pid 7031 (sudo), jid 0, uid 0: exited on signal 11 (no core dump - bad address)
pid 6624 (tcsh), jid 0, uid 1001: exited on signal 11 (no core dump - other
error)
pid 6324 (tcsh), jid 0, uid 1001: exited on signal 11 (no core dump - other
error)
Uptime: 9m12s
Khelp module "ertt" can't unload until its refcount drops from 16 to 0.
Ignoring the NFS and ertt messages (the NFS server is the same 14-STABLE build,
fwiw), this is only happening on systems that use ZFS. I have seen it on a
14-RELEASE box that uses ZFS root, and on a 14-STABLE
ae8387cc818a0d6a2229ee049b671482e1549519 box that uses UFS root, but has ZFS
volumes.
--
You are receiving this mail because:
You are the assignee for the bug.