cdash@boulder.Colorado.EDU (Charles Shub) (05/13/87)
We had to make some changes in our deqna driver ( vaxif/if_qe.c ) and when we rebuilt Ultrix 1.1 for our microvax, all was fine except PS no longer lists any processes. We haven't the foggiest. Anybody got any bright ideas? thanks...cdash -- cdash aka cdash@boulder.colorado.edu aka ...hao!boulder!cdash aka ...nbires!boulder!cdash
zink@bunker.UUCP (David Zink) (05/13/87)
Charles Shub: >we rebuilt Ultrix 1.1 for our microvax, all was fine except PS no longer >lists any processes. Does the new OS with the new drivers have the saem name as the old? PS may be using the previous version as a reference when decoding system tables. (man PS may describe a fix for that (-f option?))
cdash@boulder.Colorado.EDU (Charles Shub) (05/13/87)
the problem was i was calling it testkernel instead of vmunix and the
software was getting lost. Moral:
move the old kernel to vmunix.old and the new one to
vmunix and it will work
thanks to all 3 correct answerers...cdash
--
cdash aka cdash@boulder.colorado.edu aka ...hao!boulder!cdash
aka ...nbires!boulder!cdashark@alice.UUCP (05/13/87)
In article <648@boulder.Colorado.EDU>, cdash@boulder.UUCP writes: > We had to make some changes in our deqna driver ( vaxif/if_qe.c ) and when > we rebuilt Ultrix 1.1 for our microvax, all was fine except PS no longer > lists any processes. We haven't the foggiest. Anybody got any bright ideas? When making kernel changes, one often puts the new kernel in a non-standard place and then boots it. Ps usually will fail until the kernel is moved to the standard place. On many systems this is /unix or /vmunix. I don't know what it is on Ultrix.
mitch@stride1.UUCP (Thomas P. Mitchell) (05/19/87)
In article <2047@bunker.UUCP> zink@bunker.UUCP (David Zink) writes: >Charles Shub: >>we rebuilt Ultrix 1.1 for our microvax, all was fine except PS no longer >>lists any processes. > I assume the file 'ps' was copied in when you reinstalled the OS. If it is there, check the permissions. Also invoke it with a full path name "/bin/ps" just incase PATH/path is messed up. If as root '/bin/ps' works and it does not as a normal user then permissions are the problem. 'ps' must be able to read kernel memory to find out what processes the kernel is managing. To do this the program is normally SUID to root (PID=0) or SGID so that it has read permission on "/dev/kmem". Also check devices to ensure that they are there and can be read. -r-sr-sr-x 1 root sys 27104 Oct 9 1986 /bin/ps or -rwxr-sr-x 1 root kmem 40960 Jan 10 1902 /bin/ps Good luck from Reno Thomas P. Mitchell (mitch@stride1.Stride.COM) Phone: (702) 322-6868 TWX: 910-395-6073 MicroSage Computer Systems Inc. a Division of Stride Micro. Opinions expressed are probably mine.
jwhitson@wpi.wpi.edu (John C Whitson KB2GNC) (10/29/89)
Can anyone tell me exactly how ps works?
That is, ps(1) that shows process data, not
anything to do with postscript.
Even if you can't tell me exactly :-), any
general information would be appreciated.
--
---------------------------------------------------------------------------
John Whitson: Internet: jwhitson@wpi.wpi.edu Bitnet: jwhitson@wpi.bitnet
UUCP: {decwrl,uunet}!m2c!wpi!jwhitson
---------- Anything with this tag on it is purely my own opinion ---------