SCO Openserver 5

[FLAdmin]

First of all I'm a windows admin with just enough knowledge to get me around Unix a bit for small things. However we run our main application wich is FoxPro for Unix based.

The problem we have is Intermittent Hangs to the point where it takes about 1-2 minutes to see any kind of screen update. My only solution has been rebooting the machine unfortunately. I wish I could give more information but if anyone can point me in the right direction I would be happy.

I would like to know also how to do a chkdsk equivalent type command to check for bad sectors on the disk without harming any data.

Also does this thing have any simple path or order to start troubleshooting, maybe a log? and is there any gotchas to watch out for that are worth knowing. thanks

This Machine is: (incredibly)
3.6 Gz P4
1GB RAM
HD, unsure. I believe 2, one for backups.

 

[motoslide]

Logs: /usr/adm/messages and /usr/adm/syslog
These can get long, so you may try looking at each with the "tail" command right after you notice a problem.

"fsck" is similar to chkdsk.
# man fsck (for instructions)

If you had any bad sectors, there would be entries in /usr/adm/syslog.

That sounds like new hardware. Which version of OpenServer are you running?
# uname -X

When the system is "hung", is the console also unresponsive?

You can run a command like this to help determine which process is hogging the CPU when the performance is poor:

ps -e -o "pcpu" -o "pid=" -o "time" -o "user=" -o "args=" |
awk '$1 > 5' |
sort -r -n

 

[edfair]

badtrack or scsibadblk do some scans

to see what you have for hard drives: l /dev/hd* (l/c L)

to see how the drives are set up

divvy /dev/hd0x or /dev/hd1x (use 1 point from previous)

to see what you have for filesystems

df -k -v

for info on any of these man command

Ed Fair
Give the wrong symptoms, get the wrong solutions.

 

[stanhubble]

you should also find out what version of OS you are running.

uname -v
uname -X will give you more information.

if it is not at least 5.0.6a then really need to update it,
P4's and anything prior to 5.0.6a don't get along very well.

sar will tell you where the bottlenecks could be.

 

[cdlvj]

>>>if it is not at least 5.0.6a then really need to update it, P4's and anything prior to 5.0.6a don't get along very well.

Those versions do not support hyperthreading, and probably is the root of your problem

 

[FLAdmin]

Thanks guys, great help. so far this is what I got. maybe you'll sniff something funny out of it.

System = SCO_SV
Node = sco
Release = 3.2v5.0.6
KernelID = 2000-07-27
Machine = Pent4
BusType = ISA
Serial = 2DJ031060
Users = 105-user
OEM# = 0
Origin# = 1
NumCPU = 1

brw------- 1 sysinfo sysinfo 1, 0 Sep 5 2004 /dev/hd00
brw------- 1 sysinfo sysinfo 1, 15 Sep 5 2004 /dev/hd01
brw------- 1 sysinfo sysinfo 1, 23 Sep 5 2004 /dev/hd02
brw------- 1 sysinfo sysinfo 1, 31 Sep 5 2004 /dev/hd03
brw------- 1 sysinfo sysinfo 1, 39 Sep 5 2004 /dev/hd04
brw------- 1 sysinfo sysinfo 1, 47 Sep 5 2004 /dev/hd0a
brw-r----- 1 dos sysinfo 1, 48 Sep 5 2004 /dev/hd0d
brw------- 1 sysinfo sysinfo 1, 64 Sep 5 2004 /dev/hd10
brw------- 1 sysinfo sysinfo 1, 79 Sep 5 2004 /dev/hd11
brw------- 1 sysinfo sysinfo 1, 87 Sep 5 2004 /dev/hd12
brw------- 1 sysinfo sysinfo 1, 95 Sep 5 2004 /dev/hd13
brw------- 1 sysinfo sysinfo 1,103 Sep 5 2004 /dev/hd14
brw------- 1 sysinfo sysinfo 1,111 Sep 5 2004 /dev/hd1a
brw-r----- 1 dos sysinfo 1,112 Sep 5 2004 /dev/hd1d

LIVE # /ivvy /dev/hd01
+-------------------+------------+--------+---+-------------+------------+
| Name | Type | New FS | # | First Block | Last Block |
+-------------------+------------+--------+---+-------------+------------+
| | EAFS | no | 0 | 0| 20479|
| | NON FS | no | 1 | 20480| 806911|
| | HTFS | no | 2 | 806912| 8938495|
| (label = tmpinv) | DTFS | no | 3 | 8938496| 14058495|
| | DTFS | no | 4 | 14058496| 30441461|
| | HTFS | no | 5 | 30441462| 35561461|
| | NON FS | no | 6 | 35561462| 35561471|
| hd01 | WHOLE DISK | no | 7 | 0| 35564527|
+-------------------+------------+--------+---+-------------+------------+
35561472 1K blocks for divisions, 3056 1K blocks reserved for the system


