Niet te killen processen :?

[acq]

Ik zag vanochtend dat mijn SuSE Linux 7.2 server is blijven hangen met het maken van stats. Het proces dat blijft hangen is niet te killen met "kill" en ook niet met "killall". Tevens zijn er 2 voor mij onbekende processen bijgekomen. Nu is me dit al vaker overkomen en een reboot helpt dan, maar om nou steeds te rebooten wordt me ook wat te gortig (doe een wedstrijdje uptime). Heeft iemand enig idee wat deze processen zijn en hoe ik ze plat krijg (want ook die willen niet plat)? Ze zorgen tevens voor een load van >4 ipv 1-2

nobody 26346 1 0 00:22 ? 00:00:04 /usr/bin/find / ( -fstype nfs -o -fstype NFS -o -fstype proc

^deze ken ik niet

root 26696 1 0 02:22 ? 00:02:58 /usr/bin/perl ppstats-rc5-7.1.pl

^blijft hangen

root 27195 1 0 05:55 ?
00:03:01 /usr/bin/perl ppstats-rc5-7.1.pl

^blijft hangen


root 28154 1 0 11:52 ?
00:00:09 /usr/bin/find / ( -fstype nfs -o -fstype NFS -o -fstype proc

^ken ik niet

root 28311 1 0 12:52 ?
00:00:09 /usr/bin/find / ( -fstype nfs -o -fstype NFS -o -fstype proc

^ken ik niet

[wibblemoo]

kill -9 pidnummer ?

paardemiddeltje

[warp]

Op woensdag 31 oktober 2001 15:09 schreef acq het volgende:
Nu is me dit al vaker overkomen en een reboot helpt dan, maar om nou steeds te rebooten wordt me ook wat te gortig (doe een wedstrijdje uptime).

Rebooten

How about:

init 1
init 3

[Verwijderd]

Die find lijkt sterk op een updatedb commando dat vaak een keer per dag (nacht) wordt aangeroepen om de database te updaten.

[acq]

Op woensdag 31 oktober 2001 15:12 schreef wibblemoo het volgende:
kill -9 pidnummer ?

paardemiddeltje

Alleen niet krachtig genoeg

[Verwijderd]

Op woensdag 31 oktober 2001 15:14 schreef janjanjansen het volgende:
Die find lijkt sterk op een updatedb commando dat vaak een keer per dag (nacht) wordt aangeroepen om de database te updaten.

dat _IS_ het ook

[imdos]

heb je een nfs share die dood is gegaan ofzo? dat zou verklaren waarom die updatedb blijft hangen!

En die ppstats .. rc5 geval geen idee waarom die vastloopt

[deadinspace]

Geef eens de volledige output van 'ps auxf'.

[acq]

Ik ga er ff vanuit dat die schijf niet het loodje gelegd heeft. Lijkt me ook stug. Alles werkt verder namelijk nog

Op woensdag 31 oktober 2001 15:34 schreef deadinspace het volgende:
Geef eens de volledige output van 'ps auxf'.

code:

acq2:~ # ps auxf
USER     PID %CPU %MEM   VSZ  RSS TTY   STAT START   TIME COMMAND
root       1  0.0  0.2   436   64 ?   S    Oct16   0:25 init [3]
root       2  0.0  0.0     0    0 ?   SW   Oct16   0:00 [keventd]
root       3  0.0  0.0     0    0 ?   SWN  Oct16   1:48 [ksoftirqd_CPU0]
root       4  0.0  0.0     0    0 ?   SW   Oct16   7:34 [kswapd]
root       5  0.0  0.0     0    0 ?   SW   Oct16   0:00 [kreclaimd]
root       6  0.0  0.0     0    0 ?   SW   Oct16  10:57 [bdflush]
root       7  0.0  0.0     0    0 ?   SW   Oct16   3:54 [kupdated]
root      92  0.2  4.6  1656 1368 ?   S    Oct16  63:53 ./proxyper -detach
root     207  0.0  0.0     0    0 ?   SW   Oct16   0:00 [eth0]
root     209  0.0  0.0     0    0 ?   SW   Oct16   0:00 [eth1]
bin   252  0.0  0.6  1312  200 ?      S    Oct16   0:01 /sbin/portmap
root     273  0.0  0.8  2236  260 ?   S    Oct16   2:44 /usr/sbin/sshd
root     28439  0.0  5.2  2816 1540 ?     S    13:47   0:02  \_ /usr/sbin/sshd
root     28440  0.0  5.1  2632 1528 pts/4    S    13:47   0:02  \_ -bash
root     28515 99.9  5.0  2468 1496 pts/4    R    14:28   0:02      \_ ps auxf
root     282  0.0  0.7  1364  228 ?   S    Oct16   4:00 /sbin/syslogd
root     287  0.0  1.0  1704  308 ?   S    Oct16   0:08 /sbin/klogd -c 1
root     302  0.0  0.0  1364    4 ?   S    Oct16   0:00 /usr/sbin/lpd
at     344  0.0  0.3  1432  104 ?     S    Oct16   0:00 /usr/sbin/atd
root     401  0.0  1.6  2048  488 ?   S    Oct16   5:26 /usr/sbin/pppd call adsl
root     23792  0.5  1.8  1340  544 ?     R    Oct30   8:20  \_ /usr/sbin/pptp pptp: GRE-to-PPP gateway on /dev/ptmx
root     464  0.0  0.3  1436  116 ?   S    Oct16   0:21 /usr/sbin/cron
root     534  0.0  1.1 11764  352 ?   S    Oct16   0:08 /usr/sbin/nscd
root     536  0.0  1.1 11764  352 ?   S    Oct16   0:21  \_ /usr/sbin/nscd
root     538  0.0  1.1 11764  352 ?   S    Oct16   0:07 \_ /usr/sbin/nscd
root     539  0.0  1.1 11764  352 ?   S    Oct16   0:11 \_ /usr/sbin/nscd
root     540  0.0  1.1 11764  352 ?   S    Oct16   0:10 \_ /usr/sbin/nscd
root     541  0.0  1.1 11764  352 ?   S    Oct16   0:09 \_ /usr/sbin/nscd
root     543  0.0  1.1 11764  352 ?   S    Oct16   0:09 \_ /usr/sbin/nscd
root     661  0.0  1.7  4356  512 ?   S    Oct16   6:04 /usr/bin/perl /usr/libexec/webmin/miniserv.pl /etc/webmin/minis
root     665  0.0  0.0  1272    4 tty1     S    Oct16   0:03 /sbin/mingetty --noclear tty1
root     666  0.0  0.0  2060    4 tty2     S    Oct16   0:04 login -- root
root    7255  0.0  0.0  2612    4 tty2     S    Oct17   0:06  \_ -bash
root     669  0.0  0.0  1272    4 tty5     S    Oct16   0:03 /sbin/mingetty tty5
root     670  0.0  0.0  1272    4 tty6     S    Oct16   0:03 /sbin/mingetty tty6
root    1664  0.0  0.0  1272    4 tty3     S    Oct21   0:02 /sbin/mingetty tty3
root    1665  0.0  0.0  1272    4 tty4     S    Oct21   0:02 /sbin/mingetty tty4
root    1694  0.0  0.2 47564   76 ?   S    Oct21   2:02 /usr/sbin/httpd -f /etc/httpd/httpd.conf
wwwrun    1734  0.0  0.4 47084  140 ?     S    Oct21   0:01  \_ /usr/sbin/fcgi- -f /etc/httpd/httpd.conf
wwwrun    1736  0.0 12.6 47972 3708 ?     S    Oct21   3:11  \_ /usr/sbin/httpd -f /etc/httpd/httpd.conf
wwwrun    1820  0.0 12.7 48036 3744 ?     S    Oct21   3:15  \_ /usr/sbin/httpd -f /etc/httpd/httpd.conf
nobody   14445  0.0  0.4  3832  120 ?     S    Oct23   0:10 proftpd (accepting connections)
root     23795  0.0  1.6  1328  492 ?     S    Oct30   0:11 /usr/sbin/pptp pptp: call manager for 10.0.0.138
nobody   26346  0.0  2.6  1540  768 ?     DN   00:22   0:04 /usr/bin/find / ( -fstype nfs -o -fstype NFS -o -fstype proc -o
root     26696  0.4 13.5  5028 3976 ?     D    02:22   2:58 /usr/bin/perl ppstats-rc5-7.1.pl
root     27195  0.0  4.0  2408 1180 ?     S    05:55   0:01 /bin/sh /home/marc/stats/stats.sh
root     27204  0.5 13.6  5144 4008 ?     D    05:57   3:01  \_ /usr/bin/perl ppstats-rc5-7.1.pl
root     28154  0.1  2.7  1700  804 ?     D    11:52   0:09 /usr/bin/find / ( -fstype nfs -o -fstype NFS -o -fstype proc -o
root     28311  0.1  2.7  1700  804 ?     D    12:52   0:09 /usr/bin/find / ( -fstype nfs -o -fstype NFS -o -fstype proc -o
acq2:~ #

edit: op verzoek hele blok tussen code tags gezet.

[acq]

Ik zag BTW net in /var/log/messages dit:

code:

Oct 31 01:23:59 acq2 kernel: Unable to handle kernel paging request at virtual address 02310028
Oct 31 01:23:59 acq2 kernel:  printing eip:
Oct 31 01:23:59 acq2 kernel: c0143f7c
Oct 31 01:23:59 acq2 kernel: *pde = 00000000
Oct 31 01:23:59 acq2 kernel: Oops: 0000
Oct 31 01:23:59 acq2 kernel: CPU:    0
Oct 31 01:23:59 acq2 kernel: EIP:    0010:[find_inode+32/76]
Oct 31 01:23:59 acq2 kernel: EFLAGS: 00010213
Oct 31 01:23:59 acq2 kernel: eax: 00000000   ebx: 02310000   ecx: 0000000b   edx: c1094000
Oct 31 01:23:59 acq2 kernel: esi: 02310000   edi: 00000000   ebp: 00024e79   esp: c133dec8
Oct 31 01:23:59 acq2 kernel: ds: 0018   es: 0018   ss: 0018
Oct 31 01:23:59 acq2 kernel: Process perl (pid: 26486, stackpage=c133d000)
Oct 31 01:23:59 acq2 kernel: Stack: 00024e79 c10956f8 00024e79 c10e2000 c0144354 c10e2000 00024e79 c10956f8 
Oct 31 01:23:59 acq2 kernel:      00000000 00000000 00024e79 c1ae0ea0 c139c9a0 c133df8c c0154ac1 c10e2000 
Oct 31 01:23:59 acq2 kernel:      00024e79 00000000 00000000 fffffff4 c1ae0ea0 c139c9a0 c1699044 c013af33 
Oct 31 01:23:59 acq2 kernel: Call Trace: [iget4+64/212] [ext2_lookup+89/128] [lookup_hash+111/140] [open_namei+273/1564] [do_munmap+567/580] [filp_open+46/76] [sys_open+53/180] 
Oct 31 01:23:59 acq2 kernel:      [system_call+51/56] [startup_32+43/165] 
Oct 31 01:23:59 acq2 kernel: 
Oct 31 01:23:59 acq2 kernel: Code: 39 6e 28 75 ef 8b 44 24 14 39 86 98 00 00 00 75 e3 85 ff 74

Lijkt inderdaad op een hdd probleem. Gaf ook een fout met umounten van de root partitie. Maar met de reboot gaf ie wel aan dat de schijven clean waren en hij loopt nu weer

edit: op verzoek hele blok tussen code tags.

[acq]

Iemand een idee hoe ik die harde schijf kan scannen? Met e2fsck lijkt me beetje link:

acq2:~ # e2fsck /dev/hdc9
e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
/dev/hdc9 is mounted.

WARNING!!! Running e2fsck on a mounted filesystem may cause
SEVERE filesystem damage.

Do you really want to continue (y/n)? no

check aborted.

[RemcoX]

eerst unmounten, dan e2fsck

[deadinspace]

Mja, / umounten is niet zo heel praktisch hoor.
Je kunt het beste naar single-user mode gaan (met 'init 1'; webserver enzo worden dan wel stopgezet), en dan / read-only remounten (met 'mount -o remount,ro /') en dan fscken.

Verder kun je die processes niet killen omdat ze op I/O wachtten. De kernel ruimt processes die op I/O wachten pas op als die I/O is afgehandeld. Meestal is de I/O waar het om gaat HD-acces, en het feit dat je processes hierop bleven wachten duidt ook mogelijk in de richting van een brakke HD.

Oja, en die output van ps auxf had in een [code] blok gemogen

[acq]

Op woensdag 31 oktober 2001 17:40 schreef deadinspace het volgende:
Mja, / umounten is niet zo heel praktisch hoor.
Je kunt het beste naar single-user mode gaan (met 'init 1'; webserver enzo worden dan wel stopgezet), en dan / read-only remounten (met 'mount -o remount,ro /') en dan fscken.

Dat zal ik straks ff proberen.

Verder kun je die processes niet killen omdat ze op I/O wachtten. De kernel ruimt processes die op I/O wachten pas op als die I/O is afgehandeld. Meestal is de I/O waar het om gaat HD-acces, en het feit dat je processes hierop bleven wachten duidt ook mogelijk in de richting van een brakke HD.

Da's duidelijk! Tnx!

Dan moet ik waarschijnlijk toch maar weer naar een andere hdd gaan kijken. Heb nog wel een 8.4GB maar dat ondersteunt die 486 niet denk ik.

Oja, en die output van ps auxf had in een [code] blok gemogen

Wist niet dat er niet afgebroken werd tussen code tags, bij deze.

[deadinspace]

Op woensdag 31 oktober 2001 18:04 schreef acq het volgende:
Dan moet ik waarschijnlijk toch maar weer naar een andere hdd gaan kijken. Heb nog wel een 8.4GB maar dat ondersteunt die 486 niet denk ik.

Vergeet niet dat GNU/Linux de BIOS negeert. Als je je computer dus zo gek krijgt dattie boot, kan GNU/Linux gewoon die HD aanspreken, ook al ondersteunt je BIOS die grootte HD niet.

Wist niet dat er niet afgebroken werd tussen code tags, bij deze.

Mja, het gaat me vooral om de layout: de tekst in een [code] blok wordt normaalgesproken in een monospaced font weergegeven, waardoor het er netjes als een tabelletje uitziet. Zo kan ik snel zien dat de onderste paar processes status D (uninterruptable sleep, bijna altijd veroorzaakt door pending I/O) waren.

[acq]

Iedereen bedankt tot zover. Ik heb nog wel een vraagje, want als ik nu init 1 geef om daarna fcsk uit te kunnen voeren, wordt ik om m'n root wachtwoord gevraagd. Als ik dat in geef, vraagt ie er weer om en weer en weer. Blijft hangen in een loopje dus. Het wachtwoord is overigens niet incorrect, want als ik een incorrecten op geeft zegt ie dat ook. Verder lijken me de wachtwoord files nog in orde, aangezien ik na een reboot gewoon weer in init 3 in kan loggen.

Dit vind ik een beetje vaag. Geen idee nu of de hdd naar de haaien aan het gaan is of niet. Iemand een andere suggestie of een idee hoe het kan dat ie in een loopje komt?

[Verwijderd]

Ik heb een vergelijkbaar probleem, dus post ik 't maar hier.

Ik heb ook SuSE 7.2 Professional [kernel 2.4.4-4GB] en ik gebruik licq. Ik had een sb-128 en die heb ik omgewisselt voor een sb-Live1024.

Licq geeft sox een opdracht die zeer veel cpu-tijd kost en niet te killen is. niet met 'kill -9 <pid van progje>' of met 'skill sox' [beide als root]

ps aux | grep sox geeft o.a. de volgende output:

code:

compukid 2938 52.1 0.0 1744 0 ? RW 20:43 72:19 sox /usr/share/licq/sounds/icq/Message.wav -t ossdsp /dev/dsp

ls -lh /dev | grep dsp geeft o.a.:

code:

lrwxrwxrwx 1 root root 4 Jun 25 11:44 dsp -> dsp0
crw------ 1 compukid users 14, 3 May 21 14:21 dsp0

locate Message.wav geeft o.a.

code:

/usr/share/licq/sounds/icq/Message.wav

init 1 en dan init 5 mocht niet baten, een reboot lost 't op. maar dan ontstaat na een tijdje licq'en het probleem opnieuw.....

Iemand een idee?

[imdos]

en een fuser -v /dev/dsp
overigens kan je proberen met een fuser -k /dev/dsp het te killen als ik me niet vergis

[Verwijderd]

Je kunt eens proberen na init 1 om als root-password alleen een Enter te geven. Lukt dat niet, dan is het een kwestie van ff een rescue disk downen (zoals tomsrtbt) en dan / ff read-only mounten en vervolgens alsnog fsck runnen.

Succes.

[odysseus]

Op donderdag 01 november 2001 23:51 schreef imdos het volgende:
en een fuser -v /dev/dsp
overigens kan je proberen met een fuser -k /dev/dsp het te killen als ik me niet vergis

Helaas is fuser geen standaard programma bij mijn weten (bij Debian in ieder geval niet). En inderdaad, met -k kun je de processen die het bestand vasthouden killen. Denk alleen niet dat dat gaat lukken als een SIGKILL het ook niet wil doen...

[acq]

Op vrijdag 02 november 2001 19:11 schreef KrunK het volgende:
Je kunt eens proberen na init 1 om als root-password alleen een Enter te geven. Lukt dat niet, dan is het een kwestie van ff een rescue disk downen (zoals tomsrtbt) en dan / ff read-only mounten en vervolgens alsnog fsck runnen.

Succes.

Het lijkt alsof de hdd inderdaad defect raakt. Hij geeft nu geregeld "segmentation fault". Bijvoorbeeld bij: ping, traceroute, mc, perlscripts enzovoorts.

Ik kan inmiddels weer in init 1 (na een paar keer rebooten) en heb daar de / volgens het genoemde commando gemount (mount remount,ro /). Vervolgens e2fsck gedaan. Geen badblocks of wat dan ook gevonden. Toch de melding dat er wat veranderd is (zelfde voor de boot partitie). Wazig dus.

Een stukje uit /var/log/messages:

code:

Nov  2 20:38:15 acq2 proftpd[1719]: acq2.werkgroep (acq.werkgroep[192.168.0.105]) - FTP session opened. 
Nov  2 20:38:16 acq2 proftpd[1719]: PAM unable to dlopen(/lib/security/pam_pwcheck.so)
Nov  2 20:38:16 acq2 proftpd[1719]: PAM [dlerror: /usr/lib/libcrack.so.2: unexpected reloc type 0x0c]
Nov  2 20:38:16 acq2 proftpd[1719]: PAM adding faulty module: /lib/security/pam_pwcheck.so
Nov  2 20:38:16 acq2 proftpd[1719]: acq2.werkgroep (acq.werkgroep[192.168.0.105]) - USER marc: Login successful. 
Nov  2 20:38:16 acq2 pppd[460]: rcvd [LCP EchoReq id=0xcd magic=0xce7b10d c2 6d 68 68]
Nov  2 20:38:16 acq2 pppd[460]: sent [LCP EchoRep id=0xcd magic=0x370ca462 c2 6d 68 68]
Nov  2 20:38:53 acq2 proftpd[1720]: acq2.werkgroep (acq.werkgroep[192.168.0.105]) - FTP session opened. 
Nov  2 20:38:53 acq2 proftpd[1720]: PAM unable to dlopen(/lib/security/pam_pwcheck.so)
Nov  2 20:38:53 acq2 proftpd[1720]: PAM [dlerror: /usr/lib/libcrack.so.2: unexpected reloc type 0x0c]
Nov  2 20:38:54 acq2 proftpd[1720]: PAM adding faulty module: /lib/security/pam_pwcheck.so
Nov  2 20:38:54 acq2 proftpd[1720]: acq2.werkgroep (acq.werkgroep[192.168.0.105]) - USER marc: Login successful. 
Nov  2 20:39:08 acq2 proftpd[1720]: acq2.werkgroep (acq.werkgroep[192.168.0.105]) - FTP session closed.

Verder geeft ie af en toe iets van: Suprious IRQ 7. Exact weet ik het niet, aangezien het niet in messages komt. Alleen in de kernel output (ALT-F10).

Hij moet het iig nog even uitzingen tot ik er een andere hdd in kan zetten. Wel vreemd dat er geen problemen gevonden worden.

offtopic:
(kon gisteren niet gepost -> forum plat)

[Verwijderd]

Segmentation fault heeft blijkbaar niets te maken met je hdd. Dat zou ook verklaren waarom er geen badblocks gevonden werden.

Zo aan je log te zien is er een lib naar de kloten of zo.

Volgens mij kun je met dmesg zien wat er gevonden wordt op IRQ 7.

[acq]

Op zaterdag 03 november 2001 14:26 schreef KrunK het volgende:
Segmentation fault heeft blijkbaar niets te maken met je hdd. Dat zou ook verklaren waarom er geen badblocks gevonden werden.

Zo aan je log te zien is er een lib naar de kloten of zo.

Volgens mij kun je met dmesg zien wat er gevonden wordt op IRQ 7.

Tnx. In de output van dmesg kan ik niets over IRQ 7 vinden (zou ook niet weten wat het zou kunnen zijn). Bij het opnieuw e2fsck-en (weer geen foutmeldingen), kwam de melding over IRQ 7 weer: "Spurious 8259A interrupt: IRQ7".

Wel kan ik dit vinden:

Partition check:
hda: hda1
hdb: hdb1 hdb2 < hdb5 hdb6 hdb7 hdb8 >
hdc: [PTBL] [970/64/63] hdc1 < hdc5 hdc6 hdc7 hdc8 hdc9 >

HDC is de schijf waar linux op staat. Ik weet niet wat dat PTBL betekent en ook niet wat dat 970/64/63 betekend. Zegt iemand dat wat?

Verder vond ik dit:

code:

EXT2-fs warning: maximal mount count reached, running e2fsck is recommended

en dat 5 keer achter elkaar. Wat ik van e2fsck begreep, zijn er niet teveel files of zo (45000 tegen 200.000 maximaal). Verder is de schijf dus 2.1GB en de hdb schijf (die af en toe gemount wordt) 1.2GB. Iemand een idee wat er bedoeld wordt?

[acq]

^ & Momenteel werken alle scripts en commando's weer (weet ook niet waarom), maar de melding over "maximum mount count" blijft zich geregeld herhalen. Iemand een idee?

[Verwijderd]

Spurious 8259A interrupt: IRQ7.

[PTBL] [970/64/63] betekent, dat linux de geometrie gegevens uit de partitiontable leest ipv uit de bios. Hier een thread erover.

Dat van die maximum mount count is dat na een aantal malen in linux booten (en dus de schijven mounten) deze gechecked moeten worden. Is niks bijzonders, moet bij mijn Mandrake distro ook. Echter waarom 'ie handmatig gechecked moet worden ipv automagisch weet ik niet...

[odysseus]

Op zondag 04 november 2001 20:00 schreef KrunK het volgende:
Echter waarom 'ie handmatig gechecked moet worden ipv automagisch weet ik niet...

Uit de manpage over fstab.h (gaat ook over /etc/fstab):

The sixth field, (fs_passno), is used by the fsck( program to determine the order
in which filesystem checks are done at reboot time. The root filesystem should be
specified with a fs_passno of 1, and other filesystems should have a fs_passno of
2. Filesystems within a drive will be checked sequentially, but filesystems on
different drives will be checked at the same time to utilize parallelism available
in the hardware. If the sixth field is not present or zero, a value of zero is
returned and fsck will assume that the filesystem does not need to be checked.

Het genoemde zesde veld is dus die '0' die waarschijnlijk in de laatste kolom van de betreffende regel in de /etc/fstab staat. Normaal gezien is het vrij overbodig om niet-root filesystems vaak te fsck'en (denk aan een schijf met mp3'tjes of zo) en dus zal hij het niet automatisch doen. Natuurlijk zijn er ook programma's die je maximum mount count kunnen wijzigen, dat zou een andere oplossing zijn.

[Verwijderd]

hmmm.... ik ga geen suse gebruiken dus

[acq]

Op zondag 04 november 2001 20:00 schreef KrunK het volgende:
Spurious 8259A interrupt: IRQ7.

[PTBL] [970/64/63] betekent, dat linux de geometrie gegevens uit de partitiontable leest ipv uit de bios. Hier een thread erover.

Dat van die maximum mount count is dat na een aantal malen in linux booten (en dus de schijven mounten) deze gechecked moeten worden. Is niks bijzonders, moet bij mijn Mandrake distro ook. Echter waarom 'ie handmatig gechecked moet worden ipv automagisch weet ik niet...

Bedankt voor alle info! Over dat van IRQ 7 hoef ik me dus eigenlijk geen zorgen te maken en dat PTBL ook niet

Dat maximal mount count is een beetje vreemd aangezien ik hem al een paar keer handmatig gechecked heb, maar is dus ook niet schadelijk.

Alle andere gekkigheid (segmentation faults bij commando's) zijn verdwenen, waar ze vandaan kwamen en waar ze heen zijn weet ik niet

Vannacht heeft ie nog dit gemeld in /var/log/warn:

code:

Nov  4 20:08:03 acq2 kernel: memory.c:83: bad pmd 010fc28a.

Keertje een fout in het geheugen kennelijk.

Maar aangezien alles nog steeds werkt en ook weer goed, zal het allemaal wel weer in orde zijn. Ik zal in ieder geval er binnenkort een andere harde schijf in doen en misschien een ander mobo+proc. Vanwege al die foutmeldingen had ik al even gekeken naar andere mogelijkheden namelijk.

Nogmaals tnx!

[acq]

Op zondag 04 november 2001 20:26 schreef odysseus het volgende:

[..]

Uit de manpage over fstab.h (gaat ook over /etc/fstab):
[..]

Het genoemde zesde veld is dus die '0' die waarschijnlijk in de laatste kolom van de betreffende regel in de /etc/fstab staat. Normaal gezien is het vrij overbodig om niet-root filesystems vaak te fsck'en (denk aan een schijf met mp3'tjes of zo) en dus zal hij het niet automatisch doen. Natuurlijk zijn er ook programma's die je maximum mount count kunnen wijzigen, dat zou een andere oplossing zijn.

Ik heb even gekeken naar mijn fstab:

code:

/dev/hdc9    /   ext2    defaults 1 1
/dev/hdc7    /boot   ext2    defaults 1 2
/dev/cdrom  /media/cdrom    auto    ro,noauto,user,exec 0 0
/dev/hdb6    /data1  auto    noauto,user 0 0
/dev/hdb8    /data2  auto    noauto,user 0 0
devpts  /dev/pts      devpts  defaults 0 0
/dev/fd0      /media/floppy   auto    noauto,user,sync 0 0
proc    /proc   proc    defaults 0 0
/dev/hda1    /windows/C vfat    noauto,user 0 0
/dev/hdb1    /windows/D vfat    noauto,user 0 0
/dev/hdb5    /windows/E vfat    noauto,user 0 0
/dev/hdc5    /windows/F vfat    noauto,user 0 0
/dev/hdc6    /windows/G vfat    noauto,user 0 0
/dev/hdc8    swap    swap    pri=42 0 0

Er is inderdaad wat gewijzigd, aangezien hda en hdb er niet in gestaan hebben. Maar mijn root partitie (hdc9) staat dus netjes op 1 en de boot partitie op 2. De rest staat allemaal op 0. Lijkt me dus goed. Als ik de waarde in 0 zou veranderen, dan zou die bij het booten niet meer checken op fouten op /, dus dan laat ik die melding van maximum mount count maar gewoon langskomen.

Bedankt!

[acq]

Op zondag 04 november 2001 20:28 schreef narfpower het volgende:
hmmm.... ik ga geen suse gebruiken dus

Omdat 1 op de tig gebruikers iets geks tegen komt? Beetje vreemde opmerking he. Anyway, smaken zat

[active2]

Waarom stap je niet een keer over naar Debian GNU/Linux! Ik had namelijk ook een wrakke hd (kan ook een wrakke ide controller zijn geweest) maar elke keer als hij die hd niet meer kon aanspreken was er een reset op mijn ide controller en toen deed hij het weer.

Dus...

[acq]

Op maandag 05 november 2001 10:33 schreef active2 het volgende:
Waarom stap je niet een keer over naar Debian GNU/Linux!

Omdat ik nog steeds een redelijke newbie ben op Linux gebied en dus dat beetje extra ondersteuning (lees voorgebakken dingen) in SuSE nodig ben. Ik draai een 1.5 jaar Linux op de desktop als 2e OS en 3/4 jaar als OS voor de server (als we ff FreeSCO meerekenen als zijnde Linux, anders wordt het een paar maand ).

Dus dat lijkt me nog ff geen goed idee, ook omdat ik er verder niet veel mee op schiet voor mijn gevoel

[acq]

Voor de volledigheid vermeld ik maar ff de reden van dat mamimum mount count verhaal. Dat werd veroorzaakt door de 2e harde schijf. Die wordt geregeld gemount om een backup er op te zetten van alle logs. Gescand en klaar