Need help on df -k issue

[Sreer]

Hi Gurus,

In My Linux box facing an issue df -k .  not showing any result!

root @server1:~# uname -a
Linux server1 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
root @server1:~#
root @server1:~# cat /etc/*release
Red Hat Enterprise Linux Client release 5.4 (Tikanga)
root @server1:~#
root @server1:~# df -k
df: cannot read table of mounted file systems
root @server1:~# ls -l /etc/mtab
-rw-r--r-- 1 root root 0 Aug 29 13:56 /etc/mtab
root @server1:~#
root @server1:~#
root @server1:~# mount -a
mount: /dev/DataVol/LogVol04 already mounted or /local/opt busy
mount: /dev/DataVol/LogVol05 already mounted or /local/home busy
mount: /dev/RootVol/LogVol02 already mounted or /var busy
mount: /dev/RootVol/LogVol03 already mounted or /tmp busy
mount: /dev/cciss/c0d0p1 already mounted or /boot busy
mount: devpts already mounted or /dev/pts busy
mount: sysfs already mounted or /sys busy
root @server1:~#
root @server1:~#
root @server1:~# tail -f /var/log/messages
Aug 29 06:10:37 server1 xinetd[4307]: EXIT: vnetd status=0 pid=7122 duration=1(sec)
Aug 29 07:26:51 server1 xinetd[4307]: START: vnetd pid=9681 from=44.55.104.89
Aug 29 07:26:51 server1 xinetd[4307]: START: vnetd pid=9682 from=44.55.104.89
Aug 29 07:26:51 server1 xinetd[4307]: EXIT: vnetd status=0 pid=9682 duration=0(sec)
Aug 29 07:26:52 server1 xinetd[4307]: EXIT: vnetd status=0 pid=9681 duration=1(sec)
Aug 29 08:44:50 server1 xinetd[4307]: START: vnetd pid=12244 from=44.55.104.89
Aug 29 08:44:50 server1 xinetd[4307]: START: vnetd pid=12245 from=44.55.104.89
Aug 29 08:44:50 server1 xinetd[4307]: EXIT: vnetd status=0 pid=12245 duration=0(sec)
Aug 29 08:44:51 server1 xinetd[4307]: EXIT: vnetd status=0 pid=12244 duration=1(sec)
Aug 29 09:41:16 server1 xinetd[4307]: START: login pid=14658 from=152.9.101.178

root @server1:~#

I tried to delete /etc/mtab  then tried mount -a

no progress... Please help me to solve ifpossible w/o reboot

Rgds

Sree

[Matti_Kurkela]

Your /etc/mtab has been truncated, but the filesystems are probably actually still mounted.

Because commands like "df" and "mount" will use the information in /etc/mtab, they will now show no mounted disks even if it isn't actually true. (At least the root filesystem must obviously be mounted, otherwise you could not run those commands at all.)

Linux kernel maintains a list of mounted filesystems in /proc/mounts: this list is in the same format as /etc/mtab. Because /proc/mounts is dynamically generated by the kernel, it is guaranteed to reflect the true situation.

To repopulate your /etc/mtab, run this command:

cat /proc/mounts > /etc/mtab

 If all the filesystems listed in /etc/fstab were mounted when /etc/mtab was truncated, an alternate way to achieve the same result would be to run "fake" mount operations on each filesystem, like this:

mount -f -a

 I would recommend the first command. Use one or the other.

The log messages look like xinetd's regular statistics messages for connections related to Veritas (now Symantec) Netbackup backup software and one rlogin connection. They don't seem to be directly related to the /etc/mtab truncation issue.

[HP-UX-OS]

This is regarding Matti's reply: /proc/mounts and /etc/mtab are two different in content, and in format. I wonder how /proc/mounts can recreate /etc/mtab by simply "copy over".

[Matti_Kurkela]

In a sense, yes, they are somewhat different. But /proc/mounts format is essentially a subset of /etc/mtab format. Any valid /proc/mounts line should be valid for /etc/mtab too, it just might not have all the information (mainly, the mount options) in all cases.

Both /etc/mtab and /proc/mounts do have the same basic format:

<device/remotefs/placeholder> <mountpoint> <FStype> <comma-separated list of mount options> 0 0

If you have lost your /etc/mtab, /proc/mounts can be used as a temporary substitute that should in most cases be good enough to get the system shutdown in a controlled fashion and then rebooted, at which point /etc/mtab will be regenerated anyway. See /etc/rc.d/rc.sysinit on RHEL5. You'll find a comment "# Clear mtab": unless the root filesystem is intended to stay read-only, the /etc/mtab will be truncated to zero size.

If you haven't used the "user" mount option, it is likely the system will work well enough for most purposes, so an immediate reboot will not be required.

RHEL5 /proc/mounts has an extra entry for the root filesystem, but that does not matter since you don't ever unmount the root filesystem: you just mount it read-only at the last phases of system shutdown. Likewise, RHEL5 /etc/mtab seems to be missing the entry for the /dev filesystem... but it's a RAM-based filesystem, so there is no point in unmounting it either, and having it not mentioned in regular /etc/mtab offers a small extra measure of protection against accidentally unmounting it.

The man page of the "mount" command on a RHEL5 system (which is what the original poster has) has this to say about /etc/mtab and /proc/mounts:

When  the  proc  filesystem is mounted (say at /proc), the files
/etc/mtab and /proc/mounts have very similar contents. The  for‐
mer  has  somewhat  more  information, such as the mount options
used, but is not  necessarily  up-to-date  (cf.  the  -n  option
below).  It  is possible to replace /etc/mtab by a symbolic link
to /proc/mounts, and especially when you have very large numbers
of mounts things will be much faster with that symlink, but some
information is lost that way, and in particular using the "user"
option will fail.

Replacing /etc/mtab with a symlink to /proc/mounts is a valid technique if you want to keep the root filesystem read-only in normal use. This is often used in building embedded systems designed to run off a single CompactFlash module, when you wish to minimize the number of CompactFlash write operations.