adnan@sgtech.UUCP (Adnan Yaqub) (05/15/89)
Our Intel 386 box with Xenix 2.3.1 has a problem, and it is probably one we have inflicted on ourselves. After the system is rebooted and has been running for a while (hours, not days), the ps command stops working. For diagnostics, it says ps: seek error Usually I get a few lines of status before it dies. I believe the problem is caused by a bug in an in-house terminal driver. If I could find out why ps's seek is failing, I may be able to fix the driver. However, we don't have source code for ps, so I have no idea what in the process table is sending lseek (I assume it is lseek) off into the weeds. Maybe somebody could tell me what seeks ps does. Thanks, -- Adnan Yaqub Star Gate Technologies, 29300 Aurora Rd., Solon, OH, USA, +1 216 349 1860 ...uunet!abvax!sgtech!adnan
pb@idca.tds.PHILIPS.nl (Peter Brouwer) (05/16/89)
In article <ADNAN.89May15155425@sgtech.UUCP> adnan@sgtech.UUCP (Adnan Yaqub) writes: >Our Intel 386 box with Xenix 2.3.1 has a problem, and it is probably >one we have inflicted on ourselves. After the system is rebooted and >weeds. Maybe somebody could tell me what seeks ps does. Ps seeks to data structures in /unix file ( memory ). It reads data from for instance the user structure of each process that is running. This is done in a loop. If during this loop execution the process for which info is looked up dies, the data structures are not there any more. This causes the seek errors. I think this is also mentioned in the manual ( System administrators reference manual, topic Warning) -- # Peter Brouwer, ## # Philips TDS, Dept SSP-V2 ## voice +31 55 432523 # P.O. Box 245 ## UUCP address ..!mcvax!philapd!pb # 7300 AE Apeldoorn, The Netherlands ## Internet pb@idca.tds.philips.nl
ron@ron.rutgers.edu (Ron Natalie) (05/17/89)
The PS seek error is usually caused by the fact you are booting from a file other than /unix. PS does nlist on /unix to find the offsets for the various structures it peers into. -Ron
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (05/17/89)
>Ps seeks to data structures in /unix file ( memory ). It reads data from >for instance the user structure of each process that is running. >This is done in a loop. If during this loop execution the process for which >info is looked up dies, the data structures are not there any more. This >causes the seek errors. And unfortunately, instead of doing something smart like trying again or skipping it, it just bombs out. -- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us Ann Arbor, MI sharkey!b-tech!zeeff
daveh@marob.MASA.COM (Dave Hammond) (05/17/89)
In article <3569@ron.rutgers.edu> ron@ron.rutgers.edu writes: >The PS seek error is usually caused by the fact you are booting >from a file other than /unix. PS does nlist on /unix to find the >offsets for the various structures it peers into. Excepting that on Xenix, the kernel is usually named /xenix. The PS seek error can be fixed with a patch from SCO tech support. Sorry, I don't have the patch number handy. -- Dave Hammond daveh@marob.masa.com
marc@mas1.UUCP (Marc deGroot) (05/24/89)
> In article <ADNAN.89May15155425@sgtech.UUCP> adnan@sgtech.UUCP (Adnan Yaqub) writes: >Our Intel 386 box with Xenix 2.3.1 has a problem, and it is probably >one we have inflicted on ourselves. After the system is rebooted and >weeds. Maybe somebody could tell me what seeks ps does. ps tries to open /unix to read the symbol table. That's how it knows where the process table is in the kernel. The easiest fix is to make a link from the booted kernel to /unix. Another approach is to use the -n option on ps (this is from memory - I may be wrong) which allows you to specify which kernel file is used. Another coherent emission from: -- Marc de Groot (KG6KF) "The apparent stupidity of a bug ..!uunet!apple!mas1!marc is directly proportional to the ..!uunet!hoptoad!noe!marc amount of time it took to find it." mdg@postgres.berkeley.edu -me
adnan@sgtech.UUCP (Adnan Yaqub) (05/25/89)
In article <1887@mas1.UUCP> marc@mas1.UUCP (Marc deGroot) writes: > In article <ADNAN.89May15155425@sgtech.UUCP> adnan@sgtech.UUCP (Adnan Yaqub) writes: >Our Intel 386 box with Xenix 2.3.1 has a problem, and it is probably >one we have inflicted on ourselves. After the system is rebooted and >weeds. Maybe somebody could tell me what seeks ps does. ps tries to open /unix to read the symbol table. That's how it knows where the process table is in the kernel. The easiest fix is to make a link from the booted kernel to /unix. Another approach is to use the -n option on ps (this is from memory - I may be wrong) which allows you to specify which kernel file is used. This has turned out to be an SCO Xenix bug for which they have a fix (pach number xnx120). -- Adnan Yaqub Star Gate Technologies, 29300 Aurora Rd., Solon, OH, USA, +1 216 349 1860 ...uunet!abvax!sgtech!adnan