We have SCO Unix (realease 5.0.5b),
Please advise which files can be safely deleted on the system root folder / to create space? These are mainly spool/message/history etc log files. Where they located and can they be deleted using rm?
The server has been operational for the past 4 years.
Thanks.
Truncate the following files:
/usr/adm/messages
/usr/adm/syslog
/usr/spool/lp/logs/requests
/usr/spool/mail/root
/usr/spool/mail/cron
Do this by:
cat >file <cr>
<ctrl-d><cr>
remove all of the following:
core
Run the following from /
du -a |sort -r -n >/u/file.list
The output of this is a list of the files and directories on the entire system sorted in descending order by size. Using this you should be able to find files that you didn't know existed (inadvertently saved in the wrong directory), and which files are growing (have a recent file date).
Thanks jgt.
I didnt quite understand the cat. Please give example like on /usr/adm/messages or /usr/adm/syslog.
Regards.
do the following as root
#cd /usr/adm
#cat > messages
type a <ctrl-d> followed by a carriage return
#
the effect of this is to create a file called messages with the same attributes as the original, but with a size of zero bytes.
The MS-DOS version of this is:
c:>copy con messages
<ctrl-z>
c:>
Thanks jgt your a star.
The /usr/spool/mail/root was huge.
Using du -s * in /var:-
size before cat - 62224 and after - 59510
But I couldn't find /usr/spool/mail/cron??
On monitoring seems like the /var/opt & /var/spool folders are growing.
Are there any other files I can truncate/delete within these? What about the /tmp folder can I rm ALL files/folders in it??
Can cat be done on a link or do I have to go to actual folder/file to execute (scared to experiment)?
Regards...
/var/spool is a link of /usr/spool, email and print files are all temporarily stored below this directory.
/var/opt is the location of the operating system files, /usr/bin /bin /etc are all links to something within /var/opt.
You should, by definition, be able to delete all the files in /tmp, and, in fact, in SCO 6.0.0 and Unixware, /tmp can be a ramdrive...but, I would make a copy of it, say "tar ctvf /u/tmp.tar /tmp" before deleting it the first time.
There are hard links, and soft(symbolic) links. There is no way to tell which is the original and which is the link with a hard link, so deleting one will delete both.
With soft links, the original file will still exist if the link (newer file) is deleted. See "man ln".
It doesn't matter which file name you use to truncate the file.
/usr/spool/mail/cron will only exist if you have cron jobs (typically scheduled overnight batch jobs) running.
If you are using mail on this system, you should move all the contents of /usr/spool/mail to /u/spool/mail, and then edit /usr/mmdf/mmdftailor and change the location of the spool files accordingly. Doing this will prevent someone from filling the root file system with email messages.
Hi,
Can I safely cat wtmp, utmp, wtmpx, utmpx & lastlog without causing any log-in/system problems as these files are growing?
My tmp is filling up only over week-end (Sunday). I have been monitoring durring the week and /tmp/ does not change in size; its only on Sunday.
The HUGE file being created is CroutSHBa0004R. This contains lines :-
var/opt/K/SCO/Unix/5.0.5Eb/etc/default/filesys does not exit
var/opt/K/SCO/Unix/5.0.5Eb/etc/default/format does not exit
var/opt/K/SCO/Unix/5.0.5Eb/etc/default/goodpw does not exit
var/opt/K/SCO/Unix/5.0.5Eb/etc/default/login does not exit
etc
etc
etc
I don't understand as these files do exist.
Looking into the crontab file, the jobs that run on Sunday are:-
17 5 * * 0 /etc/cleanup > /dev/null
0 2 * * 0,4 /usr/lib/cron/logchecker
0 4 * * 0 /etc/custom -V syslinks;# CUSTOM_SYMLINK_REPORT
Thanks
Yes, but do it in single user mode. These files contain the data used by the 'who' and 'w' commands.
Is the root file system mounted? I know this sounds like an impossibility, but it is not.
Run divvy in order to list all the file systems on drive 0.
Run df -v and see if all file systems are accounted for.
In /etc/default run 'ls -li login' and see if the link to /var/opt/K still exists.
My belief is that the root file system has become corrupted as a result of running out of disk space.
Hi,
Please tell me how to run divvy for this?
Yes df -v show all filesystems:-
/ 33 (% Used)
/stand 55
/zlt 4
/back 4
/run 9
The 'ls li login' in /etc/defaults link exists for '/var/opt/K'.
I noticed that when i exec 'find / -name othman.rpt -print' as root I get screen-full of messages as in the Crout file ie 'var/opt/....../etc/default/filename does not exist. Surely this shouldn't happen??? Isn't this the problem as /usr/lib/cleantmp also does a find (not sure of other sys crons)? The cleantmp is run everyday at 3 3 but doesn't cause problems durring the week but maybe runs differently over week-end (due to file ageing I think)?? There are 0 size crout files everyday at 3 3 in /tmp.
This is very puzzling!!!
Thanks
'divvy' accesses the boot drive when used with no options.
Do not change anything, just note all the file systems and exit.
Run 'scoadmin', and choose 'software manager' then 'software' then 'verify system' then run once for each variation.
Run 'integrity -e' and correct permissions and ownership until there is no output.
------------------+------------+--------+---+-------------+------------
| Name | Type | New FS | # | First Block | Last Block |
+-------------------+------------+--------+---+-------------+------------
| boot | EAFS | no | 0 | 0| 15359|
| swap | NON FS | no | 1 | 15360| 108543|
| root | HTFS | no | 2 | 108544| 1527928|
| zlt | HTFS | no | 3 | 1527940| 8867972|
| back | HTFS | no | 4 | 8867990| 16208022|
| run | HTFS | no | 5 | 16208050| 18305202|
| recover | NON FS | no | 6 | 1527929| 1527938|
| hd0a | WHOLE DISK | no | 7 | 0| 19550631|
+-------------------+------------+--------+---+-------------+------------
19542600 1K blocks for divisions, 8032 1K blocks reserved for the system
/var/opt/K/SCO/Unix/5.0.5Eb/etc/default/cleantmp (wildcard entry 79) is wrong.
Owner is root, should be bin.
Group is sys, should be bin.
Mode is 0664, should be 0644.
Type is FIFO (f), should be regular file (r).
/var/opt/K/SCO/Unix/5.0.5Eb/etc/default/codeset (wildcard entry 79) is wrong.
Owner is root, should be bin.
Group is root, should be bin.
/var/opt/K/SCO/Unix/5.0.5Eb/etc/default/cron (wildcard entry 79) is wrong.
Owner is root, should be bin.
Group is sys, should be bin.
Mode is 0755, should be 0644.
Type is directory (d), should be regular file (r)
I can change the owner, group & mode but not sure how to change filetype?
The actual files don't seem right. I did an ls of the folder (below) ie problem files & few others. Please note the dates, cleantmp is 0 size, cron is a folder. Should these be like this??
Not sure how this happened. Could manualy running 'cron' ie without any arguments the lastime cause this?? Whats the FIFO file in the /usr/lib/cron folder for? Seems like its regulary changing date/time but noted on solaris (localy Zimbabwe) in /etc/cron.d its static but we also run cron jobs here?
rw-r--r-- 1 bin bin 795 Mar 21 2000 Stp
-rw-r--r-- 1 bin bin 2336 Mar 21 2000 archive
-rw-r--r-- 1 bin bin 3629 Mar 21 2000 authsh
-rw-r--r-- 1 bin bin 631 Mar 21 2000 backup
-rw-r--r-- 1 bin bin 829 Mar 21 2000 boot
prw-r--r-- 1 bin bin 0 May 14 13:39 cleantmp
-rw-r--r-- 1 bin bin 4 Jun 4 08:04 codeset
drwxr-xr-x 2 root sys 512 May 4 13:24 cron
-rw-r--r-- 1 bin bin 2641 Mar 21 2000 device.tab
-rw-r--r-- 1 bin bin 617 Mar 21 2000 dumpdir
-rw-r--r-- 1 bin bin 1225 May 15 18:09 filesys
-rw-r--r-- 1 bin bin 649 Mar 21 2000 format
-rw-r--r-- 1 bin bin 984 Mar 21 2000 goodpw
-rw-r--r-- 1 bin bin 626 Mar 21 2000 idleout
-rw-r--r-- 1 bin bin 1228 Mar 21 2000 issue
-rw-r--r-- 1 bin bin 437 Mar 21 2000 lang
Thanks.
Lets answer the easy one first. You do not have to be in single user mode to run scoadmin, or any of its sub menus.
The four files that you highlighted in the list are all simple text files.
The filesys file would change if you had changed the file system mount points,
or had run mkdev fs (filesystems option in scoadmin).
The other files would likely not have changed since the original installation.
The FIFO file is normal in /usr/lib/cron.
For cleantmp, codeset, and cron, do you have a backup prior to May 29, that you can restore these files from.
-rw-r--r-- 1 bin bin 656 Sep 29 2000 cleantmp@
-rw-r--r-- 1 bin bin 1244 Sep 29 2000 codeset@
-rw-r--r-- 1 bin bin 915 Sep 29 2000 cron@
-rw-r--r-- 1 bin bin 1302 Mar 20 2003 filesys@
If you don't have a backup, send me an email, and I will forward them to you.
Filesys is probably correct, otherwise the non root file systems would not mount properly when the system is booted.
Codeset contains the default info for which character set is used.
Cleantmp contains a list of directories to be purged
Cron contains a list of log size defaults for cron
Hi jgt,
Unfortunately, I don't have a backup of the system.
Please advise how I can get your email addr; as your profile prevents me from emailing you.
Thanks.
Changed my profile to allow email.
Jack
Thanks for the files. Managed to copy cleantmp & codeset. Having problems with removing the invalid cron folder. I emptied its contents.
Problems:
'integrity -e' now only complains of the cron folder.
Try
rmdir cron
If that complains that it is not empty,
cd cron
rm *
cd ..
and try again.
Also see if
ls -li cron
returns a link to another file, then try deleting it instead.
Is the system now running more or less normally?
Not sure why i am redirected to this folder as the cron is not a link and properties are 'drw-r--r--' . What exactly is '/dev/ttypdir'??
The system is ok (Mon-Sat) but Sunday the /tmp got the huge crout file and fills up /root. It haapened again this last Sunday. I am sure it will happen again this Sunday since 'find /' not working.
I checked a 5.0.5 system, and it has no file/directory named ttypdir.
If you haven't created your own jobs, the only job that would be run on Sunday (on the system that I checked) is /etc/cleanup. Disable it in /usr/spool/cron/crontabs/root.
Then at least the system will not go down again. All that this job does is truncate some log files, and does a 'find' in order to remove any 'core' files more than 7 days old.
Have you tried removing 'cron' from within /var/opt/K/SCO/Unix/5.0.5Eb/etc/default, as opposed to /etc/default ?
It may be time to re-install the operating system.