|
|
| Author |
Message |
i
|
|
Grex System Problems Item
| 
Mar 21 04:09 UTC 1999 |
This item is for system problems. If something on Grex isn't working
right (line noise on a modem, weird behavior from a program, etc.),
this is the place to announce it. Except for security holes. If you
find a hole in system security, mail information about it to "staff".
|
| 124 responses total. |
krj
|
|
response 1 of 124:
|
Mar 27 19:39 UTC 1999 |
As the staff probably knows, /var is full, /tmp is full.
I am finding that I can't edit conference responses I'm writing.
|
gregb
|
|
response 2 of 124:
|
Mar 27 20:53 UTC 1999 |
Sounds like Grex is really full of it. 8-)
|
keesan
|
|
response 3 of 124:
|
Mar 28 01:40 UTC 1999 |
Is there some way to tell my total grex memory usage? (home directory, www,
and mail directories)
|
drew
|
|
response 4 of 124:
|
Mar 28 02:11 UTC 1999 |
The unix command is 'du'. This gets you the size of whatever directory tree
you give it. You'll have to do this for your home directory, and for your mail
file (which I am not sure that du can isolate from the rest; you might want
'ls -l /var/mail/keesan' for that.
Memory use, I'm not sure of, but 'free' gets the total memory use of the
system, including both real and virtual. There might be an option to get
memory use only for processes owned by you.
|
aruba
|
|
response 5 of 124:
|
Mar 28 03:38 UTC 1999 |
To see the size of her mail file, Sindi should execute
!ls -l /var/spool/mail/k/e/keesan
|
keesan
|
|
response 6 of 124:
|
Mar 28 14:25 UTC 1999 |
I did the var/spool/ thing and got about 92K.
I then typed du /a/k/e/keesan and got
226 for mail
16 for www
551 for home directory
Does the var/spool/ thing show only mail in inbox?
|
scott
|
|
response 7 of 124:
|
Mar 28 15:06 UTC 1999 |
Yup.
|
davel
|
|
response 8 of 124:
|
Mar 28 16:06 UTC 1999 |
(du shows disk usage in 512-byte blocks. Multiply by 512 to get bytes.)
|
remmers
|
|
response 9 of 124:
|
Mar 28 17:41 UTC 1999 |
Or (on Grex, anyway) you can use du with the -b option to get bytes.
|
mcnally
|
|
response 10 of 124:
|
Mar 28 18:02 UTC 1999 |
but be aware that the total for "du -b" and "du -k" doesn't necessarily
jibe..
% du -s -k ~mcnally
45 /a/m/c/mcnally
% du -s -b ~mcnally
29208 /a/m/c/mcnally
My guess is that "du -b" just adds up the bytes in the file contents,
which is not actually an accurate way to count how much space is being
used by the files.
Files in the 4.2BSD (McKusick, et al.) filesystem being used on Grex
consume filesystem space in greater-than-1-byte increments. The
filesystem is divided into "blocks", which are themselves sub-divided
into "fragments". Depending on how the filesystem was initialized,
the smallest amount of disk space a file can consume will be one fragment
(disregarding the file's entry in a directory file, which also consumes
some space.)
That means that if Grex's filesystems are created with 4K blocks, each
consisting of 8 fragments (I don't know what the actual parameters are,
I didn't create the filesystems when they were set up..) that the smallest
amount of disk space a file can use will be 512 (= 4096 / 8) bytes(*)
So if you have a file with just a single character in it, and assuming
I am right about "du -b", then "ls -l" will report a size of 1 byte,
"du -b" will count it as a byte, and "du -k" will count it as a full
fragment -- 512(*) bytes -- a much more accurate measure of how much
space you're really using.
(*) again, assuming 512 byte fragments *only* for purposes of example.
|
mdw
|
|
response 11 of 124:
|
Mar 30 04:21 UTC 1999 |
/a and /c were built with a fragsize of 1024 and a blocksize of 8192.
|
orinoco
|
|
response 12 of 124:
|
Mar 30 21:44 UTC 1999 |
(out of curiousity, why is there no /b ?)
|
kaplan
|
|
response 13 of 124:
|
Mar 31 01:46 UTC 1999 |
There is a /b. It's the bbs shell. The bbs shell was given the shortest
possible name to save space in the password file.
|
i
|
|
response 14 of 124:
|
Mar 31 01:51 UTC 1999 |
/b is a symbolic link to /bbs/bbs.sh, which is the "real" bbs shell.
|
steve
|
|
response 15 of 124:
|
Mar 31 06:51 UTC 1999 |
Right, that was created back long before we saw that we needed
a more general way of labeling the partitions for user areas. The
current one letter system will let us have 23 more such partitions,
and hopefully we'll never go beyond that! So poor little /b is a
lagacy directory.
|
davel
|
|
response 16 of 124:
|
Mar 31 11:11 UTC 1999 |
"*lag*acy" meaning it increases system lag? 8-{)]
|
bdh1
|
|
response 17 of 124:
|
Apr 2 06:57 UTC 1999 |
Munificent Grace to ye grex abacus staff whom in one day sothe to an
conquered a dreaded Y2M monster inhabiting the sacred plane of the grex
abacus.
|
ryan
|
|
response 18 of 124:
|
Apr 2 14:08 UTC 1999 |
This response has been erased.
|
katie
|
|
response 19 of 124:
|
Apr 3 04:53 UTC 1999 |
Is there a reason I wouldn't receive a couple of e-mails that a particular
person sent me? I believe in both cases he mailed me by responding to an
e-mail I sent him. It happened over a week apart and I'm getting plenty of
e-mail from other people.
|
keesan
|
|
response 20 of 124:
|
Apr 5 15:15 UTC 1999 |
I apparently sent someone half an email yesterday (subject line was the last
thing that got sent) from a computer that we discovered shortly after had a
virus. He could check for viruses. This is a partition table virus, whatever
that means.
|
gull
|
|
response 21 of 124:
|
Apr 5 19:09 UTC 1999 |
Don't worry. Partition table virii can't be spread by email, or at least I
don't know of any that can be. And there's nowhere to stick one before the
subject line anyhow.
|
mcnally
|
|
response 22 of 124:
|
Apr 6 06:24 UTC 1999 |
partition table viruses?
|
keesan
|
|
response 23 of 124:
|
Apr 6 19:16 UTC 1999 |
I was suggesting that the friend who had trouble sending email might have a
problem at his end. (See the item on viruses for a detailed description of
our virus problem.) And that he should check his computer for viruses. A
virus may have been responsible for an intermittent formatting problem on the
computer that our virus spread from.
Partition table viruses can definitely spread by floppy disk and by
nullmodem cable. Anyone know about tape backup? If so, please offer us some
help in the computer virus item (66, I think it is). We would like to know
how to remove the virus from the hard disk, since repartitioning and
reformatting did not remove it.
|
mcnally
|
|
response 24 of 124:
|
Apr 7 04:53 UTC 1999 |
(would someone please explain to me what good it would do to put
a virus in the partition table? are you, perhaps, talking about
*boot sector* viruses?)
|
