/ is at 100%
 

How do I find on / what is specifically taking up the space? I've got 100% on / but not sure where the culprit is. I take it everything else not listed below such as /etc, /sbin etc. fall under / partition. Is there a way to extract where in root the problem is maybe using df?


I have mounted

/dev/mapper/VolGroup00-rootVol / is 100%
/dev/mapper/VolGroup00-tmpVol /tmp is 4%
/dev/mapper/VolGroup00-optVol /opt is 3%
/dev/mapper/VolGroup00-homeVol /home is 22%
/dev/mapper/VolGroup00-varVol /var is 10 %
/dev/mapper/VolGroup00-auditVol /var/log/audit is 5%
/dev/cciss/c0d0p1 /boot is 11%
/dev/cciss/c0d1p1 /export is 2%
tmpfs /dvm/shm 0%

You can use du to view the disk usage for /.

hi, with df you're almost there : "du" gives you directory sizes
I suggest using "du -h" for human readable output.

Serafean

Type thisin terminal and it will show you which folder is which size. From there you can go on with the du command to find the culprit.

I just found where my issue is. I used du -hs * . I have a script that runs that mounts /mnt/dump to a windows share. Backup files are tarred and zipped at that mount point than the mount is umounted afterwards. The windows server than has a script that once the files are backed up to tape they are supposed to be moved to a storage directory. So /mnt/dump was the culprit, the backup files are still sitting there.

I guess I'm not understanding the concept. When /mnt/dump is mounted to the windows share it's not essentially placing those files on that Windows share (file system)? So aren't they now on the windows server at that point and it's OK to unmount /mnt/dump?

The problem here is that while /mnt/dump is a mount-point,
it's also a local directory; if, for some reason, the remote
machine is unreachable and the mount fails, you're writing
to your local disk (which is why you filled / up).

So no, the files never made it to your windows share.



Cheers,
Tink

That's why I'm asking the question, to help me understand what I'm doing wrong. I'm not looking for you to do my job for me. The work I am doing myself, being a Linux newbie I do need help once in a while. I'm trying to picture the /mnt/dump and windows share relation. What I was trying to understand is the files are not actually on the windows server but still on the linux server in /mnt/dump. (OK so /mnt/dump is a local directory).

If I run the script by itself the process of backing up the files to the windows share works. /mnt/dump is mounted, the files are tar,zipped and placed there. I can then go to the windows share and the files are there.

But the cron job I set up in the evenings seems to partialy work because as I found out today the files were still on /mnt/dump but not on the windows server were I ultimately wanted them.

Another cron job I have set to run later is to unmount /mnt/dump because I don't want the shared connection permanent. This is probably where I'm messing up. My thinking was that by placing the files on /mnt/dump they were actually being placed on the windows server so unmounting /mnt/dump would be OK. So what I'm looking for is for the files to be on the windows server after /mnt/dump is umounted from the windows share.

Just a side note: my signature is generic, not coined towards
your post/thread.

So how do you go about the mounting from the command-line,
what does it look like in the cron job? In cron, do you
redirect output to /dev/null, are you setting cron to mail
you the results? If the latter - are there any errors in
the mails you receive? What does the cron daemon say in
/var/log/{message,debug,...}?


Cheers,
Tink

OK no problem. I have to leave now but I will add the scripts I'm running and logs tomorrow.

Tinkster,

Sorry I've been out for a few days. It appears you were right earlier. It doesn't seem like the mount cron job is running so that's why the files sit in /mnt/dump . Like I said the script works when it's ran manually. What's strange is the cron log indicates it as being run. The cron job is setup as,

30 23 * * 1-5 /opt/temp/scripts/hostname_dumpsharedcmd_conv.pl >> /opt/temp/logs/mount.log
45 23 * * 1-5 /opt/temp/scripts/hostname_umount_dumpsharedcmd.pl >> /opt/temp/logs/umount.log

I have changed the mount to run every minute just to test.

*/1 * * * * /opt/temp/scripts/hostname_dumpsharedcmd_conv.pl >> /opt/temp/logs/mount.log

I even totally deleted the mount job line and typed it back in just in case there was something wrong in that line. It should have indicators in it that say if it is or it's not mounted. The mount log always indicated it cannot mount and the umount log file always indicates that /mnt/dump is not mounted.

The cron log says,

Oct 1 23:30:01 hostname crond[13002]: (root) CMD (/opt/temp/scripts/hostname_dumpsharedcmd_conv.pl >> /opt/temp/logs/mount.log)
Oct 1 23:45:01 hostname crond[13065]: (root) CMD (/opt/temp/scripts/hostname_umount_dumpsharedcmd.pl >> /opt/temp/logs/umount.log)

