[comp.sys.sgi] the /debug partition

bernie@cidam.rmit.OZ.AU (Bernard Kirby) (07/27/88)

We recently had one of our machines upgraded to a 4D-70GT running
version 3 of the operating system (4sight 1.0 etc). After all the
software was installed we noticed that a  "df" showed an "extra"
partition /dev/debug of type dbg mounted on /debug. It was about
50Mb in size! There appeared to be files in the /debug directory,
but whenever you tried to look at them, nothing happened, like they
were zero length files, except that "ls -l" showed that some of them
were quite large in size. The number and size of files varied as the
machine was used. This partition was not in /etc/fstab but was in 
/etc/mtab. So, one day in a fit of experimentality we simply "umount"ed
it, and it hasn't reappeared since, even after a reboot. 
Now for the questions.

a) Is this a "hidden" partition that is secretly present on all SGI
   machine's disks, only manifesting itself when explicitly mounted?

b) Is it really about 50Mb in size, or is that simply a function of "df"
   misinterpreting a file system of type dbg.

	OR

c) Did the Version 3 system repartition our disk without telling us?
   If it did, then it must have zapped some files. 

d) Can we use it for something else, like an NFS partition?

e) If we can't use it for anything else, can we reclaim the disk space?
   (If in fact is really is using disk space)

f) What the F**k's it for? Why did it just show up unannounced, with no
   documentation about what it's doing.

Thanks, 
	Bernie Kirby.

creon@ORVILLE.NAS.NASA.GOV (07/27/88)

The /debug partition is basically /dev/proc.  The files change as processes
are born and die (I guess).

tarolli@olympus.SGI.COM (Gary Tarolli) (07/27/88)

/debug is the swap partition made visible.  Files are actually pids,
file size is the process size.  The "df" command reveals the swap
partition's size, usage, and availability.

As for the documentation and how to get /debug mounted again, I don't know...

archer@elysium.SGI.COM (Archer Sully) (07/27/88)

In article <8807260558.AA07135@uunet.UU.NET>, bernie@cidam.rmit.OZ.AU (Bernard Kirby) writes:
> 
> We recently had one of our machines upgraded to a 4D-70GT running
> version 3 of the operating system (4sight 1.0 etc). After all the
> software was installed we noticed that a  "df" showed an "extra"
> partition /dev/debug of type dbg mounted on /debug. It was about
> 50Mb in size! There appeared to be files in the /debug directory,
> but whenever you tried to look at them, nothing happened, like they
> were zero length files, except that "ls -l" showed that some of them
> were quite large in size. The number and size of files varied as the
> machine was used. This partition was not in /etc/fstab but was in 
> /etc/mtab. So, one day in a fit of experimentality we simply "umount"ed
> it, and it hasn't reappeared since, even after a reboot. 
> Now for the questions.
> 
> a) Is this a "hidden" partition that is secretly present on all SGI
>    machine's disks, only manifesting itself when explicitly mounted?

yes, it is present, because it is really the swap partition.

> 
> b) Is it really about 50Mb in size, or is that simply a function of "df"
>    misinterpreting a file system of type dbg.
> 
> 	OR
> 
> c) Did the Version 3 system repartition our disk without telling us?
>    If it did, then it must have zapped some files. 
> 
It really is 50MB.

> d) Can we use it for something else, like an NFS partition?
> 

no

> e) If we can't use it for anything else, can we reclaim the disk space?
>    (If in fact is really is using disk space)
> 
Since it doesn't use any space that wasn't already allocated, this 
isn't a problem.

> f) What the F**k's it for? Why did it just show up unannounced, with no
>    documentation about what it's doing.
> 
/debug is used by debuggers and other programs that like to control
processes other than themselves.  The idea is that when you access a 
file in the /debug partition, the kernel actually performs an operation
on another process.  This is what allows dbx to attach to a running 
process.

If /debug won't remount, check your /etc/fstab.  it should have this 
line in it:

/debug /debug dbg rw 0 0

If it doesn't, put it back.  If it does, make sure that the /debug
mount point is still there.  If both conditions are true, then I
have no idea what you've done to your system.  Try re-installing
3.0, or waiting for the maintenance release to get there.

There will be a man page for /debug in the next general software release.

> Thanks, 
> 	Bernie Kirby.


You're Welcome,
	Archer Sully

dunlap@bombadl.SGI.COM (D. Christopher Dunlap) (07/27/88)

In article <18021@sgi.SGI.COM>, archer@elysium.SGI.COM (Archer Sully) writes:
> 
> If /debug won't remount, check your /etc/fstab.  it should have this 
> line in it:
> 
> /debug /debug dbg rw 0 0
> 
> If it doesn't, put it back.  If it does, make sure that the /debug
> mount point is still there.  If both conditions are true, then I
> have no idea what you've done to your system.  Try re-installing
> 3.0, or waiting for the maintenance release to get there.
> 
> There will be a man page for /debug in the next general software release.
> 
> > Thanks, 
> > 	Bernie Kirby.
> 
> 
> You're Welcome,
> 	Archer Sully
> 
> 

Actually, the thing that mounts "/debug" is the script 
"/etc/rc2.d/S01MOUNTFSYS". This is the script that actually does the
mounting of the filesystems, and if you look in there, you will see
that it explicitly mounts "/debug".




Chris Dunlap
Silicon Graphics

	"I Knew something Archer didn't know.... YA YAAA YA YA.."



P.S.

You should NEVER touch anything in those directories. 

grose@camax01.UUCP (Larry Grose) (07/29/88)

In article <8807260558.AA07135@uunet.UU.NET> bernie@cidam.rmit.OZ.AU (Bernard Kirby) writes:
>
>We recently had one of our machines upgraded to a 4D-70GT running
>version 3 of the operating system (4sight 1.0 etc). After all the
>software was installed we noticed that a  "df" showed an "extra"
>partition /dev/debug of type dbg mounted on /debug. It was about
>50Mb in size! There appeared to be files in the /debug directory,
>but whenever you tried to look at them, nothing happened, like they
>were zero length files, except that "ls -l" showed that some of them
>were quite large in size. The number and size of files varied as the
>machine was used. This partition was not in /etc/fstab but was in 
>/etc/mtab. So, one day in a fit of experimentality we simply "umount"ed
>it, and it hasn't reappeared since, even after a reboot. 

(Specific questions deleted.)

Basically, this is your standard swap partition which has been there all
along.  There has been no change in your disk partitioning.  Each file in
the partition corresponds to a running task (I believe the file "name" is
the process id), and the size of the file corresponds to the size of the
process's virtual memory.  Our in-house users had the same questions about
whether or not that partition could be used for storing files, and the
answer from SGI was "no".  This window into the swap partition was made
available so that you could debug programs that were already running (I
didn't ask how).  One other convenient use is that you can quickly see how
full virtual memory is by doing a 'df'.  I haven't tried dismounting it,
but I don't imagine there should be any problem with it if it bothers you
to see it in the 'df' listing.  I agree with the complaint about the lack
of documentation concerning it.  It was a rather disconcerting thing for
us to discover, too.
-- 
Larry Grose
CAMAX Systems, Minneapolis MN