Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 21 Jun 2020 09:43:59 +0000
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
Message-ID:  <bug-147444-227-9iRU5d9udO@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-147444-227@https.bugs.freebsd.org/bugzilla/>
References:  <bug-147444-227@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D147444

--- Comment #4 from Markus Stoff <ms-freebsd-bugzilla@stoffnet.at> ---
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.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-147444-227-9iRU5d9udO>