/ was not properly dismounted

Alain De Vos

Alain De Vos

When i do nicely "reboot" on reboot i get always the message from my ufs filesystem,
/ was not properly dismounted
In rc.conf i have
Code: 
fsck_y_enable="YES"     # Set to YES to do fsck -y if the initial preen fails.
background_fsck="YES"   # Attempt to run fsck in the background where possible.
background_fsck_delay="60" # Time to wait (seconds) before starting the fsck.
 
Yep the man reboot even says it in its description, it isn't joking ^^
DESCRIPTION
The halt and reboot utilities flush the file system cache to disk, send all running processes a
SIGTERM (and subsequently a SIGKILL) and, respectively, halt or restart the system. The action
is logged, including entering a shutdown record into the user accounting database.
Click to expand...
 
It's a cute theory, but doesn't hold much water.
gotnull said:
I think reboot kind of "kills" everything while shutdown -r now turns off properly the running processes.
I don't know if it can solve your problem but you can give it a shot.
Click to expand...
Then how would "turning off properly the running processes" be achieved if not by some invocation of kill?
gotnull said:
Yep the man reboot even says it in its description, it isn't joking ^^
Click to expand...
It also gives a clue, however:
Code: 
     -l      The halt or reboot is not logged to the system log.  This option
             is intended for applications such as shutdown(8), that call
             reboot or halt and log this themselves.
And indeed:
C: 
        if (doreboot) {
            BOOTTRACE("exec reboot(8) -l...");
            execle(_PATH_REBOOT, "reboot", "-l", nosync,
                (char *)NULL, empty_environ);
            syslog(LOG_ERR, "shutdown: can't exec %s: %m.",
                _PATH_REBOOT);
            warn(_PATH_REBOOT);
        }
 
While reboot(8) effectively kills processes, the filesystem is closed cleanly, it's not marked "dirty". The filesystem is considered "dirty", that's why fsck(8) runs. But because it's doing a background fsck(8) (background_fsck="YES") it will do so while the filesystems are mounted read/write. And can therefor not fix certain filesystem errors, so it's still considered "dirty", no matter how many times you reboot(8) or shutdown(8) the system.

Don't enable background_fsck, or boot to single user mode and actually let fsck(8) fix the filesystem issues.

That said, you should definitely use shutdown -r now, not reboot. A proper shutdown(8) will run /etc/rc.shutdown and "stop" all running services in a reverse rcorder(8).
 
SirDice said:
While reboot(8) effectively kills processes, the filesystem is closed cleanly [...]
Click to expand...
Reading Eric A. Borisch's description here; a part from that:
Eric A. Borisch said:
If something is keeping a process from nicely shutting down for a while, AND it doesn't cause any page-ins for three seconds, halt/reboot may KILL a still-closing process; shutdown gives it more time, and can have (depending on the rc scripts) actual waits for exits rather than the heuristic wait-for-"idle".
Click to expand...
could mean that if something—that could even be some filesystem aspects, If I understand correctly—isn't quick enough on their feet in mopping itself up, it would still be unceremoniously killed. No details about the marking of a filesystem as dirty though.
 
Since mount(2) marks a UFS file system as dirty, and unmount(2) marks it as clean, a "dirty file system" is one that has not been properly unmounted prior to the kernel terminating.

A file system can't be unmounted if there are any remaining entries in the kernel's open file table at the time the kernel exits -- which implies that all processes with open files must have exited (or gone to a lot of trouble to close all file descriptors).
 
You must log in or register to reply here.
Back
Top