Ext3 warnings on a loop device
After one of our servers went on a fsck loop after several EXT3 kernel messages new EXT3 messages have appeared /var/log/messages
I do not know how to interpret these error messages
The server is RHEL EL 3 and is running the latest version of Cpanel current.
The server has been up 60 days.
The fact that /etc/fstab has loop in the /tmp partition settings could indicate that the problem is with that partition. I have no idea what the loop parameter implies in a partition. It is probably unnecessary.
I do not understand these Ext3 warnings.
This seems to be a very bizarre setup. Why loopback mount a device node? And why mount the same device node in two places? What may be happening is that a file is being deleted from (e.g.) /tmp and the message occurs when /var/tmp realizes the file is no longer there. As /tmp and /var/tmp don't need to be loopback mounted I would suggest removing the loop option. Also only mount one (e.g. /tmp) and have the other as a symlink to /tmp. If for some reason symlinks aren't acceptable then use mount to bind /tmp to /var/tmp ("mount --bind /tmp /var/tmp"). This seems much saner to me and will also inform the kernel as to what you are doing as opposed to the present situation where it works but looks bizarre from kernel space. Of course this is RHEL and this may be some extremely clever trick on their part but this is what I would do if faced with your situation. Hope this helps.
Mounting as loop
This is a common practice among cPanel servers, basically to add the noexec and nosuid bits to the /tmp and /var/tmp directories without repartitioning to give them their own mount points to help slow down script kiddies from placing flood scripts on the servers through insecure PHP/CGI scripts.
I've implemented this on a box where we were also seeing the issue. The strange thing is, is we have this setup on numerous machines, and the only ones this appears to be an issue on are ones using ADAPTEC 2110S scsci cards. It's a 2.4 kernel (in our case, Fedora's 2.4.22-1.2199.nptlsmp kernel, with the dpt_i2o module).
Thank you for the suggestion of using --bind. I'm sure it will come in handy :)
Anybody see a correlation here, or come across this in their journey's?
|All times are GMT -5. The time now is 12:50 PM.|