/dev/root??? Strange

[Christopher McCray_1]

I have done some digging; nothing that really answered my question in full, so I am turning to you, my HP-UX brothers and sisters.

Here is an exerpt of my syslog.log:

Dec 3 08:17:49 dmc49 vmunix: vxfs: mesg 001: vx_nospace - /dev/root file system full (1 block
extent)


I assume this is referring to /, but bdf shows it as only 41%, as well as being mounted to /dev/vg00/lvol1. I had no backups that could have been mistakenly sent to /, either. So, with all this being said, what type of gremlins are running amuck in my server and how do I kill them?? Or is there nothing to worry about?

Thank you all in advance. Chris

[Ian Dennison_1]

Is / mounted on /dev/root (or at least shown as such on a bdf?). And is it 100% full?

Are we dealing with an issue of totally wrong syslog messages, or of incorrect mount points?

Share and enjoy! Ian

[Tom Geudens]

Hi,
- /dev/root is indeed /
- The message should be frequent in syslog,
if not the problem has resolved itself
- I would look at directories directly under
/ (thus in the same filesystem) that are
accessable to users other than root.
Probably somebody filled it up ... noticed
the mistake and cleared the file.
- There should be no directories in the
/ filesystem that can be filled up by
others than root.
- It is also possible that there was a core
file in the / directory that has been
removed by an "automatic" clean job (from
crontab for example).

Regards,
Tom

[Robin Wakefield]

Hi Chris,

Obviously whatever process was writing to the filesystem received the error, releasing the space. Is there anything either side of this in the syslog, an ftp connection perhaps? Anything in the cron log that ended around the same time?

Also, / is normally lvol3, /stand is lvol1.

Rgds, Robin.

[Darrell Allen]

Hi Chris,

I think you'll find from other threads that / often gets mounted on /dev/root after booting into maintenance mode. I've seen several threads recently about that.

Was the system booted yesterday (or recently) and particularly, was it booted into maintenance mode? Perhaps it had been awhile back and just yesterday had a problem.

Darrell

[Sanjay_6]

Hi Christopher,

Try to recreate the mnttab file. To do that, move /etc/mnttab out of way and run mount -a to recreate the correct mnttab with /dev/vg00/lvol? mounted to / .

Hope this helps.

Regds

[Christopher McCray_1]

Okay, I shall now try to answer all questions posed:

/ is indeed mounted on /dev/vg00/lvol3 (I stand corrected, Robin)

The problem only occurred a couple of times yesterday morning and has not returned.

There was only a couple of cron jobs that kicked off during that time, but one was a sar job and the other sent it's output to elm.

Finally (??) There were only a couple of users that were logged on at the time, but there is no evidence that they even wrote anything to /. This directory is very restrictive, anyway and users are limited to only a handful of filesystems.

Thank you all for trying to jar my brain. Please, If you have anything els you can have me look at, please let me know. This is annoying to say the least.

[Christopher McCray_1]

Darren,
The server had been up for 9 days at the time.

Sanjay,
The mnttab looks fine as does bdf. I am dealing with some weird occurrance where something decided to access/write(?) to /dev/root instead of /dev/vg00/lvol3. Any other ideas??

Thanks, guys, for all your continued help.

[Marilyn DuChene]

I had a similiar problem where an app had created a /xxtemp directory on the root. Whenever certain tasks were run it would fill up the root file system momentairly. I would look at all the directories under root and see if anything looks like it shouldn't be there.

[Christopher McCray_1]

Good thought, Marilyn, but I had already checked that possibility, all directories are mountpoints for filesystems, except for /rootdir, which is fine and a user data directory, which is empty. If you all can think of anything else, please come forward.

Chris