|
|
| Author |
Message |
| 25 new of 224 responses total. |
other
|
|
response 24 of 224:
| 
Apr 10 14:29 UTC 2003 |
I thought those were all Klez variations.
|
gull
|
|
response 25 of 224:
|
Apr 10 18:34 UTC 2003 |
Maybe they are. I haven't been keeping track.
|
goose
|
|
response 26 of 224:
|
Apr 16 20:33 UTC 2003 |
Can anyone give us an 'official' explaination as to why Grex was down for so
long the other day?
|
mynxcat
|
|
response 27 of 224:
|
Apr 16 20:40 UTC 2003 |
read coop
|
scott
|
|
response 28 of 224:
|
Apr 16 22:08 UTC 2003 |
UPS again. STeve is looking into getting fresh batteries.
|
mcnally
|
|
response 29 of 224:
|
Apr 16 22:59 UTC 2003 |
BTW, "watch" has been reporting that "woot" is logged onto console
for a couple of days now. Perhaps it's just a ghost in wtmp
(or wherever watch gets its info) but if not, even on console leaving
a root user logged in isn't a particularly good idea..
|
goose
|
|
response 30 of 224:
|
Apr 16 23:26 UTC 2003 |
RE#27 -- I don't want to. Plus this is the Grex system problem item....;-)
|
badman
|
|
response 31 of 224:
|
Apr 17 23:14 UTC 2003 |
Hi every one! Im new to grex so i have no idea what you are talking
about.... im new to shells too so maybe some people can help me out?
thanks.
|
mcnally
|
|
response 32 of 224:
|
Apr 17 23:43 UTC 2003 |
With a name like that, we expect you to be omniscient..
|
keesan
|
|
response 33 of 224:
|
Apr 18 23:35 UTC 2003 |
When I logged in: mesg: Unable to find your tty (ttyt0) in utmp file.
Might I have done something stupid to .cshrc or .login? It all seems to work
anyway. I think I set things to force vt100.
|
jor
|
|
response 34 of 224:
|
Apr 19 01:09 UTC 2003 |
I don't believe it's your startup file(s),
and I'm glad it's here not . .
that other Unix system.
Maybe ttyt0 escaped to M-Net.
|
krj
|
|
response 35 of 224:
|
Apr 19 04:41 UTC 2003 |
The system periodically "loses" a tty or two somehow. When one gets
the message described by Sindi, it means you've connected to one of
those "lost" ttys. I had a similar tty tonight. Tels won't work
on a "lost" tty; if this is a problem, just log out and log in again,
and hope you get a different tty. I don't know of anything else
which fails on a "lost" tty.
|
shodan
|
|
response 36 of 224:
|
Apr 19 12:09 UTC 2003 |
i don not now way telnet can not fonction clarly..
|
mynxcat
|
|
response 37 of 224:
|
Apr 19 12:51 UTC 2003 |
I'm on the lost tty now. I've had this problem before.
|
keesan
|
|
response 38 of 224:
|
Apr 19 16:11 UTC 2003 |
I got the same message when I logged out and logged in again to a different
account, but today it is okay.
|
keesan
|
|
response 39 of 224:
|
Apr 22 15:30 UTC 2003 |
Today grex lost my tty again, but to compensate yesterday it started letting
me save mail messages and things I print (P) with lynx again.
|
keesan
|
|
response 40 of 224:
|
Apr 25 18:03 UTC 2003 |
I just figured out why I can telnet from a Linux computer and use Lynx with
arrow keys from my new (keesan2) account, whichhad no .cshrc, but it was not
recognizing the terminal type when telnetting with myold account:
tcsh: No entry for terminal type "linux"
tcsh: Using dumb terminal type
I had to set terminal type to VT100 every time before using Lynx (or the arrow
keys would not work).
My first account had some lines in .cshrc which I did not put there and when
I removed them things worked properly. Now it forces vt100 instead of using
dumb terminal.
Anyway, there is some problem with what used to be the settings in .cshrc
(from about five years ago). THere was a tset line that might have been
interfering with the tset vt100 line in .login. I removed that and everything
else but the personal aliases.
|
naftee
|
|
response 41 of 224:
|
Apr 27 02:12 UTC 2003 |
UUH OKAY
22878 naftee 38 0 3380K 3688K run/3 0:07 8.67% 7.03% top
21955 root -5 0 940K 536K sleep 0:03 15.79% 1.56% sendmail
665 root 15 0 12K 8K sleep 546:32 2.29% 1.56% update
22918 root 41 0 896K 452K run/0 0:00 7.69% 0.39% sendmail
|
keesan
|
|
response 42 of 224:
|
Apr 27 02:24 UTC 2003 |
I would love to have someone interpret #41.
|
other
|
|
response 43 of 224:
|
Apr 27 03:29 UTC 2003 |
Sindi, I would be curious if, based on what you have learned in your
years of tinkering with computers, you would take a stab at interpreting
it yourself, and sharing that with the rest of us.
|
jor
|
|
response 44 of 224:
|
Apr 27 11:39 UTC 2003 |
Sindi take a glance at the manpage for top
|
tod
|
|
response 45 of 224:
|
Apr 27 12:32 UTC 2003 |
This response has been erased.
|
jazz
|
|
response 46 of 224:
|
Apr 27 14:52 UTC 2003 |
Not enough information to respond. Any one given process can look
like that if the system is heavily loaded enough, if it's responsible for
any of the load at all. I'd imagine the real problem at the time is too
many users with too many processes.
|
jhudson
|
|
response 47 of 224:
|
Apr 28 19:08 UTC 2003 |
Isn't update the process that sync's disks every 90 seconds or so?
If so, than this symptom is simply of an overloaded machine.
|
mdw
|
|
response 48 of 224:
|
Apr 28 22:23 UTC 2003 |
Update naturally accumulates time in operation. This is a function of
the amount of disk disk writes, size of the buffer pool, and other
factors. On grex which is usually busy doing something that involves
disk writes, update manages to consume about 1.72 seconds every minute.
That works out to 103 seconds per hour. An accumulated runtime of
546:32 should correspond to an uptime of approximately 13 days 5 hours.
The time update spends is basically part of "sytem overhead". Newer
systems may be more efficient at this, perhaps. OpenBSD does not have
/usr/sbin/update, but it does have a kernel process that does
effectively the same thing. On an ultrasparc1 running openbsd, update
seems to be accumulating only .06 seconds per minute, but this machine
is *much* less busy than grex. On an AIX machines, I got only .03
seconds/minute, but since that machine isn't running ffs but instead
jfs, I don't know that this number is at all comparable.
|