The file permissions for /opt/temp/scripts/hostname_dumpsharedcmd_conv.pl are
-rwx------ root root

- Is there anything I could be missing? I have other jobs that run OK it's just this mount job that will not run properly. It tries to mount but just won't do it. My cronjob does send to it's log file. In my log files I get,

/opt/temp/logs/mount.log says,

/mnt/dump is NOT mounted!
Mounting /mnt/dump....

First try mount /mnt/dump NOT successful!
SHARE may be down!

Trying unmounting /mnt/dump
Second Try: mounting /mnt/dump...
Second mount try /mnt/dump NOT successfull!
SHARE may be down!
Try next time.

My /opt/temp/logs/umount.log says,

/mnt/dump wasn't mounted.

If I manually run the mount script so /mnt/dump is mounted, the mount log does update and says,

/mnt/dump is already mounted.

I do have two other files in this mounting scheme and I'm wondering if cron is having a problem with them.

--------------------------------
Check if mapped if not than map
--------------------------------
#!/usr/bin/perl
print `date`;

$ismounted = `df -h |awk '{ print $1 }'|grep ShareName`;
chomp ($ismounted)
unless ($ismounted =~ /ShareName/) {

print "/mnt/dump is NOT mounted!\n";
print "Mounting /mnt/dump...\n";
`/opt/temp/scripts/xxxx_dumpsharedcmd_conv.exp`;
} else {
print "/mnt/dump is already mounted.\n";
exit;
}

#Double Check
$ismounted = `df -h |awk '{ print $1 }'|grep ShareName`;
chomp ($ismounted)
unless ($ismounted =~ /ShareName/) {
print "First try /mnt/dump was NOT successful!\n";
print "Share may be down!\n";
#Try unmounting - sometimes it has to be unmounted first
print "Trying unmounting /mnt/dump...\n";
`umount /mnt/dump`;
print "Second try: Mounting /mnt/dump...\n";
`/opt/temp/scripts/xxxx_dumpsharedcmd_conv.exp`;
} else {
print "\nSuccessful! - /mnt/dump is now mounted.\n";
exit;
}

#Triple Check
$ismounted = `df -h |awk '{ print $1 }'|grep ShareName`;
chomp ($ismounted)
unless ($ismounted =~ /ShareName/) {
print "Second try /mnt/dump was NOT successful!\n";
print "Share may be down! \nTry next time.\n";
} else {
print "\nSuccessful! - /mnt/dump is now mounted.\n";
exit;
}
exit;

-----------------------------------------------------
This is the mapping script called in the script above
-----------------------------------------------------

#xxxx_dumpsharecmd_conv.exp
#!/usr/bin/expect

set timeout 20

#set password xxxxxxxxxxx

spawn mount -t cifs //xxx.xxx.xxx.xxx/ShareName/Hostname /mnt/dump -o username=xxxxxx,credentials=dump_cred,iocharset=utf8
,file_mode=0777,dir_mode=0777

#expect "Password:"
#send "$password\r"

expect eof

No worries re the delay; I'm no good with expect, I'm afraid,
but what are the chances of "mount" not being in the PATH in
crons environment?

And another suggestion: instead of using expect from within
perl to do the mount, why don't you use a hidden file to store
the credentials and mount it from perl? Surely it's no harder for
anyone to read the script with the password in it than it would
be to find the credentials file, but it would take one level
of complexity out of the equation.

Actually ... just looked at your scripts again: if you're using a
credentials file already - why did you bother with expect?



Cheers,
Tink

I suspected the problem had to do with this file below, the one that does the mount and uses the credentials file. I started to look into cron and expect and there were a few issues people were having out there but that wasn't it. All these files are in the same location and I assumed since they all work when ran manually that wouldn't be a problem but that was the problem. in the "credentials=dump_cred" section below the full path needed to be there so it had to look like credentials=/opt/temp/scripts/dump_cred. Once that was put there it worked.

#xxxx_dumpsharecmd_conv.exp
#!/usr/bin/expect

set timeout 20

#set password xxxxxxxxxxx

spawn mount -t cifs //xxx.xxx.xxx.xxx/ShareName/Hostname /mnt/dump -o username=xxxxxx,credentials=dump_cred,iocharset=utf8
,file_mode=0777,dir_mode=0777

#expect "Password:"
#send "$password\r"

expect eof

Thanks for your help. Your help made me look in places I wouldn't normally look.