There seems to be no information how this issue is related to selinux-policy.
Unfortunately, I was unable to reproduce the issue and gather additional data.
Did you try the same scenario in SELinux permissive mode?
Are there any AVC denials in journal or dmesg? Supposing auditd is not running any longer that time.

Hello,

So I went with reproducing the issue. The reproducer is very simple:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
# vgcreate data /dev/vdb
# lvcreate -T -L 5G --name test_volume data

# touch /.autorelabel
# reboot
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Having a thin pool makes the dm-event.socket be triggered, hence related dm-event.service (dmeventd daemon).

Upon relabeling, the /usr/libexec/selinux/selinux-autorelabel script reboots the system using forced flag (line 66):
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
 32 relabel_selinux() {
 :
 65     sync
 66     systemctl --force reboot
 67 }
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

This ends up NOT triggering normal unit shutdown, but only send TERM signal, then KILL later.

Due to dmeventd NOT quitting on receiving TERM signal, we get the delay then systemd sends the KILL signal.

I think this needs to be fixed on both sides:
1. dmeventd should probably quit (unless there is a good reason not to do so)
2. the script should not use "--force" because not going through unit shutdown may be bad, who knows ...

Ideally the script should perform a "systemctl reboot" and retry with "--force" flag after some time, e.g.:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
 65     sync
 66     systemctl reboot
 67     sleep 30
 68     systemctl --force reboot
 69 }
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

User is supposed to  *UNMONITOR*  LVs  before  quiting dmeventd.

'dmveventd' is protected  against signal - so processed commands which *MAY* freeze your system (i.e.  suspend devices) aren't leaving  system in unusable state.

So I'm not sure what  '--force reboot' is doing - but  it should run   'vgchange --monitor n' first.

From discussion BZ #2101793, it appears selinux-autorelabel script needs to stop using "systemctl --force reboot", which is not suitable at all.

I think we just need to remove the "--force" flag, there is nothing to do:
in case something bad happens, the reboot will anyway happen automatically on "reboot.target" timeout, as on a normal system reboot.

selinux-autorelabel script was originally written for SysV initscripts and hasn't much changed since than.

(In reply to Renaud Métrich from comment #10)
> 
> Ideally the script should perform a "systemctl reboot" and retry with
> "--force" flag after some time, e.g.:
> -------- 8< ---------------- 8< ---------------- 8< ---------------- 8<
> --------
>  65     sync
>  66     systemctl reboot
>  67     sleep 30
>  68     systemctl --force reboot
>  69 }
> -------- 8< ---------------- 8< ---------------- 8< ---------------- 8<
> --------


`systemctl reboot` should do it itself in 30 minutes:

    $ cat /usr/lib/systemd/system/reboot.target
    ...
    [Unit]
    Description=System Reboot
    Documentation=man:systemd.special(7)
    DefaultDependencies=no
    Requires=systemd-reboot.service
    After=systemd-reboot.service
    AllowIsolate=yes
    JobTimeoutSec=30min
    JobTimeoutAction=reboot-force
    
    [Install]
    Alias=ctrl-alt-del.target

I would try to drop `--force` first. And if 30min timeout too long, users could use their own reboot.target with lower timeout

OK great!
At this step anyway there is not many services running, so it's unlikely some service will hang.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (policycoreutils bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:7805