Re: Again: Most programs don't run. Please help!

2002-01-27 Thread ben
On Saturday 26 January 2002 05:48 pm, Andreas Goesele wrote:
[snip]
 The problem BTW returned again, now the third time, again only for
 some minutes. It started during a cron job and started and *ended*
 during heavy disk activity. 

as i mentioned earlier, you should determine whether one of the cron 
scheduled programs is causing the crashes.

to check the dependencies for the apps that cron runs, do 

apt-cache show filename

and check the output for dependency conflicts.



Re: Again: Most programs don't run. Please help!

2002-01-27 Thread Dimitri Maziuk
* Andreas Goesele ([EMAIL PROTECTED]) spake thusly:
 Dimitri Maziuk [EMAIL PROTECTED] writes:
 
  I'd ask on the kernel mailing list and/or on comp.os.linux.system.
 
 Thanks. But where would I find comp.os.linux.system? My news-server
 doesn't provide it nor did I find it on googles groups.

Sorry, make that comp.os.linux.development.system. It's on google,
as well as kernel list (linux.kernel; it is read-only, of course).

Dima



Re: Again: Most programs don't run. Please help!

2002-01-27 Thread Cameron Kerr
On 27 Jan 2002, Andreas Goesele wrote:

Cameron Kerr [EMAIL PROTECTED] writes:

 Well, if the error is indeterminate, then I would start to suspect your
 hardware. Errors such as this often indicate bad memory, in my
 experience. Getting segfaults all the time is a classic example of this.

 Get hold of memtest86 (http://www.teresaudio.com/memtest86/) and give your
 memory a good going over.

Three completed runs, all 16 tests, no error.

OK, so thats your memory tested...

 Running crashme off a boot floppy might also be, ah, interesting...

Would this, run by a simple computer user - except possibly crashing my
system - produce information which could help to pinpoint the problem?

Its not meant to pinpoint the problem. If the system crashes, that would
be a problem, if not, the CPU/kernel is (as far as running operations go)
okay. But, yeah. I've never used it myself, I just pointed it out because
it may come in useful ;)

The problem BTW returned again, now the third time, again only for
some minutes. It started during a cron job and started and *ended*
during heavy disk activity. (Actually it ended when I started memtest
for a third run which seemed to cause some swapping activity.)

Maybe, I should test my hard disks. What programs would you recommend
for that?

Well then, if it only happens during periods of high disk activity, I
would still suspect your hardware. We've already determined its not likely
to be your memory, but it could well be some other conflict. Perhaps if
you remove _all_ unnecessary drivers from the kernel (easiest if you are
running a very modular kernel), then you can start to tell what is
conflicting.

Make sure you are running a recent kernel. Also, please give details as to
your (detailed) hardware specs, paying particular attention to chipsets,
and the drivers used.

I hope this may shed some light on your predicament. If not, start
removing hardware, such as sound cards, and seeing if that starts to make
any difference.

Good luck.

Cameron Kerr
-- 
[EMAIL PROTECTED]
http://homepages.paradise.net.nz/~cameronk/




Re: Again: Most programs don't run. Please help!

2002-01-26 Thread Dimitri Maziuk
* Andreas Goesele ([EMAIL PROTECTED]) spake thusly:
 Hi,
 
 my problem as described in [EMAIL PROTECTED] and with
 some more details in [EMAIL PROTECTED] returned, though
 only for some minutes.
 
 Simple description: Suddenly most programs won't start anymore but will
 give the error message:
 
 foo: relocation error: /lib/libnss_compat.so.2: symbol rectory,
 version GLIBC_2.0 not defined in file libc.so.6 with link time
 reference
 
 As the problem returned there is - without any doubt - something
 deeply wrong with my system, but I don't have any clue what and how to
 go about finding out.
 
 So please, if you have any suggestion about how I could locate and
 eventually solve the problem, let me know.

I'd ask on the kernel mailing list and/or on comp.os.linux.system.

Dima
-- 
I have not been able to think of any way of describing Perl to [person]
Hello, blind man?  This is color.  -- DPM



Re: Again: Most programs don't run. Please help!

2002-01-26 Thread Cameron Kerr
* Andreas Goesele ([EMAIL PROTECTED]) spake thusly:

 Simple description: Suddenly most programs won't start anymore but will
 give the error message:

 foo: relocation error: /lib/libnss_compat.so.2: symbol rectory,
 version GLIBC_2.0 not defined in file libc.so.6 with link time
 reference

OK, GLIBC_2.0 refers to glibc5 (or 4?). Anyway, the likely reason that it
is not defined in libc.so.6 is because it only supports GLIBC_2.2 (glibc
2.2.4 actually). Normally I would have expected it to be backwards
compatible, but perhaps the Debian Maintainer does things differently, in
order to keep the binaries smaller. Perhaps there is a compatibility
packages in oldlibs (libc5 package)

