PID wird nicht angelegt

[Christoph Schnauß]

hallo Forum,

manchmal gibts doch sehr merkwürdige Dinge. Ich hatte auf einem FreeBSD-Rechner eine Weile einen Apache laufen, der brav gearbeitet hat. Heute will das gute Stück nicht mehr. Es liegt daran, daß er aus welchen Gründen auch immer keine PID anlegt und demzufolge kein zuständiger Prozess angeschubst werden kann.
Sowas hatte ich noch nie. Hab ihn mal komplett deinstalliert, wieder neu installiert  -  nix. Kein Prozeß und also keine Prozeßnummer. Was mache ich da?

Grüße aus Berlin

Christoph S.

[Fabian St.]

Hi Christoph!

manchmal gibts doch sehr merkwürdige Dinge. Ich hatte auf einem FreeBSD-Rechner eine Weile einen Apache laufen, der brav gearbeitet hat. Heute will das gute Stück nicht mehr. Es liegt daran, daß er aus welchen Gründen auch immer keine PID anlegt und demzufolge kein zuständiger Prozess angeschubst werden kann.
Sowas hatte ich noch nie. Hab ihn mal komplett deinstalliert, wieder neu installiert  -  nix. Kein Prozeß und also keine Prozeßnummer. Was mache ich da?

Ich weiß jetzt nicht so genau, wie es unter FreeBSD läuft, aber wie startest du deinen Apache? Über ein Init-Skript oder direkt in der Kommandozeile mit apache -k start? Hat der Benutzer, mit dem du den Apache startest, Schreibrechte auf das Verzeichnis (meist /var/run/), wo die PID-File angelegt werden soll? Steht irgendwas in der error_log bei LogLevel debug?

Grüße,
Fabian St.

[Christoph Schnauß]

hallo Fabian,

aber wie startest du deinen Apache?

Das ist wurscht - hab alle bekannten Varianten probiert.

Hat der Benutzer, mit dem du den Apache startest, Schreibrechte auf das Verzeichnis (meist /var/run/)

Es gibt da noch gar keinen Benutzer (Apache startet grundsätzlich als root), weil der Rechner ihn bereits mit dem System hochfährt, noch bevor sich irgendjemand einloggt. dmesg zeigt auch brav "httpd started", aber das ist schlicht gelogen.

Steht irgendwas in der error_log bei LogLevel debug?

Leider nicht. Es wird gar kein log angelegt, da der Apache gar nicht erst loslegt ohne Prozeß.

Grüße aus Berlin

Christoph S.

[Fabian St.]

Hi Christoph!

aber wie startest du deinen Apache?

Das ist wurscht - hab alle bekannten Varianten probiert.

OK. Dann kann ein fehlerhaftes Init-Skript ausgeschlossen werden (das war bei mir einemal der Fall).

Hat der Benutzer, mit dem du den Apache startest, Schreibrechte auf das Verzeichnis (meist /var/run/)

Es gibt da noch gar keinen Benutzer (Apache startet grundsätzlich als root), weil der Rechner ihn bereits mit dem System hochfährt, noch bevor sich irgendjemand einloggt. dmesg zeigt auch brav "httpd started", aber das ist schlicht gelogen.

Du lässt den Apache also von INIT starten?
Ansonsten hätte ich da noch eine Idee: Findest du etwas in der Ausgabe von

~# strace apache2 -k start

das auf ein Problem hinweisen könnte? Wenn dies ebenfalls nichts bringt, weiß auch ich leider nicht mehr weiter.

Grüße,
Fabian St.

[Christoph Schnauß]

hallo Fabian,

~# strace apache2 -k start

strace: command not found

(ist eben ein Linux-Befehl aus der bash, wenn ich das richtig verstanden habe)