LIVE # divvy /dev/hd00
+-------------------+------------+--------+---+-------------+------------+
| Name | Type | New FS | # | First Block | Last Block |
+-------------------+------------+--------+---+-------------+------------+
| boot | EAFS | no | 0 | 0| 20479|
| swap | NON FS | no | 1 | 20480| 806911|
| root | HTFS | no | 2 | 806912| 8938495|
| tmpinv | DTFS | no | 3 | 8938496| 14058495|
| user2 | DTFS | no | 4 | 14058496| 30441461|
| tmp | HTFS | no | 5 | 30441462| 35561461|
| recover | NON FS | no | 6 | 35561462| 35561471|
| hd0a | WHOLE DISK | no | 7 | 0| 35564527|
+-------------------+------------+--------+---+-------------+------------+
35561472 1K blocks for divisions, 3056 1K blocks reserved for the system



50.09 457 00:00:03 root /usr/unform60/rt/pvx /usr/unform60/uflist.pv -
arg start
18.59 2959 00:00:00 bernie /usr/lib/foxpro/foxr.pr -t -i -o -e selcompx
7.55 206 00:00:02 root htepi_daemon /tmp

 

[FLAdmin]

Mount Dir Filesystem blocks used free %used
/ /dev/root 8131584 3221991 4909593 40%
/stand /dev/boot 20480 11950 8530 59%
/tmpinv /dev/tmpinv 5120000 3931808 1188192 77%
/user2 /dev/user2 16382966 13307310 3075656 82%
/tmp /dev/tmp 5120000 179608 4940392 4%
/usr2 /dev/usr2 32489472 26843477 5645995 83%
/usr3 /dev/usr3 3072000 1134574 1937426 37%
/josedsk lx:/home/public/PERF 47968136 37042640 10925496 78%
/usr/archi lx:/home/public/arch 47968136 37042640 10925496 78%

 

[motoslide]

Your Unform process shouldn't be hogging all the CPU like that. It's a quick form-generating utility. This will, of course, consume CPU time while it is processing, but that should be short-term. See if it continues to be at the top of that list. You can enable debugging in Unform 6 if it proves to be the issue. My guess is that you just happened to run that PS command while it was active.

Check that you have the recommended patches for that 5.0.6 O/S. As mentioned by others, there are compatibility issues with the P4. To the extent, (I've heard, but never seen) that it can cause the P4 to fail.
To see the O/S patches, run "custom".

 

[motoslide]

Also, those last two filesystem entries are NFS-mounted filesystems (right?). See if you can determine their purpose, and also see if there are files being modified or copied to/from those areas while the system is sluggish.

 

[FLAdmin]

Here's whats in Custom:

3Com EtherLink PCI (ver 5.0.6b)
Bash - GNU Bourne-Again SHell (ver 2.03)
Broadcom BCM5700 NetXtreme Gigabit Ethernet (ver 5.0.7d)
Bzip2 - block-sorting file compressor/uncompressor (ver 0.9.5d)
DB - the Berkeley Database Library (ver 1.85.4)
Expect - programmed dialogue (ver 5.30)
FSU Pthreads (ver 3.5)
GCC - GNU Compiler Collection (ver 2.95.2pl1)
GNU Ghostscript, a PostScript and PDF interpreter (ver 6.51)
GNU Libtool, a generic library support script (ver 1.3.5)
GNU Privacy Guard (ver 1.2.4)
Groff - GNU nroff, troff and related tools (ver 1.15)
LDAP - Lightweight Directory Access Protocol (ver 3.3)
Lxrun - Linux Application Environment Emulator (ver 0.9.4pre3)
OSS631B - Supplemental Graphics, Web and X11 Libraries (ver 1.2.1)
OpenSSH - secure shell client/server (ver 3.1p1)
PRNGD - Pseudo Random Number Generator Daemon (ver 0.9.23)
Pacific CodeWorks, Inc. Olympus TuneUp (ver 6.0.0P)
Qpopper - POP3 protocol server (ver 3.1)
Redhat Package Manager (ver 4.0.4)
SCO OpenServer Enterprise System (ver 5.0.6j)
SCO SendMail (ver 8.11.0)
SCO Skunkware 2000 (ver 2000.1)
zlib - unencumbered lossless data-compression library (ver 1.1.4)
OSS638A: rarpd Supplement for OpenServer 5 (ver 1.0.0)
OSS640A: BIND Update (ver 1.0.0)
OSS642a - Cron supplement (ver 1.0.0)
OSS643A: Socket Driver Supplement for OpenServer 5 (ver 1.0.0)
OSS644B - Reboot supplement for OpenServer 5 (ver 1.0.0)
OSS645A: Audit Subsystem Security Supplement (ver 1.0.0)
OSS646B - Execution Environment Supplement (ver 1.1.0j)
OSS646C - Execution Environment Supplement (ver 1.2.0a)
OSS648A: Processor Supplement for OpenServer 5.0.6 (ver 1.0.0)
OSS650a - lpd supplement (ver 1.0.0)
OSS651A: Intel Microcode Update for OpenServer 5.0.6 (ver 1.0.0)
OSS660A - getty Supplement for OpenServer 5.0.6 (ver 1.0.0)
OSS663A - LPD Supplement for OSS646 (ver 1.0.0)
RS506A: Release Supplement for SCO OpenServer Release 5.0.6 (ver rs
RS506A: Software Manager Supplement (ver rs506a)

 

[FLAdmin]

As for the NFS Drives, If I'm not mistaken... I think they are the windows friendly shares we have. because we do share the entire set of tables for the foxpro database in order to run a windows based fox pro app that we are developing as well. However I have been trying to import data with SQL, I considered this. but even after shutting down sql it was sluggish. for now mysteriously its fast again after a hard boot that made a disk checking come up at boot.

 

[FLAdmin]

The system is slow now:

54.84 2 00:00:06 root vhand
12.41 2712 00:00:20 erika /usr/lib/foxpro/foxpro.pr -t -i -o -e selcomp
x
8.05 6466 00:00:00 erika mv 1115_HELLECOMFO_F-92834_060307_AHARON_SHA /
tmpinv/pdfinv-hist

 

[FLAdmin]

Also at the Console:

Table_Grow excecdata table page limit of 50 pages(MAXEXECARGS) Exceeded by 1 pages

 

[FLAdmin]

heres another snapshot:
25.80 9604 00:00:34 jose popper
22.28 2 00:00:21 root vhand
15.08 9710 00:00:01 root /usr/lib/foxpro/foxpro.pr -t -i -o -e selcomp
x
6.90 199 00:00:05 root dtdaemon
5.38 18974 00:00:55 vanessa /usr/lib/foxpro/foxpro.pr -t -i -o -e selcomp
x

 

[motoslide]

Make sure there exists a mailbox for any PC's which are configured to check for mail using the POP3 daemon (popper). If you do not have a corresponding file in /usr/spool/mail, then popper gets very cranky. I think it is generating the console messages.

You can create those files using the "touch" and "chown" commands:
# cd/usr/spool/mail
# touch user1
# chown user1 user1
# chmod 600 user1
(repeat as needed for the other users)

 

[FLAdmin]

there is only less than 10 office people that use it to check mail, wich are there. there is also about a hundred or so for other users wich are not being used.

 

[motoslide]

Are any of the mailbox files extremely large?
When a PC checks for Email, it will launch the popper daemon, which will start by creating a copy of the user's mailbox file, then transfer tne contents of the copy to the User's Email program. Once that has been accomplished, it will copy the file back to the original name. If the file is large (Megabytes), you could have a delay. You've got new hardware, so disk I/O should be extremely fast.

Before getting too worked up, you will need to see if there is a direct correlation between the processes which are active while the system is noticeably slow.

 

[FLAdmin]

Here's the top bunch. they dont seem all that large.. 3mb? if thats correct

Size
2838531 Mar 7 13:23 root
2180044 Nov 24 13:23 marcelo
2131948 Dec 16 19:10 michelle
1389424 172 Mar 7 13 jose
1161297 Nov 14 2003 kristina
862117 Nov 28 11:19 terre
834011 May 2 2003 xfer
819592 Sep 27 2004 jeff
784361 Apr 17 2003 jessica
765960 Dec 21 11:21 alex
746549 Apr 17 2003 irene
723066 Apr 28 2003 info
718852 Jan 26 12:34 mary
718771 Jan 27 2004 linda
718567 Apr 25 2003 larry

 

[FLAdmin]

You guys mentioned updating to 605a. Does Unix have some kind of auto update from ftp tool or anything?

and more importantly can they impact the FoxPro for Unix application?

 

[stanhubble]

also see if it is cpu io or memory that the system is busy with.

sar 5 5

sar -r 5 5