Warning: This is just an educated guess. Good luck

Cameron Kerr
-- 
[EMAIL PROTECTED]
http://homepages.paradise.net.nz/~cameronk/




Re: Again: Most programs don't run. Please help!

2002-01-26 Thread Andreas Goesele
Dimitri Maziuk [EMAIL PROTECTED] writes:

 I'd ask on the kernel mailing list and/or on comp.os.linux.system.

Thanks. But where would I find comp.os.linux.system? My news-server
doesn't provide it nor did I find it on googles groups.

Andreas Goesele



Re: Again: Most programs don't run. Please help!

2002-01-26 Thread Andreas Goesele
Cameron Kerr [EMAIL PROTECTED] writes:

 * Andreas Goesele ([EMAIL PROTECTED]) spake thusly:
 
  Simple description: Suddenly most programs won't start anymore but will
  give the error message:
 
  foo: relocation error: /lib/libnss_compat.so.2: symbol rectory,
  version GLIBC_2.0 not defined in file libc.so.6 with link time
  reference
 
 OK, GLIBC_2.0 refers to glibc5 (or 4?). Anyway, the likely reason that it
 is not defined in libc.so.6 is because it only supports GLIBC_2.2 (glibc
 2.2.4 actually). Normally I would have expected it to be backwards
 compatible, but perhaps the Debian Maintainer does things differently, in
 order to keep the binaries smaller. Perhaps there is a compatibility
 packages in oldlibs (libc5 package)

Thanks. But would that explanation be compatible with the fact that my
system most of the time functions all-right and then suddenly for some
time (one day and then a few minutes) not? If libc.so.6 wasn't
backwards compatible I would expect that the problem would arise all
the time. And why should the great majority of programs, in a more or
less up to date woody system, depend on glibc5 or glibc4?

I continue to be mystified ...

Andreas Goesele



Re: Again: Most programs don't run. Please help!

2002-01-26 Thread Cameron Kerr
On 27 Jan 2002, Andreas Goesele wrote:

Thanks. But would that explanation be compatible with the fact that my
system most of the time functions all-right and then suddenly for some
time (one day and then a few minutes) not? If libc.so.6 wasn't
backwards compatible I would expect that the problem would arise all
the time. And why should the great majority of programs, in a more or
less up to date woody system, depend on glibc5 or glibc4?

I continue to be mystified ...

Well, if the error is indeterminate, then I would start to suspect your
hardware. Errors such as this often indicate bad memory, in my
experience. Getting segfaults all the time is a classic example of this.