:-(

Grüße aus Berlin

Christoph S.

[Fabian St.]

Hi Christoph!

~# strace apache2 -k start

strace: command not found

(ist eben ein Linux-Befehl aus der bash, wenn ich das richtig verstanden habe)

:-(

Dann installiere dir es doch über das Ports-System. Es würde mich ziemlich wundern, wenn es das nicht auch für FreeBSD geben würde (zumindest tauchen in Google einige Treffer der FreeBSD-Mailingliste auf, wo auch strace verwendet wird). Unter Umständen ist auch ein manuelles Kompilieren des Sourcecodes von strace erfolgreich.

Grüße,
Fabian St.

[Christoph Schnauß]

hallo Fabian,

Dann installiere dir es doch über das Ports-System.

Port:   strace-4.5.1
  Path:   /usr/ports/devel/strace
  Info:   A portable process tracer
  Maint:  [e-mail]
  B-deps: perl-5.8.6_2
  R-deps: perl-5.8.6_2
  WWW:    http://strace.sourceforge.net/

So, und wenn ich (das mit dem Kompilieren ging sehr fix) den Aufruf starte, siehts so aus:
  pc1# strace httpd -k start
  strace: open("/proc/...", ...): No such file or directory
  trouble opening proc file
  pc1#
Das ist genau das, was ich schon geschrieben habe, es existiert kein zugehöriger Prozeß bzw. er kann nicht gestartet werden. /proc existiert natürlich (als Container)

Grüße aus Berlin

Christoph S.

[Fabian St.]

Hi Christoph!

Dann installiere dir es doch über das Ports-System.

Port:   strace-4.5.1
  Path:   /usr/ports/devel/strace
  Info:   A portable process tracer
  Maint:  [e-mail]
  B-deps: perl-5.8.6_2
  R-deps: perl-5.8.6_2
  WWW:    http://strace.sourceforge.net/

Na siehste, ist doch alles da :-)

So, und wenn ich (das mit dem Kompilieren ging sehr fix) den Aufruf starte, siehts so aus:
  pc1# strace httpd -k start
  strace: open("/proc/...", ...): No such file or directory
  trouble opening proc file
  pc1#
Das ist genau das, was ich schon geschrieben habe, es existiert kein zugehöriger Prozeß bzw. er kann nicht gestartet werden. /proc existiert natürlich (als Container)

Wie kannst du von obiger Fehlermeldung darauf schließen, dass kein Apache-Prozess existiert? Das obige heißt doch nur, dass strace /proc nicht öffnen kann. Schau mal hier: http://lists.freebsd.org/pipermail/freebsd-ports/2004-September/016241.html

Grüße,
Fabian St.

[Christoph Schnauß]

hallo Fabian,

Wie kannst du von obiger Fehlermeldung darauf schließen, dass kein Apache-Prozess existiert?

Entschuldige, ich hätte die Ausgabe von "mount" noch dranhängen müssen.

Schau mal hier: http://lists.freebsd.org/pipermail/freebsd-ports/2004-September/016241.html

Ja, hatte ich auch schon gefunden. Macht nichts, das Problem hat sich jetzt von alleine in Wohlgefallen aufgelöst. Ich habe den gesamten Quellbaum nochmal per CVSUP synchronisiert, auf einmal geht es. Ich hätt bloß gerne kapiert, was da kaputt war und wie es dazu gekommen ist.

Grüße aus Berlin

Christoph S.

[Fabian St.]

Hi Christoph!

Wie kannst du von obiger Fehlermeldung darauf schließen, dass kein Apache-Prozess existiert?

Entschuldige, ich hätte die Ausgabe von "mount" noch dranhängen müssen.

Also war /proc auch gemounted?

Schau mal hier: http://lists.freebsd.org/pipermail/freebsd-ports/2004-September/016241.html

Ja, hatte ich auch schon gefunden. Macht nichts, das Problem hat sich jetzt von alleine in Wohlgefallen aufgelöst. Ich habe den gesamten Quellbaum nochmal per CVSUP synchronisiert, auf einmal geht es. Ich hätt bloß gerne kapiert, was da kaputt war und wie es dazu gekommen ist.

Mh, naja, das hätte mich jetzt auch interessiert, aber das wird jetzt wohl nicht mehr herauszufinden sein, woran es lag.
«strace» solltest du dir jedoch merken, ist ein ganz nützliches Programm, wenn man verstehen will, was beim Aufruf eines Programms alles passiert - auch wenn es nur ein «ls» ist ;-)

Grüße,
Fabian St.

[Christoph Zurnieden]

