Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Strange, but the last four bootups have been without error. Perhaps it's cured itself?
Quote:
Originally Posted by unSpawn
OK, so what in the /etc/rc* modifies /etc/mtab on shutdown?
I can't find anything in /etc/rc.d/rc.6 that modifies mtab on shutdown. And the mtab from /lost+found looks exactly like the one from /etc:
#9177226 from /lost+found:
Generally, fstab is just stored permanently on disk as a wish list of what you want mounted or might be mounted, but mtab is generated on the fly by the kernel as list of what's actually mounted at any given moment.
Losing mtab shouldn't be an issue.
Having said that, maybe you could try using the old-skool technique of throwing a couple of 'sync' cmds into the shutdown process, thus forcing the disks to be updated before unmounting them.
Booted up OK again.
Thanks, Chris. There are 3 sync commands in there already:
Code:
#! /bin/sh
#
# rc.6 This file is executed by init when it goes into runlevel
# 0 (halt) or runlevel 6 (reboot). It kills all processes,
# unmounts file systems and then either halts or reboots.
#
# Version: @(#)/etc/rc.d/rc.6 2.47 Sat Jan 13 13:37:26 PST 2001
#
# Author: Miquel van Smoorenburg <miquels@drinkel.nl.mugnet.org>
# Modified by: Patrick J. Volkerding, <volkerdi@slackware.com>
#
# Set the path.
PATH=/sbin:/etc:/bin:/usr/bin
# If there are SystemV init scripts for this runlevel, run them.
if [ -x /etc/rc.d/rc.sysvinit ]; then
. /etc/rc.d/rc.sysvinit
fi
# Set linefeed mode to avoid staircase effect.
/bin/stty onlcr
echo "Running shutdown script $0:"
# Find out how we were called.
case "$0" in
*0)
command="halt"
;;
*6)
command=reboot
;;
*)
echo "$0: call me as \"rc.0\" or \"rc.6\" please!"
exit 1
;;
esac
# Save the system time to the hardware clock using hwclock --systohc.
if [ -x /sbin/hwclock ]; then
# Check for a broken motherboard RTC clock (where ioports for rtc are
# unknown) to prevent hwclock causing a hang:
if ! grep -q -w rtc /proc/ioports ; then
CLOCK_OPT="--directisa"
fi
if grep -q "^UTC" /etc/hardwareclock 2> /dev/null ; then
echo "Saving system time to the hardware clock (UTC)."
/sbin/hwclock $CLOCK_OPT --utc --systohc
else
echo "Saving system time to the hardware clock (localtime)."
/sbin/hwclock $CLOCK_OPT --localtime --systohc
fi
fi
# Run any local shutdown scripts:
if [ -x /etc/rc.d/rc.local_shutdown ]; then
/etc/rc.d/rc.local_shutdown stop
fi
# Stop the Apache web server:
if [ -x /etc/rc.d/rc.httpd ]; then
/etc/rc.d/rc.httpd stop
fi
# Stop the MySQL database:
if [ -r /var/run/mysql/mysql.pid ]; then
. /etc/rc.d/rc.mysqld stop
fi
# Stop the Samba server:
if [ -x /etc/rc.d/rc.samba ]; then
. /etc/rc.d/rc.samba stop
fi
# Shut down the NFS server:
if [ -x /etc/rc.d/rc.nfsd ]; then
/etc/rc.d/rc.nfsd stop
fi
# Shut down the SSH server:
if [ -x /etc/rc.d/rc.sshd ]; then
/etc/rc.d/rc.sshd stop
fi
# Shut down the SASL authentication daemon:
if [ -x /etc/rc.d/rc.saslauthd ]; then
/etc/rc.d/rc.saslauthd stop
fi
# Shut down OpenLDAP:
if [ -x /etc/rc.d/rc.openldap ]; then
/etc/rc.d/rc.openldap stop
fi
# Stop D-Bus:
if [ -x /etc/rc.d/rc.messagebus ]; then
sh /etc/rc.d/rc.messagebus stop
fi
# Kill any processes (typically gam) that would otherwise prevent
# unmounting NFS volumes:
unset FUSER_DELAY
for dir in $(/bin/mount | grep 'type nfs' | cut -d ' ' -f 3 ) ; do
echo "Killing processes holding NFS mount $dir open..."
# Background this to prevent fuser from also blocking shutdown:
/usr/bin/fuser -k -m $dir &
FUSER_DELAY=5
done
# If fuser was run, let it have some delay:
if [ ! -z "$FUSER_DELAY" ]; then
sleep $FUSER_DELAY
fi
# Unmount any NFS, SMB, or CIFS filesystems:
echo "Unmounting remote filesystems."
/bin/umount -v -a -l -f -r -t nfs,smbfs,cifs
# Try to shut down pppd:
PS="$(ps ax)"
if echo "$PS" | /bin/grep -q -w pppd ; then
if [ -x /usr/sbin/ppp-off ]; then
/usr/sbin/ppp-off
fi
fi
# Bring down the networking system, but first make sure that this
# isn't a diskless client with the / partition mounted via NFS:
if ! /bin/mount | /bin/grep -q 'on / type nfs' ; then
if [ -x /etc/rc.d/rc.inet1 ]; then
. /etc/rc.d/rc.inet1 stop
fi
fi
# In case dhcpcd might have been manually started on the command line,
# look for the .pid file, and shut dhcpcd down if it's found:
if /bin/ls /etc/dhcpc/*.pid 1> /dev/null 2> /dev/null ; then
/sbin/dhcpcd -k 1> /dev/null 2> /dev/null
# A little time for /etc/resolv.conf and/or other files to
# restore themselves.
sleep 2
fi
# Shut down PCMCIA devices:
if [ -x /etc/rc.d/rc.pcmcia ]; then
. /etc/rc.d/rc.pcmcia stop
# The cards might need a little extra time here to deactivate:
/bin/sleep 5
fi
# Turn off process accounting:
if [ -x /sbin/accton -a -r /var/log/pacct ]; then
/sbin/accton off
fi
# Terminate acpid before syslog:
if [ -x /etc/rc.d/rc.acpid -a -r /var/run/acpid.pid ]; then # quit
. /etc/rc.d/rc.acpid stop
fi
# Kill all processes.
# INIT is supposed to handle this entirely now, but this didn't always
# work correctly without this second pass at killing off the processes.
# Since INIT already notified the user that processes were being killed,
# we'll avoid echoing this info this time around.
if [ ! "$1" = "fast" ]; then # shutdown did not already kill all processes
/sbin/killall5 -15
/bin/sleep 5
/sbin/killall5 -9
fi
# Try to turn off quota.
if /bin/grep -q quota /etc/fstab ; then
if [ -x /sbin/quotaoff ]; then
echo "Turning off filesystem quotas."
/sbin/quotaoff -a
fi
fi
# Carry a random seed between reboots.
echo "Saving random seed from /dev/urandom in /etc/random-seed."
# Use the pool size from /proc, or 512 bytes:
if [ -r /proc/sys/kernel/random/poolsize ]; then
/bin/dd if=/dev/urandom of=/etc/random-seed count=1 bs=$(cat /proc/sys/kernel/random/poolsize) 2> /dev/null
else
/bin/dd if=/dev/urandom of=/etc/random-seed count=1 bs=512 2> /dev/null
fi
/bin/chmod 600 /etc/random-seed
# Before unmounting file systems write a reboot or halt record to wtmp.
$command -w
# Clear /var/lock/subsys.
if [ -d /var/lock/subsys ]; then
rm -f /var/lock/subsys/*
fi
# Turn off swap:
echo "Turning off swap."
/sbin/swapoff -a
/bin/sync
echo "Unmounting local file systems."
/bin/umount -v -a -t no,proc,sysfs
echo "Remounting root filesystem read-only."
/bin/mount -v -n -o remount,ro /
# This never hurts:
/bin/sync
# Close any volumes opened by cryptsetup:
if [ -f /etc/crypttab -a -x /sbin/cryptsetup ]; then
cat /etc/crypttab | grep -v "^#" | grep -v "^$" | while read line; do
# NOTE: we only support LUKS formatted volumes (except for swap)!
LUKS=$(echo $line | tr '\t' ' ' | tr -s ' ' | cut -f1 -d' ')
DEV=$(echo $line | tr '\t' ' ' | tr -s ' ' | cut -f2 -d' ')
OPTS=$(echo $line | tr '\t' ' ' | tr -s ' ' | cut -f4 -d' ')
if /sbin/cryptsetup isLuks $DEV 2>/dev/null ; then
echo "Locking LUKS crypt volume '${LUKS}':"
/sbin/cryptsetup luksClose ${LUKS}
elif echo $OPTS | grep -wq swap ; then
# If any of the volumes was used as encrypted swap,
# then run mkswap on the underlying device -
# in case other Linux installations on this computer should use it:
echo "Erasing encrypted swap '${LUKS}' and restoring normal swap on ${DEV}:"
/sbin/cryptsetup remove ${LUKS}
mkswap $DEV
fi
done
fi
# Deactivate LVM volume groups:
if [ -r /etc/lvmtab -o -d /etc/lvm/backup ]; then
echo "Deactivating LVM volume groups:"
/sbin/vgchange -an --ignorelockingfailure
fi
# This never hurts again (especially since root-on-LVM always fails
# to deactivate the / logical volume... but at least it was
# remounted as read-only first)
/bin/sync
# sleep 3 fixes problems with some hard drives that don't
# otherwise finish syncing before reboot or poweroff
/bin/sleep 3
# This is to ensure all processes have completed on SMP machines:
wait
if [ -x /sbin/genpowerd ]; then
# See if this is a powerfail situation:
if /bin/egrep -q "FAIL|SCRAM" /etc/upsstatus 2> /dev/null ; then
# Signal UPS to shut off the inverter:
/sbin/genpowerd -k
if [ ! $? = 0 ]; then
echo
echo "There was an error signaling the UPS."
echo "Perhaps you need to edit /etc/genpowerd.conf to configure"
echo "the serial line and UPS type."
# Wasting 15 seconds of precious power:
/bin/sleep 15
fi
fi
fi
# Now halt (poweroff with APM or ACPI enabled kernels) or reboot.
if [ "$command" = "reboot" ]; then
echo "Rebooting."
/sbin/reboot
else
/sbin/poweroff
fi
Indeed, but the point is to have at least 2 syncs (some recommended 3 due to built-in HW buffering etc) as literally the last cmds just before reboot or power off eg old-skool shutdown was
Code:
sync
sync
sync #(optionally)
shutdown -h now
Any time you do something, you (potentially) un-sync the disk(s) version of reality from the RAM version...
Eg taking the end of your script
Code:
# Now halt (poweroff with APM or ACPI enabled kernels) or reboot.
if [ "$command" = "reboot" ]; then
echo "Rebooting."
sync
sync
/sbin/reboot
else
sync
sync
/sbin/poweroff
fi
Thanks again, Chris.
Got the error again this morning, so I've put the extra syncs in /etc/rc.d/rc.6. Since it's not a regular occurrence, I'll have to see what happens over the next week of bootups. Fingers, toes, and eyes crossed.
Not only that but at the bottom of the script it also performs an explicit '/bin/mount -v -n -o remount,ro /' to ensure /etc/mtab doesn't get updated by mount. As writing /etc/mtab happens on "remount,ro" it still shouldn't be impossible to troubleshoot but it might require looking at system calls and logging them where a log file still can be written to (as in remote). You might find that requiring a bit too much work. As a temporary workaround, how about linking mtab to something on an expendable file system like /dev/shm? (Won't work if /etc/mtab is hard-coded in the 'mount' binary and in a way it ignores substitutes anyway.)
Not only that but at the bottom of the script it also performs an explicit '/bin/mount -v -n -o remount,ro /' to ensure /etc/mtab doesn't get updated by mount. As writing /etc/mtab happens on "remount,ro" it still shouldn't be impossible to troubleshoot but it might require looking at system calls and logging them where a log file still can be written to (as in remote). You might find that requiring a bit too much work. As a temporary workaround, how about linking mtab to something on an expendable file system like /dev/shm? (Won't work if /etc/mtab is hard-coded in the 'mount' binary and in a way it ignores substitutes anyway.)
Thanks, unSpawn. Too much work, and beyond my present level of knowledge. I wouldn't want to tinker with the system too much, since this error has only shown up in the last month or so, it wasn't there right after installation of Slackware 13.37.
If it sounds suspicious, what do you suspect may be causing it? I ran rkhunter last week, and it found nothing.
I would like to find an explanation, definitely. When the error first cropped up, I did a websearch, and all similar problems seem to have been cleared up with a manual fsck.
If it sounds suspicious, what do you suspect may be causing it?
I agree. Dropping clues slash hints would have been helpful.
Quote:
Originally Posted by brianL
I ran rkhunter last week, and it found nothing.
...because RKH doesn't know about any /etc/mtab-modifying malware. Not that I would suspect yours is a case of malware anyway.
Quote:
Originally Posted by brianL
I would like to find an explanation, definitely. When the error first cropped up, I did a websearch, and all similar problems seem to have been cleared up with a manual fsck.
We're talking about writing /etc/mtab on shutdown slash reboot and beyond the point any unprivileged user-initiated applications survive so I strongly doubt doing a web search or anything else would influence this behaviour. Do you perchance have FUSE installed? If you don't would you be willing to install it temporarily? If you can then FUSE-loggedfs may help us show (example) in more detail what's going on.
Yes, FUSE is already installed. And I've managed to get loggedfs installed after a bit of a struggle. Now all I have to do is work out what to do next.
Thanks, unSpawn.
in /etc/rc.d/rc.6. IMO best put it right after the last 'sync' to start with.
2) Reboot should show loggedfs kicks in writing to stdout (http://loggedfs.sourceforge.net/loggedfs.html).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.