At 04:15 PM 4/24/2001 -0500, you wrote:
>Ben Ocean wrote:
> >
> > At 03:00 PM 4/24/2001 -0500, you wrote:
> > >Hm. Guess arbitrarily closing the port was probably a bad idea, huh?
> > >Is this Linux's/RedHat's fault?
> >
> > hindsight's 20/20
>
>But foresight is necessary. Sounds like you and your hired proxies are
>making decisions about networked applications without having sufficient
>information to hand. This happens of course, but let's give credit
>where credit is due when things go wrong.
I hear ya.
> > > > Then, I noticed there was a problem with /usr/bin/slocate. Now,
> > > > when I say *problem*, I mean the damn thing was chewing up 80%+ of
> my CPU!
> > >
> > >All the time? Or just at certain times?
> >
> > Dunno for the slocate problem. When the problem was in logrotate.status
> > (presumably before it got to slocate) it ran for *hours* then crashed.
>
>I do not understand. logrotate is independent of slocate, it's doubtful
>that the same issue would cause both of these processes to run haywire,
>with the exception of filesystem-related problems in /var, maybe. Did
>you ever get to the bottom of the logrotate problem? I don't recall
>mention of it previously in this thread.
The problem, it appears, was this *interchange* thing I mentioned earlier.
I finally finished erasing the file. It appears that closing the port
created innumerable log errors, which in turn were gzipped, and it took an
hour, AN HOUR of CPU time to erase them. Good grief! Anyway, I now have to
undo the stupid mistakes I made along the way trying to *fix* the problem.
Namely the problem of updating slocate that caused it to corrupt the database:
>>>
thewebsons:/apache/vhosts# slocate this
/apache/vhosts/skagitharley/this.html
fatal error: slocate: decode_db: 'pathlen == -1'! Corrupt Database!
<<<
> > Makes newbies skittish...
>
>Good. Skittishness is what turns newbies into BOFHen. Eventually.
>Face your fear and learn.
Uh, yeah. Didn't know HTML from Mandarin 15 months ago...
> > >Since updating slocate, have you run updatedb(1L)?
> >
> > You mean updatedb without the (1L)
>
>Sorry, (1L) refers to the section in which the manpage resides. Yes, I
>do mean to run just updatedb with no arguments.
I'm doing that now that I *finally* erased the aforementioned file. Let's
see if I can hold an Internet connection long enough and not fall asleep :)
> > It chokes. Gave it about 10
> > seconds then killed the command.
>
>Part of the reason why I include the manpage section with the reference
>to the command is so that you will know that there is a manpage for the
>command. And read it. Ten seconds is almost certainly not long enough
>to let updatedb run. It indexes your whole filesystem. That is how
>[s]locate works. And by the way, while it is indexing your whole
>filesystem you should expect it to chew some CPU.
Yeah. It took 1-1/2 hrs until it reached the aforementioned now deleted
file, then I killed it to delete.
>Before assuming that a program is hung, try watching it with strace(1).
>If you see it repeating the same sequence over and over again with no
>changes, then it's (probably) hung. If it's just taking lots of time or
>CPU, it may be doing what it's supposed to do.
strace after updatedb
> > >http://www.linux-geek.org/slocate/
> >
> > dead page. Looked at the home page: strange but unrelated.
>
>Crud. Well, my search efforts don't fare any better. But before you
>bug them you should give the software an opportunity to run properly.
Yup.
> > Tried B4 I wrote the list. No man page on my box for slocate. RH6.2
>
>That's funny...
Uh-huh...
'Preciate your help. Keep you posted. Thanks again :))
BenO
_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