Hi,

Mh, naja, das hätte mich jetzt auch interessiert, aber das wird jetzt wohl nicht mehr herauszufinden sein, woran es lag.
«strace» solltest du dir jedoch merken, ist ein ganz nützliches Programm, wenn man verstehen will, was beim Aufruf eines Programms alles passiert - auch wenn es nur ein «ls» ist ;-)

Dann würde ich aber doch eher zu den passenden Tools tendieren und für FreeBSD sind das ktrace/kdump.

Und laß Dich nie wieder mit so komischen Linuxtools auf BSD erwischen! ;-)

so short

Christoph Zurnieden

[Fabian St.]

Hi Christoph!

Mensch muss man hier mit den Namen aufpassen - da kommt man ja ganz durcheinander :-)

[strace]

Dann würde ich aber doch eher zu den passenden Tools tendieren und für FreeBSD sind das ktrace/kdump.

Und laß Dich nie wieder mit so komischen Linuxtools auf BSD erwischen! ;-)

Nunja, wie gesagt, ich kenne mich mit FreeBSD nicht so aus und habe nur einmal vor einiger Zeit kurz über die Dokumentation gelesen. Da aber auch «strace» auf einigen *BSD-Listen erwähnt wurde, dachte ich, es wären eben auch in dieser Familie beheimatet... ;-)

Aber ich werds mir merken *g*

Grüße,
Fabian St.

[Christoph Zurnieden]

Hi,

Mensch muss man hier mit den Namen aufpassen - da kommt man ja ganz durcheinander :-)

Ein Grund, warum ich mich erst gar nicht darauf einlasse ;-)

Nunja, wie gesagt, ich kenne mich mit FreeBSD nicht so aus und habe nur einmal vor einiger Zeit kurz über die Dokumentation gelesen. Da aber auch «strace» auf einigen *BSD-Listen erwähnt wurde, dachte ich, es wären eben auch in dieser Familie beheimatet... ;-)

Naja, es dürfte ja auch da funtkionierne, jedoch sollte man so nah am "nacktem Metall" die hauseigenen Tools bevorzugen, die können es mitunter den entscheidenden Tick besser. Da ganz unten funktioniert nämlich ein *BSD ganz anders als GNU/Linux.
[folgte längere Abhandlung über monolithische und Microkernel, Syscalls, Posix, SysV und ähnlichen Grausamkeiten, die keine Sau interessieren -- gestrichen]

so short

Christoph Zurnieden

[Christoph Schnauß]

hallo,

[folgte längere Abhandlung über monolithische und Microkernel, Syscalls, Posix, SysV und ähnlichen Grausamkeiten, die keine Sau interessieren -- gestrichen]

äh ... bitte mal ein "unerase" drüberlaufen lassen ;-)

Grüße aus Berlin

Christoph S.

[Fabian St.]

Hi!

Naja, es dürfte ja auch da funtkionierne, jedoch sollte man so nah am "nacktem Metall" die hauseigenen Tools bevorzugen, die können es mitunter den entscheidenden Tick besser. Da ganz unten funktioniert nämlich ein *BSD ganz anders als GNU/Linux.
[folgte längere Abhandlung über monolithische und Microkernel, Syscalls, Posix, SysV und ähnlichen Grausamkeiten, die keine Sau interessieren -- gestrichen]

Ehrlich gesagt würde mich das schon interesssieren - gibt es das irgendwo zum Nachlesen, damit du dir nicht die Finger wundschreiben müsstest? ;-)

Grüße,
Fabian St.

[Christoph Zurnieden]

Hi,

[folgte längere Abhandlung über monolithische und Microkernel, Syscalls, Posix, SysV und ähnlichen Grausamkeiten, die keine Sau interessieren -- gestrichen]

Ehrlich gesagt würde mich das schon interesssieren - gibt es das irgendwo zum Nachlesen, damit du dir nicht die Finger wundschreiben müsstest? ;-)

Gut, bevor ich mich von euch noch schlagen lasse ;-)

