ps problem solved - more stupidity on our part

David Sherman dave at lsuc.UUCP
Sat Sep 7 01:10:09 AEST 1985


In article <845 at burl.UUCP> rcj at burl.UUCP (Curtis Jackson) writes:
>The first reply to my HELP!! article gave me the answer -- many thanks
>to dutoit!norman for his insight.  Although we changed the location of
>the swap area in the config file, reconfig'd properly, and remade the
>system properly; but it does help if you remove the old /dev/swap and
>do a mknod for a new one with the new major and minor device numbers;
>we were swapping onto a garbage area that used to hold news.

No, you were swapping where you were supposed to be swapping.
It just that ps wasn't looking in the right place for the swapped
processes.

However, you shouldn't need to do a mknod. Just rm the previous /dev/swap
and ln from the appropriate device. You normally have disk devices in
/dev, already mknod'ed, with names something like /dev/msm0a, msm0b, msm0c,
and so on (those are ours, yours will depend on the name of your disk).
I just changed our swap area this morning on lsuc, and what I did was
	rm swap
	ln fuja swap
because the swap is now in the first partition of our new Fujitsu drive.

>One question, though:  since we were swapping into the old swap area
>because we forgot the mknod, just what does changing the 'swap' line
>in the system definition file (config input) do?

THAT is what determines where you swap. You never have to do a mknod
for swap if you don't want to, but ps needs it to see what's going on
out there. The kernel itself doesn't need a /dev/swap.

Oh, and by the way, you should make sure /dev/swap is mode
644 if ps is not setUID (although that leaves a small security
hole in that someone can look at your process while it's swapped out);
conversely there rest of /dev/msm0[a-g] or whatever should be mode
600 and owned by root, so people can't look at files through the
back door.

Dave Sherman
The Law Society of Upper Canada
Toronto
-- 
{  ihnp4!utzoo  pesnta  utcs  hcr  decvax!utcsri  }  !lsuc!dave



More information about the Comp.unix.wizards mailing list