Get hold of memtest86 (http://www.teresaudio.com/memtest86/) and give your
memory a good going over.

Running crashme off a boot floppy might also be, ah, interesting...

Andreas Goesele

Cameron Kerr
-- 
[EMAIL PROTECTED]
http://homepages.paradise.net.nz/~cameronk/




Re: Again: Most programs don't run. Please help!

2002-01-26 Thread ben
On Saturday 26 January 2002 03:34 pm, Andreas Goesele wrote:
[snip]
   foo: relocation error: /lib/libnss_compat.so.2: symbol rectory,
   version GLIBC_2.0 not defined in file libc.so.6 with link time
   reference
 
  OK, GLIBC_2.0 refers to glibc5 (or 4?). Anyway, the likely reason that it
  is not defined in libc.so.6 is because it only supports GLIBC_2.2 (glibc
  2.2.4 actually). Normally I would have expected it to be backwards
  compatible, but perhaps the Debian Maintainer does things differently, in
  order to keep the binaries smaller. Perhaps there is a compatibility
  packages in oldlibs (libc5 package)

 Thanks. But would that explanation be compatible with the fact that my
 system most of the time functions all-right and then suddenly for some
 time (one day and then a few minutes) not? If libc.so.6 wasn't
 backwards compatible I would expect that the problem would arise all
 the time. And why should the great majority of programs, in a more or
 less up to date woody system, depend on glibc5 or glibc4?


given that the disfunction is only occasional, it would seem that some app 
that runs only occasionally provokes the dependency issue. got anything set 
up in cron that might be doing this?



Re: Again: Most programs don't run. Please help!

2002-01-26 Thread Andreas Goesele
ben [EMAIL PROTECTED] writes:

  Thanks. But would that explanation be compatible with the fact that my
  system most of the time functions all-right and then suddenly for some
  time (one day and then a few minutes) not? If libc.so.6 wasn't
  backwards compatible I would expect that the problem would arise all
  the time. And why should the great majority of programs, in a more or
  less up to date woody system, depend on glibc5 or glibc4?
 
 
 given that the disfunction is only occasional, it would seem that some app 
 that runs only occasionally provokes the dependency issue. got anything set 
 up in cron that might be doing this?

I was thinking of that. But to my uneducated eye entries in cron.d,
cron.daily, cron weekly and cron.monthly looked rather inoffensive. Or
is there something in the following lists which could be the offender?
Is there some other source of cron jobs? (anacrontab and crontab
only start the jobs in these directories.)

cron.daily:

0anacron, 5snort, apache, calendar, cfengine, dwww, exim, find,
logrotate, man-db, mgetty, modutils, netbase, netkit-inetd, standard,
sysklogd, tetex-bin, tripwire-1.2

cron.d:

anacron, exim, logcheck, postgresql, shaper, tiger

cron.weekly:

0anacron, apt-move, cfengine, cfingerd, cvs, dpkg-mountable, efax, htdig, lpr,
man2html, man-db, sysklogd

cron.monthly:

0anacron, rwhod, standard

Andreas Goesele



Re: Again: Most programs don't run. Please help!

2002-01-26 Thread Andreas Goesele
Cameron Kerr [EMAIL PROTECTED] writes:

 Well, if the error is indeterminate, then I would start to suspect your
 hardware. Errors such as this often indicate bad memory, in my
 experience. Getting segfaults all the time is a classic example of this.
 
 Get hold of memtest86 (http://www.teresaudio.com/memtest86/) and give your
 memory a good going over.

Three completed runs, all 16 tests, no error.

 Running crashme off a boot floppy might also be, ah, interesting...

Would this, run by a simple computer user - except possibly crashing my
system - produce information which could help to pinpoint the problem?
(To say the truth - the explanation at
http://people.delphi.com/gjc/crashme.html didn't give me the
impression that I could interpret the result.)

The problem BTW returned again, now the third time, again only for
some minutes. It started during a cron job and started and *ended*
during heavy disk activity. (Actually it ended when I started memtest
for a third run which seemed to cause some swapping activity.)

Maybe, I should test my hard disks. What programs would you recommend
for that?

Andreas Goesele



Re: Again: Most programs don't run. Please help!

2002-01-26 Thread ben
On Saturday 26 January 2002 04:25 pm, Andreas Goesele wrote:
[snip]
 I was thinking of that. But to my uneducated eye entries in cron.d,
 cron.daily, cron weekly and cron.monthly looked rather inoffensive. Or
 is there something in the following lists which could be the offender?
 Is there some other source of cron jobs? (anacrontab and crontab
 only start the jobs in these directories.)

 cron.daily:

 0anacron, 5snort, apache, calendar, cfengine, dwww, exim, find,
 logrotate, man-db, mgetty, modutils, netbase, netkit-inetd, standard,
 sysklogd, tetex-bin, tripwire-1.2

 cron.d:

 anacron, exim, logcheck, postgresql, shaper, tiger

 cron.weekly:

 0anacron, apt-move, cfengine, cfingerd, cvs, dpkg-mountable, efax, htdig,
 lpr, man2html, man-db, sysklogd

 cron.monthly:

 0anacron, rwhod, standard


it might be worth your while going through the man pages for these--or using 
any other means you can come up with--to check for version numbers and 
possibly consequent dependency conflicts. it may well be that all you need to 
do is force an upgrade for one or another of them. apropos cfingerd, i can't 
remember the details but i do remember reading of something buggy about that. 
if i were you, i would definitely check on everything that cron invokes, and 
srupulously check your logs for any clue about the times the failures occur. 
follow that up with a search for anything at all that might have been 
modified around the same time. also, there's either an apt or a dpkg option 
that spits out dependency info but i can't remember the fine points of that 
right now. dpkg -C will return info on anything that hasn't been configured 
properly.



Again: Most programs don't run. Please help!

2002-01-25 Thread Andreas Goesele
Hi,

my problem as described in [EMAIL PROTECTED] and with
some more details in [EMAIL PROTECTED] returned, though
only for some minutes.

Simple description: Suddenly most programs won't start anymore but will
give the error message:

foo: relocation error: /lib/libnss_compat.so.2: symbol rectory,
version GLIBC_2.0 not defined in file libc.so.6 with link time
reference

As the problem returned there is - without any doubt - something
deeply wrong with my system, but I don't have any clue what and how to
go about finding out.

So please, if you have any suggestion about how I could locate and
eventually solve the problem, let me know.

Many thanks in advance!

Andreas Goesele

PS: This time the beginning of the problem coincided with the starting
of the daily cron jobs and heavy disk activity.