Der Unterschied zwischen monolithischem und Microkernel ist noch einfach, zumindest das Prinzip: der monolithische Kernel besteht, wie der Name schon anzudeuten versucht, aus einem Stück. So wie Linux. Das es dort Module gibt spielt keine Rolle, da die im Bedarfsfalle fest an den Kernel angehangen werden im Gegensatz zum -> Microkernel, wo es nur einen kleine Kernel für's Nötigste gibt -- den _Micro_kernel eben -- der sich mit den Geräte-und anderen Treibern über einen gesonderten Kommunikationskanal austauscht. Der monolithische Kernel ist daher schneller (der Unterschied ist aber schon seit langem nur noch marginal) und einfacher zu basteln, der Mikrokernel dagegen eleganter und stabiler, ein abstürzender Treiber sollte rein theoretisch den Kernel nicht mitreißen können.

Syscalls sind die Aufrufe von Kernelfunktionen.
Nur mal als Eselsbrücke und um die Namensunterschiede zu erklären, die eigentlich gar keine sind:
strace = _s_ystem call _trace_
ktrace = _k_ernel _trace_

Was war da noch? Ach ja, SysV und Posix. System V ist eine relativ proprietäre Betriebssystemumgebung und -standard, Posix (eine Mischung aus SysV und BSD) dagegen ein öffentlicher. Siehe die Links rechts auf http://posixtest.sourceforge.net/

"ähnliche Grausamkeiten"? Nein, es lesen Kinder und Jugendliche mit >;->

Ich hoffe in der Kürze keine wesentlichen Fehler außer Rechtschreibfehlarn gemacht zu haben.

so short

Christoph Zurnieden

[Christoph Schnauß]

hallo,

Der Unterschied zwischen monolithischem und Microkernel ist noch einfach [...]

Hm, das liest sich so, als ob du die zugehörige Seite in der Wikipedia verfaßt hättest. Aber: Sowohl die *BSD wie auch Linux nutzen zumindest "generisch" monolithische Kernel, Linux eher einen hybrid monolithischen, weil eben die Module dazukommen können. Microkernel gibt es bei Mac OS und Beos (Zeta).

Nur mal als Eselsbrücke und um die Namensunterschiede zu erklären, die eigentlich gar keine sind:
strace = _s_ystem call _trace_
ktrace = _k_ernel _trace_

Oh, gut. Da hätte ich jetzt zwei Sätze mehr gebraucht. Ich habe versäumt, auf ktrace hinzuweisen, weil ich mir nun extra strace dazuinstalliert hatte, um Fabian die Ausgabe zeigen zu können.

Ich hoffe in der Kürze keine wesentlichen Fehler außer Rechtschreibfehlarn gemacht zu haben.

Ich habe nur einen Rechtschreibfehler entdeckt  -  und das ist eher ein Tipp- als ein echter Rechtschreibfehler ;-)

Grüße aus Berlin

Christoph S.

[Christoph Zurnieden]

Hi,

Der Unterschied zwischen monolithischem und Microkernel ist noch einfach [...]

Hm, das liest sich so, als ob du die zugehörige Seite in der Wikipedia verfaßt hättest.

Wollte ich sogar erst noch verlinken, aber das stimmt alles nicht so ganz, was da steht.

Aber: Sowohl die *BSD wie auch Linux nutzen zumindest "generisch" monolithische Kernel, Linux eher einen hybrid monolithischen, weil eben die Module dazukommen können.

Linux fehlt jedoch der getrennte Kommunikationskanal, die Module werden einfach reingelinkt. Microkernel haben ihn.

FreeBSD nutzt übrigens den Mach-Kernel. Kannst' auch Debian drauf laufen lassen.

Microkernel gibt es bei Mac OS und Beos (Zeta).

Na, selbst der Mach ist keine reine Lehre mehr. Microkernel sind mittlerweile alles Hybridteile, vielleicht wird der L4 wieder reine Lehre, aber dafür wird der ja auch nie was >;->

Nur mal als Eselsbrücke und um die Namensunterschiede zu erklären, die eigentlich gar keine sind:
strace = _s_ystem call _trace_
ktrace = _k_ernel _trace_

Oh, gut. Da hätte ich jetzt zwei Sätze mehr gebraucht.

