Bug 202420 - Unmount Of Swap Files At Reboot Fails
Summary: Unmount Of Swap Files At Reboot Fails
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: 10.2-STABLE
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-08-18 16:34 UTC by tundra
Modified: 2019-08-01 10:42 UTC (History)
3 users (show)

See Also:


Attachments
202420 (39.69 KB, application/pdf)
2019-08-01 10:42 UTC, martha simons
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description tundra 2015-08-18 16:34:21 UTC
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.
Comment 1 Jilles Tjoelker freebsd_committer 2016-12-27 23:35:27 UTC
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).
Comment 2 martha simons 2019-08-01 10:42:04 UTC
Created attachment 206191 [details]
202420