|
Grex > Helpers > #123: Grex System Problems - Fall 2003 |  |
|
| Author |
Message |
| 25 new of 291 responses total. |
tpryan
|
|
response 150 of 291:
| 
Nov 16 18:21 UTC 2003 |
Why would modem replacement take more than taking the
two disconnected and replaceing the first two in the trunk hunt?
THEN IF problem persists. Swap those two for the last two. Is
that more than a 22 minute visit at the pumpkin?
|
keesan
|
|
response 151 of 291:
|
Nov 16 18:34 UTC 2003 |
There has already been lots of modem swapping and half of the time it just
makes things worse. These modems are not reliable.
|
gelinas
|
|
response 152 of 291:
|
Nov 16 19:27 UTC 2003 |
So far as I know, there has been no swapping of modems in recent memory.
The next time I'm out, I'll swap in a couple of the recently retired modems.
|
keesan
|
|
response 153 of 291:
|
Nov 16 20:36 UTC 2003 |
Scott swapped modems not too long ago and what he put in was worse, I don't
recall exactly how.
|
tsty
|
|
response 154 of 291:
|
Nov 18 07:00 UTC 2003 |
nto a happy sight ...
df
Filesystem kbytes used avail capacity Mounted on
/dev/sd0a 109823 76941 21900 78% /
/dev/sd0d 156783 137446 3659 97% /usr
/dev/sd6h 1971009 1804600 0 102% /usr/local
/dev/sd0e 706783 354791 281314 56% /bbs
/dev/sd0f 471183 450069 0 106% /x
/dev/sd6g 1969885 1219140 553757 69% /var
/dev/sd3h 1944365 1222411 527518 70% /var/spool/mail
/dev/sd2a 31023 17781 10140 64% /rootbak
/dev/sd2d 31023 16038 11883 57% /suidbin
/dev/sd2f 62863 11755 44822 21% /tmp
/dev/sd2h 842574 686687 71630 91% /s
/dev/sd4a 1944365 1577694 172235 90% /c
/dev/sd1c 1944365 1059672 690257 61% /a
/dev/sd7g 1971009 1766520 7389 100% /d
/dev/sd2e 699223 455142 174159 72% /oldvar
/dev/sd0h 284215 252695 3099 99% /oldbbs
|
bhoward
|
|
response 155 of 291:
|
Nov 18 07:36 UTC 2003 |
That's the second time recently that /d filled, isn't it?
|
twenex
|
|
response 156 of 291:
|
Nov 18 10:18 UTC 2003 |
argh. I'd be more concerned about /usr/local "running at" 102%. Filesystems
aren't Hollywood nuclear submarine or starship warp engines, and don't run
well over capacity...
(Not to mention /x at 106%...
|
gelinas
|
|
response 157 of 291:
|
Nov 18 12:15 UTC 2003 |
It's more than the second time, I think.
Yes, filesystesm can run at more than 100%; the OS keeps a cushion available.
|
davel
|
|
response 158 of 291:
|
Nov 18 13:19 UTC 2003 |
(Only root can allocate disk blocks once 100% is exceeded. So no, things
mostly don't run well at over 100%, but /x & most likely /usr/local may not
notice the problem until they actually run out.)
|
russ
|
|
response 159 of 291:
|
Nov 18 14:01 UTC 2003 |
As the last of four dial-in users this morning, I got a decently
fast connection. This might be helpful to whoever is doing the
debugging.
|
twenex
|
|
response 160 of 291:
|
Nov 18 14:27 UTC 2003 |
Ah. After gelinas 2cents I suspected that "100%" actually meant "100% of the
space not reserved to root." QED.
|
gull
|
|
response 161 of 291:
|
Nov 18 14:47 UTC 2003 |
It's tricky because it's OS-dependent. Most Linux distributions report
percentages of the total disk space. BSD and SunOS report percentages
of the disk space available to users. So it's possible to fill a BSD
file system over 100% but not a Linux one.
|
twenex
|
|
response 162 of 291:
|
Nov 18 14:49 UTC 2003 |
Hmm. Does POSIX have anything to say on this?
|
jhudson
|
|
response 163 of 291:
|
Nov 18 15:43 UTC 2003 |
I've gotten two different takes on full filesystems under Linux.
It seems to matter which df I use (I have three of them: one from
my distribution, one from busybox, and one from asmutils).
|
twenex
|
|
response 164 of 291:
|
Nov 18 15:57 UTC 2003 |
Hmm. What's the behaviour from your distro's version? I'd consider that
standard (for Linux).
|
gull
|
|
response 165 of 291:
|
Nov 18 18:49 UTC 2003 |
In at least one version of df it's a compile-time flag, so you can have
it either way.
|
krj
|
|
response 166 of 291:
|
Nov 18 20:57 UTC 2003 |
www.cyberspace.org is not loading for me or for two other party
users in widely separated locations.
|
gull
|
|
response 167 of 291:
|
Nov 18 21:25 UTC 2003 |
It times out for me, too.
|
gelinas
|
|
response 168 of 291:
|
Nov 18 23:23 UTC 2003 |
I swapped out the first two modems (3000 and 5041) for two recently removed
from service. I also updated the phones script.
It looks like whatever was bothering httpd has now been fixed.
|
other
|
|
response 169 of 291:
|
Nov 19 03:00 UTC 2003 |
/x is not a user partition at all, so its being over 100% is of no
consequence.
|
russ
|
|
response 170 of 291:
|
Nov 19 23:40 UTC 2003 |
Speed on the modems is vastly improved. Thanks to gelinas.
|
gelinas
|
|
response 171 of 291:
|
Nov 20 05:03 UTC 2003 |
Glad it helped. Wish I knew which of the two removed from service was bad.
|
rcurl
|
|
response 172 of 291:
|
Nov 20 16:38 UTC 2003 |
I have been a supporter of Grex in the past by having several small
non-profit organizations with which I have been associated join Grex and
use it at least as their website and board mail reflector. The latter,
however, has become untenable because of spam. There is nearly ten times
more spam being distributed to the boards than board correspondence. Is
there any hope of soon having access to a filter here for spam? I will
probably move an organization off Grex (and thereby cancel membership)
unless there is some recourse against this avalanche of junk e-mail.
|
gelinas
|
|
response 173 of 291:
|
Nov 21 17:51 UTC 2003 |
} #233 of 233: by Rane Curl (rcurl) on Fri, Nov 21, 2003 (11:18):
} Could Grex use the Spamhaus Block List (SBL) to block spam? See
} http://www.spamhaus.org/sbl/howtouse.html
|
rcurl
|
|
response 174 of 291:
|
Nov 21 18:06 UTC 2003 |
(Gag...I did it again - entered that item in oldagora. I always scan
oldagora before agora, and have been forgetting where I am.... thanks
Joe, for bringing it over.)
|