From owner-freebsd-bugs@freebsd.org Sun Jun 21 09:43:59 2020 Return-Path: Delivered-To: freebsd-bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CC6C5348C0A for ; Sun, 21 Jun 2020 09:43:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 49qSKq55Wjz4fYg for ; Sun, 21 Jun 2020 09:43:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id AECA5348C09; Sun, 21 Jun 2020 09:43:59 +0000 (UTC) Delivered-To: bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AE91E348C08 for ; Sun, 21 Jun 2020 09:43:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49qSKq4Gm2z4fWG for ; Sun, 21 Jun 2020 09:43:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 8DEE41B70B for ; Sun, 21 Jun 2020 09:43:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 05L9hxCD077439 for ; Sun, 21 Jun 2020 09:43:59 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 05L9hxR4077438 for bugs@FreeBSD.org; Sun, 21 Jun 2020 09:43:59 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 147444] [rc.d] [patch] /etc/rc.d/zfs stop not called on reboot & modules cause system hang Date: Sun, 21 Jun 2020 09:43:59 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: conf X-Bugzilla-Version: 7.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ms-freebsd-bugzilla@stoffnet.at X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2020 09:43:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D147444 --- Comment #4 from Markus Stoff --- It's amazing that after more than 10 years a single line could not be added. Please find attached the diff to facilitate that change. If there is a reas= on why /etc/rc.d/zfs should not be called by rc.shutdown, please let us know. Patch: rc.shutdown calls rcorder(8) with the '-k shutdown' option. rcorder(8) will therefore only return files declaring the 'shutdown' keyword: # KEYWORD: shutdown As of 12.1, /etc/rc.d/zfs does not declare any keywords. This patch adds the 'shutdown' keyword. Use case: Providing ZFS datasets to a jail Problem: Without calling /etc/rc.d/zfs on shutdown, resources associated with ZFS mo= unts are not freed and the jail will remain in dying state. In addition, the dat= aset is now in a dangling state, as the jail it is attached to is dying. Workaround: In /etc/jail.conf, make sure to run 'service zfs stop' when the jail is stopped: exec.stop =3D "/bin/sh /etc/rc.shutdown"; exec.stop +=3D "/usr/sbin/service zfs stop"; Desaster recovery: With the jail in dying state, issue: # After the following statements, the dataset will be unmounted and the jail # will finally be gone zfs set jailed=3Doff tank/jaildata zfs unmount tank/jaildata # Don't forget to set jailed=3Don before starting the jail again zfs set jailed=3Don tank/jaildata How to reproduce: # jail.conf test { path =3D "/jails/test"; exec.clean; exec.start =3D "/bin/sh /etc/rc"; exec.stop =3D "/bin/sh /etc/rc.shutdown"; # Make sure to unmount all ZFS datasets before stopping the jail # Required unless the jails /etc/rc.d/zfs contains '# KEYWORD: shutdown' exec.stop +=3D "/usr/sbin/service zfs stop"; # Mandatory to use ZFS in jail allow.mount; allow.mount.zfs; enforce_statfs =3D 1; # must be less than 2 # Attach ZFS dataset to jail exec.created =3D "/sbin/zfs jail test tank/jaildata"; # Make sure the /dev/zfs device is included (it is with the default # devfs_ruleset =3D 4) mount.devfs; } # Create dataset zfs create -o jailed=3Don -o mountpoint=3D/data tank/jaildata mkdir -p /jails/test/data sysrc -f /jails/test/etc/rc.conf zfs_enable=3DYES # Start the jail jail -c test # List ZFS mounts zfs mount | grep jaildata tank/jaildata /jails/test/data # Stop the jail jail -r test # List ZFS mounts (mount is still there) zfs mount | grep jaildata tank/jaildata /jails/test/data Additional Remarks: While the workaround seems to be okay-ish for the jail situation, it is sti= ll unclean. However, for physical hosts this may wreak havoc with the pool if shared spares are used, as 'zfs unshare' is never invoked on shutdown. --=20 You are receiving this mail because: You are the assignee for the bug.=