Subject: kern/23397: NetBSD does not cleanly shutdowns when /var/run is a MFS mount point
To: None <gnats-bugs@gnats.NetBSD.org>
From: None <sobrado@acm.org>
List: netbsd-bugs
Date: 11/09/2003 18:18:08
>Number: 23397
>Category: kern
>Synopsis: NetBSD does not cleanly shutdowns when /var/run is a MFS mount point
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Nov 09 18:19:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator: Igor Sobrado
>Release: NetBSD 1.6.1
>Organization:
University of Oviedo
>Environment:
It is a standard NetBSD 1.6.1 system running GENERIC kernel. (I have
not network access to that machine now.)
>Description:
I am trying to use /var/run as a mounting point for a memory
filesystem (MFS). It is a common configuration on other
operating systems (e.g., latest Solaris releases use /var/run
as a mounting point for a tmpfs) and provides some important
advantages.
This is the /etc/fstab file used on the test machine:
/dev/wd0a / ffs rw,softdep 1 1
/dev/wd0b none swap sw 0 0
/dev/wd0e /stand ffs rw,softdep 1 2
/dev/wd0f /var ffs rw,softdep 1 2
/dev/wd0g /usr ffs rw,softdep 1 2
/dev/wd0h /usr/contrib ffs rw,softdep 1 2
/dev/wd0i /usr/obj ffs rw,softdep 1 2
/dev/wd0j /usr/pkg ffs rw,softdep 1 2
/dev/wd0k /usr/pkgsrc ffs rw,softdep 1 2
/dev/wd0l /usr/src ffs rw,softdep 1 2
/dev/wd0m /dump ffs rw,softdep 1 2
/dev/wd0n /home ffs rw,softdep 1 2
swap /tmp mfs rw,-s=16m 0 0
swap /var/run mfs rw,-s=1m 0 0 <- problem
kernfs /kern kernfs rw 0 0
procfs /proc procfs rw 0 0
Problem description: when mounting a MFS in /var/run the machine
cannot cleanly shutdown. It locks when syncing disks and all
filesystems must be fsck'ed on the next boot.
To avoid loses of important PID files created when booting
the operating system, I changed critical_filesystems_beforenet
from "/var" to "/var /var/run". Undoing this change does not
fixes the problem.
>How-To-Repeat:
The problem can be repeated by mouting a small MFS in /var/run,
as described above, and rebooting the computer.
Brian A. Seklecki was able to repeat the problem on his computer,
and proposed sending this problem report.
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: