If a swapfile has been mounted (as opposed to a swap partition on the disk), when attempting to reboot, the system panics, complaining about not being able to read a block of swap data and then hangs. This is an issue for servers being rebooted where no one is watching the console and we don't find out the server never came back up until an alarm goes off. It seems that the reboot logic should at least try to quiesce and flush auxiliary swap before actually resetting the machine. This may be relevant also to Bug #187081.
It looks like this situation occurs only with manually added swap devices (including swap files) and not with swap devices added by /etc/rc.d/swap and /etc/rc.d/swaplate, since no writable filesystems are available when /etc/rc.d/swap runs and /etc/rc.d/swaplate removes any "late" devices it added when the system is shut down. Note that swapoff -a looks at /etc/fstab, not at the currently active swap devices (as would be shown by swapinfo). If additional logic is desired to turn off (some of the) active swap devices, it should probably be in init(8) (and reboot(8)) or in the kernel, so it executes after all other processes have terminated and the resulting I/O is minimized. It might be useful to non-forcibly unmount tmpfs (or all) mounts first. The actual panic with the usual information may be interesting as well. Normally, a failure to read from swap causes the affected process(es) to crash with SIGBUS (but things might be different for pageable kernel memory such as pipe buffers and execve arguments, or if a process has been swapped out and the kernel stack cannot be read back from swap).
Created attachment 206191 [details] 202420