nicht angemeldet
Was will mir diese Fehlermeldung sagen?
Hello,
ich habe auf dem Server eine Datei gesucht, und bekomme plötzlich diese Meldung. Gestern hatte ich die noch nicht.
find: WARNING: Hard link count is wrong for ./proc/1/task/1: this may be a bug in your filesystem driver. Automatically turning on find's -noleaf option. Earlier results may have failed to include directories that should have been searched.
Was kann/muss ich da tun, um das Problem einzukreisen und möglichst zu beseitigen?
Liebe Grüße
Tom vom Berg
--
Nur selber lernen macht schlau
Nur selber lernen macht schlau
-
Hallo,
find: WARNING: Hard link count is wrong for ./proc/1/task/1: this may be a bug in your filesystem driver. Automatically turning on find's -noleaf option. Earlier results may have failed to include directories that should have been searched.
Das ist ein Bug im proc-Dateisystem in alten Kerneln, der m.W. nicht weiter kritisch ist. Allerdings stellen sich hier zwei Fragen:
* Was machst Du noch mit so einem alten Kernel? Meines Wissens wurde der
Fehler mit 2.6.12 oder 2.6.13 gefixed (und selbst wenn's 2.6.16 war,
der ist auch schon vor 2 Jahren freigegeben worden). Du solltest den
dringend mal aktualisieren, es gab im Linux-Kernel ein paar Sicherheits-
lücken, die seitdem korrigiert wurden (ich denke da v.a. an vmsplice).* Was suchst Du in /proc rum? Da will man doch idR. eh nichts suchen...
Viele Grüße,
Christian-
hallo Christian,
* Was suchst Du in /proc rum? Da will man doch idR. eh nichts suchen...
Naja, jedenfalls nicht mit find. Nach einem Kernelneubau oder anderen gravierenden Änderungen möchte man bisweilen wissen, ob alles noch da ist - oder du möchtest eventuell /proc auf ein anderes device mounten, um eine gechrootete Umgebung nutzen zu können.
Grüße aus Berlin
Christoph S.
-
Hello,
[...] oder du möchtest eventuell /proc auf ein anderes device mounten, um eine gechrootete Umgebung nutzen zu können.
Ich habe im ersten Moment doch tatsächlich "geschrotete Umgebung" gelesen und dachte an "geschreddert"... Also Christoph, Dein Denglisch ist wirklich interessant, das sollte glatt zu einer eigenen "Denglisch Zitatesammlung" Anlass geben. Die schönsten Verballhornungen der deutschen und der englischen Sprache ;-)
Liebe Grüße
Tom vom Berg
--
Nur selber lernen macht schlau
-
-
Hello,
* Was machst Du noch mit so einem alten Kernel? Meines Wissens wurde der
Fehler mit 2.6.12 oder 2.6.13 gefixed (und selbst wenn's 2.6.16 war,
der ist auch schon vor 2 Jahren freigegeben worden). Du solltest den
dringend mal aktualisieren, es gab im Linux-Kernel ein paar Sicherheits-
lücken, die seitdem korrigiert wurden (ich denke da v.a. an vmsplice).*ups* schon wieder Handlungsbedarf. Dabei wollte ich nun langsam mit der Installation der Applikationen anfangen. :-(
Der Root-Server ist billig. Dafür ist es ein älteres Gerät. Es wird ausdrücklich darauf hingewiesen, dass es für Debian 4.0 insbesondere neure Kernels bisher noch keinen Support gibt.
Meine Freundin hat ihn letzte Woche erst von 3.1 auf 4.0 hochgezogen. Das läuft auf eigene Gefahr.
Ich hatte hier zuhause mit einem meiner Testserver auch Probleme mit neueren Kernels. Die haben so ungefähr das gleiche Alter...________:/# uname -r
2.6.8-2-686-smpScheint trotz Upgrade das alte Kernel geblieben zu sein.
Ich weiß nicht, ob ich das so einfach wagen kann, das Kernel auszutauschen.
Wenn die Kiste nicht wieder hochfährt, fangen wir von vorne an und vor allem kann ich das dann nicht online machen.* Was suchst Du in /proc rum? Da will man doch idR. eh nichts suchen...
Ich habe mit find ab der Root nach phpize gesucht, weil ich zu faul war nachzudenken, wo es sich denn verstecken könnte. Das haben wir hier ja schon mal zusammen durch, wie ich es nachinstalliert bekomme. Muss ich gleich mal das Archiv bemühen. Die Akte steht natürlich zuhause.
Liebe Grüße
Tom vom Berg
--
Nur selber lernen macht schlau
-
hallo Tom,
Meine Freundin hat ihn letzte Woche erst von 3.1 auf 4.0 hochgezogen. Das läuft auf eigene Gefahr.
Debian 4.0 (Etch) hat laut Pressemitteilung Kernel 2.6.18.
Grüße aus Berlin
Christoph S.
-
Hello Christoph,
Meine Freundin hat ihn letzte Woche erst von 3.1 auf 4.0 hochgezogen. Das läuft auf eigene Gefahr.
Debian 4.0 (Etch) hat laut Pressemitteilung Kernel 2.6.18.
Das war mir bekannt.
Daher macht mich das auch stutzig.
Ich kann meine fleißigen Helferlein aber leider nicht erreichen, um mal nachzufragen.
Aber in der Doku, die bei uns immer geschreiben wird bei wesentlichen Änderungen, steht, dass es vorher Debian (sarge) 3.1 war, PHP4, MySQL4 usw.
Debian wurde mittels dist-Upgrade von 3.1 auf 4.0 gebracht und alle anderen Dienste mit apt-get remove und anschließendem apt-get intstall des neuen Paketes.Beim Dist-Upgrade wird also augenscheinlich das Kernel in Ruhe gelassen. Ich kann mir, muss ich zugeben, auch nicht vorstellen, wie man das im laufenden Betrieb wechseln kann. Hab ich noch nie auf einem Remote-Host gemacht.
Liebe Grüße
Tom vom Berg
--
Nur selber lernen macht schlau
-
hallo Tom,
Beim Dist-Upgrade wird also augenscheinlich das Kernel in Ruhe gelassen.
Richtig - so weit mir bekannt.
Ich kann mir, muss ich zugeben, auch nicht vorstellen, wie man das im laufenden Betrieb wechseln kann. Hab ich noch nie auf einem Remote-Host gemacht.
Wie das "remote" geht, weiß ich auch nicht. Auf dem eigenen Rechner geht es problemlos. Nur wechselst du den Kernel nicht "im laufenden Betrieb", der neue ist erst nach einem reboot aktiv - einschließlich des neuen /proc und aller Module.
Grüße aus Berlin
Christoph S.
-
Hello,
Wie das "remote" geht, weiß ich auch nicht. Auf dem eigenen Rechner geht es problemlos. Nur wechselst du den Kernel nicht "im laufenden Betrieb", der neue ist erst nach einem reboot aktiv - einschließlich des neuen /proc und aller Module.
Ich habe mir ein paar Howtos gezogen. Angeblich ist "Upgrading remote Debian server is a piece of cake :-)" was auch immer das heißen soll.
Meint der jetzt "so einfach wie Torteessen"?
http://www.cyberciti.biz/tips/upgrading-debian-sarga-3-to-etch-4.html
Liebe Grüße
Tom vom Berg
--
Nur selber lernen macht schlau
-
hallo Tom,
Angeblich ist "Upgrading remote Debian server is a piece of cake :-)" was auch immer das heißen soll.
Meint der jetzt "so einfach wie Torteessen"?Nö. Gemeint ist: "ist ein(es von vielen) Tortenstückchen".
http://www.cyberciti.biz/tips/upgrading-debian-sarga-3-to-etch-4.html
Liest sich eigentlich sehr einfach.
Grüße aus Berlin
Christoph S.
-
Hello,
http://www.cyberciti.biz/tips/upgrading-debian-sarga-3-to-etch-4.html
Liest sich eigentlich sehr einfach.
Wenn ich es wage, dann solange nichts drauf ist an Daten...
Also wäre jetzt die einzige Möglichkeit.
Ich kann mich dann nur schlecht kümmern die nächste Woche, wenn es schief gehen sollte.Liebe Grüße
Tom vom Berg
--
Nur selber lernen macht schlau
-
-
Hello,
http://www.cyberciti.biz/tips/upgrading-debian-sarga-3-to-etch-4.html
Das war nur das remote OS Upgrade auf dem alten Kernel.
Das haben die Mädels schon letzte Woche gemacht.
Hab ich also keinen Mehrwert erzeugt bisher.Nun hab ich noch einen:
http://jeremy.zawodny.com/blog/archives/004215.html
Mal schauen, was der so vorschlägt...Liebe Grüße
Tom vom Berg
--
Nur selber lernen macht schlau
-
-
-
-
-
-
-
hallo Tom,
Hard link count is wrong for ./proc/1/task/1
Ups. Ein Fehler in /proc ist nicht sehr häufig. Du kannst dir erstmal mit
ls -l /proc/1/task/1
anschauen, was es da alles gibt. Ich kann im Moment nur mit Gentoo vergleichen, und da gibt es drei Hardlinks; das müßte allerdings bei dir genauso sein.Was kann/muss ich da tun, um das Problem einzukreisen und möglichst zu beseitigen?
Hast du denn zwischenzeitlich irgendwas herumgebastelt? /proc sollte bei einem Neustart während des shutdown erstmal völlig geleert werden.
Grüße aus Berlin
Christoph S.
-
Hallo Christoph,
Hast du denn zwischenzeitlich irgendwas herumgebastelt? /proc sollte bei einem Neustart während des shutdown erstmal völlig geleert werden.
Nö. Seitdem vor Jahrzehnten irgendwer mal beschlossen hat /proc für Systeminformationen zu missbrauchen (naja, inzwischen gibt's ja /sys, aber das setzt sich erst langsam durch) sind in /proc immer irgendwelche Dateien, die den Systemzustand wiedergeben - z.B. /proc/mounts o.ä. Leer ist /proc also nicht.
Außerdem: Sobald auch nur ein Prozess gestartet ist (und das kann auch ein Kernel-Thread wie pdflush sein), dann bekommt der auch eine PID und damit auch ein Verzeichnis in /proc.
Viele Grüße,
Christian-
hallo Christian,
Leer ist /proc also nicht.
Ich muß dir widersprechen. Ich habe auf meinem Rechner zwar im Augenblick Gentoo laufen, aber es gibt auf einer anderen Platte auch ein voll funktionsfähiges Debian. Ich habe das eben mal in mein Gentoo eingehängt, um nachzuschauen - dort ist im Moment /proc vollkommen leer.
Ich schau mal, wie das andersherum aussieht - also wenn ich Debian starte und mir von dort aus das Gentoo-/proc ansehe.Außerdem: Sobald auch nur ein Prozess gestartet ist (und das kann auch ein Kernel-Thread wie pdflush sein), dann bekommt der auch eine PID und damit auch ein Verzeichnis in /proc.
Das ist ja richtig. Und übrigens:
cat /proc/mounts
will man gelegentlich wissen.Grüße aus Berlin
Christoph S.
-
Hallo Christoph,
Leer ist /proc also nicht.
Ich muß dir widersprechen. Ich habe auf meinem Rechner zwar im Augenblick Gentoo laufen, aber es gibt auf einer anderen Platte auch ein voll funktionsfähiges Debian. Ich habe das eben mal in mein Gentoo eingehängt, um nachzuschauen - dort ist im Moment /proc vollkommen leer.
Unter /proc verstehe ich das virtuelle Kernel-Dateisystem, das man in 99,999999999999% aller Fälle nach /proc mountet. Dass das in Wirklichkeit auf der Platte lediglich ein leeres Verzeichnis ist, das einen Mountpoint darstellt, ist doch vollkommen irrelevant für den Sachverhalt. Es wäre genauso idiotisch zu sagen, /home sei nach dem Booten leer, wenn's in einer anderen Partition liegt und man gerade von CD gebootet hat und bisher nur das Hauptdateisystem gemountet hat.
Zumal Deine Aussage, dass das nach dem Booten geleert ist, weiterhin falsch ist, denn wenn man eine Linux-Distribution bootet, mountet die von vorne herein /proc, und damit ist das Verzeichnis nach dem Booten "gefüllt".
Viele Grüße,
Christian-
hallo Christian,
Zumal Deine Aussage, dass das nach dem Booten geleert ist, weiterhin falsch ist
Das wäre sie - aber ich habe gesagt, "nach dem shutdown", und bisher bin ich davon ausgegangen, daß sich das tatsächlich so verhält.
Grüße aus Berlin
Christoph S.
-
Hello,
hallo Christian,> Das wäre sie - aber ich habe gesagt, "nach dem shutdown", und bisher bin ich davon ausgegangen, daß sich das tatsächlich so verhält.
Ich habe den Reboot gerade gegeben. Das System kam nicht wieder.
Dann habe ich über das Kundencenter einen (harten? weiß ich nocht nicht genau) Reset ausgelöst.
*Schwitz* *BluBluBlöutdruck* Wenn das der Doc wüsste, würde er gleich die Leitung kappen lassen.Nach zwei Minuten war "er" dann wieder da...
Aber /proc war keinesfalls leer und find verurschte dieselbe (oder ist es nur die gleiche?) Meldung.
Ok, da muss ich wohl noch stricken.
Eigentlich wollte ich heute ImageMagick und die API-Extension für PHP installieren.
Kennt sich schon jemand mit dieser MagicWand API aus?Danach sollten die VirtHosts vorbereitet werden und anschließend Typo3 auf einem eingerichtet werden, soweit das ohne DNS möglich ist. Bis Dienstag sollte das eigentlich fertif sein...
Liebe Grüße
Tom vom Berg
--
Nur selber lernen macht schlau
-
hallo Tom,
/proc war keinesfalls leer
Nein, nach dem Booten ist es das nicht, da hat Christian absolut recht.
und find verurschte dieselbe (oder ist es nur die gleiche?) Meldung.
find ist nicht dran schuld. Aber vielleicht solltest du schauen, ob du erstmal einen neuen Kernel bauen kannst.
Grüße aus Berlin
Christoph S.
-
Hello,
find ist nicht dran schuld. Aber vielleicht solltest du schauen, ob du erstmal einen neuen Kernel bauen kannst.
Das übersteigt leider meinen momentanen Horizont, wie ich das remote anstellen kann.
Ich habe keinerlei konkrete Infos über die Maschine.Liebe Grüße
Tom vom Berg
--
Nur selber lernen macht schlau
-
-
-
Hallo Christoph,
Zumal Deine Aussage, dass das nach dem Booten geleert ist, weiterhin falsch ist
Das wäre sie - aber ich habe gesagt, "nach dem shutdown", und bisher bin ich davon ausgegangen, daß sich das tatsächlich so verhält.
Du hast gesagt:
/proc sollte bei einem Neustart während des shutdown erstmal völlig geleert werden.
Und die Aussage ist schlicht und ergreifend sinnlos im Falle von /proc, weil /proc (außer man kopiert's von Hand) NIEMALS durch irgendwelche Daten auf der Platte repräsentiert wird. /proc ist ein virtuelles (!) Dateisystem, das eine Schnittstelle zum Kernel ist. Die Dateien dahinter gibt es einfach nicht, der Kernel tut nur so, als ob sie da wären. Da wird biem Shutdown nichts "geleert" oder ähnliches. Das Dateisystem wird beim Herunterfahren vermutlich ausgehängt (muss aber nicht sein), das ist aber kein "reinigender Effekt" analog zum Leeren von /tmp, wie Du mit Deiner Aussage in dem Kontext (d.h. nach der Frage, ob Tom gebastelt hätte) implizieren willst - dem Kernel ist es egal, wo oder wie oft das Dateisystem "proc" gemountet ist, wenn es geomuntet ist, dann stehen Informationen zur Verfügung, wenn nicht, dann nicht, aber ein mount/umount auf dieses Dateisystem ändert nichts am Zustand dieser Informationen.
Viele Grüße,
Christian
-
-
-
-
-