Ähm ... ja, welche denn? Was möchtest Du denn wissen? Aufruf steht in der Manpage, die Analyse der Ausgabe würde hingegen das Posting sprenge, deshalb bräuchte ich schon ein paar detailierte Fragen.

so short

Christoph Zurnieden

PS:
Mir stürzt der Konqueror (allerdings noch 3.2.1) bei de.wikipedia.org hin und wieder sogar total ab. Teilweise sogar nachvollziehbar. Was die da anstellen mögen ... ;-)
CZ

[Christoph Schnauß]

hallo,

PS:
Mir stürzt der Konqueror (allerdings noch 3.2.1) bei de.wikipedia.org hin und wieder sogar total ab. Teilweise sogar nachvollziehbar. Was die da anstellen mögen ... ;-)

Siehe https://forum.selfhtml.org/?t=108679&m=677357. Betrifft Konqueror 3.3.x und 3.4

Grüße aus Berlin

Christoph S.

[Christoph Zurnieden]

Hi,

Posting um 02:41? Auch abends noch Spargel gegessen? ;-)

Siehe https://forum.selfhtml.org/?t=108679&m=677357. Betrifft Konqueror 3.3.x und 3.4

Ja, darauf bezog ich mich. Wollte mich aufgrund des Alters meines Browser aber nicht direkt einmischen.

Aber was ist denn jetzt mit dem merkwürdigem Fehler? Hätte mich und bestimmt auch noch andere durchaus brennend interessiert, woran's gelegen hat!

so short

Christoph Zurnieden

[Christoph Schnauß]

hallo,

Aber was ist denn jetzt mit dem merkwürdigem Fehler? Hätte mich und bestimmt auch noch andere durchaus brennend interessiert, woran's gelegen hat!

Ich weiß es wirklich nicht. In der NG wurde mir nur erklärt, daß sowas schonmal vorkommen kann bei CURRENT

Grüße aus Berlin

Christoph S.

[Christoph Zurnieden]

Hi,

Ich weiß es wirklich nicht. In der NG wurde mir nur erklärt, daß sowas schonmal vorkommen kann bei CURRENT

Schad'! Naja, kann man nix machen, muß man wohl doch selber in die Quellen tauchen ;-)

so short

Christoph Zurnieden

[Fabian St.]

Hi Christoph!

Ehrlich gesagt würde mich das schon interesssieren - gibt es das irgendwo zum Nachlesen, damit du dir nicht die Finger wundschreiben müsstest? ;-)

Gut, bevor ich mich von euch noch schlagen lasse ;-)

Hier wird doch niemand gleich handgreiflich *g*

Der Unterschied zwischen monolithischem und Microkernel ist noch einfach, zumindest das Prinzip: der monolithische Kernel besteht, wie der Name schon anzudeuten versucht, aus einem Stück. So wie Linux. Das es dort Module gibt spielt keine Rolle, da die im Bedarfsfalle fest an den Kernel angehangen werden im Gegensatz zum -> Microkernel, wo es nur einen kleine Kernel für's Nötigste gibt -- den _Micro_kernel eben -- der sich mit den Geräte-und anderen Treibern über einen gesonderten Kommunikationskanal austauscht. Der monolithische Kernel ist daher schneller (der Unterschied ist aber schon seit langem nur noch marginal) und einfacher zu basteln, der Mikrokernel dagegen eleganter und stabiler, ein abstürzender Treiber sollte rein theoretisch den Kernel nicht mitreißen können.

Danke für die Ausführungen. Windows hätte demnach also einen Microkernel, oder?

Syscalls sind die Aufrufe von Kernelfunktionen.
Nur mal als Eselsbrücke und um die Namensunterschiede zu erklären, die eigentlich gar keine sind:
strace = _s_ystem call _trace_
ktrace = _k_ernel _trace_

OK, das ist nun auch klar und wieder ein Beweis, dass nicht jedes Programm, dass mit einem «k» anfängt, was mit KDE zu tun haben muss ;-)

"ähnliche Grausamkeiten"? Nein, es lesen Kinder und Jugendliche mit >;->

Soll das eine Anspielung sein, dass ich erst 16 bin? *fg*

Grüße,
Fabian St.

[Christoph Zurnieden]

Hi,

Gut, bevor ich mich von euch noch schlagen lasse ;-)

Hier wird doch niemand gleich handgreiflich *g*

Nein, _sofort_ nicht, da hast Du schon Recht.

Danke für die Ausführungen. Windows hätte demnach also einen Microkernel, oder?

Die Kausalität kann ich zwar nicht so ganz nachvollziehen, aber die Windows-NT Reihe hat einen Microkernel, ja.

"ähnliche Grausamkeiten"? Nein, es lesen Kinder und Jugendliche mit >;->

Soll das eine Anspielung sein, dass ich erst 16 bin? *fg*

Nein, das _Lebens_alter interessiert mich nicht. Höchstens noch beim weiblichem Geschlecht, aber da auch nur aus strafrechtlichen Gründen.

so short

Christoph Zurnieden

[Fabian St.]

Hi Christoph!

Gut, bevor ich mich von euch noch schlagen lasse ;-)

Hier wird doch niemand gleich handgreiflich *g*

Nein, _sofort_ nicht, da hast Du schon Recht.

Und wenn, dann gibt es _immer_ sehr gute Gründe ;-)

Danke für die Ausführungen. Windows hätte demnach also einen Microkernel, oder?

Die Kausalität kann ich zwar nicht so ganz nachvollziehen, aber die Windows-NT Reihe hat einen Microkernel, ja.

Das „demnach” bezog sich auf deine Erklärungen, aber ich fand es angebracht, mich zuerst zu bedanken... Ich hoffe, die Kausalkette hiermit geschlossen zu haben *g*

Soll das eine Anspielung sein, dass ich erst 16 bin? *fg*

Nein, das _Lebens_alter interessiert mich nicht. Höchstens noch beim weiblichem Geschlecht, aber da auch nur aus strafrechtlichen Gründen.

Das lasse ich jetzt mal unkommentiert :-D

Grüße,
Fabian St.

[Gero Takke]

Hallo Christoph,

manchmal gibts doch sehr merkwürdige Dinge. Ich hatte auf einem FreeBSD-Rechner eine Weile einen Apache laufen, der brav gearbeitet hat. Heute will das gute Stück nicht mehr. Es liegt daran, daß er aus welchen Gründen auch immer keine PID anlegt und demzufolge kein zuständiger Prozess angeschubst werden kann.

Eine PID ist eine Prozess-ID, keine Datei. Es gibt pidfiles, in denen die Prozess-IDs noch einmal der Einfachheit halber drinstehen, haeufig unter /var/run.
Was passiert in Deinem Fall genau? Kann er die Datei nicht anlegen, oder kann er keinen Prozess starten?
Wo bist Du ueber das Wort "PID" gefallen? Poste doch mal die genauen Fehlermeldungen, sonst kann man Dir nicht weiterhelfen.

Viele Gruesse,
Gero

[Christoph Schnauß]

hallo Gero,

Poste doch mal die genauen Fehlermeldungen, sonst kann man Dir nicht weiterhelfen.

Es gibt keine Fehlermeldungen. Startaufruf beispielsweise mit
  httpd -k start
ergibt keine Fehlermeldung.
  httpd -t
ergibt
  Syntax OK
Im Browser gibts dann eine Fehlermeldung der Art:
  Beim Laden von http://localhost/ ist folgender Fehler aufgetreten:
  Keine Verbindung zu Rechner localhost.
Sämtliche Einträge in der /etc/hosts sind erfolgt und korrekt. Versuche ich es jetzt mit
  httpd -k restart
kommt:
  httpd not running, trying to start
Versuche ich es mit
  httpd -k stop
kommt:
  httpd (no pid file) not running
Und tatsächlich existiert unter /var/run kein PID-File. Auch ps bzw. ps -ax zeigt keinen laufenden Prozeß. Wesentlich mehr Diagnose weiß ich auch nicht. logs (error_log) gibt es gar nicht, da der Apache gar nicht erst startet. Neuinstallation aus dem port hat nicht geholfen, portupgrade ist erfolgreich drübergelaufen, irgendwas gelöscht habe ich nicht.

Grüße aus Berlin

Christoph S.