Lösung: Suse 9.1 -> Apache2 ->PHP4 -> _kein_ Start

Ich habe am Samstag Suse 9.1 auf meinem Laptop installiert, bis jetzt funktioniert alles ganz gut.
Nur kann ich keinen Lamp Server aufsetzen, sobald ich das PHP4 Modul installiere läßt sich Apache2 nicht mehr starten. Ohne PHP4 Modul funktioniert Apache2.
In der Datei messages werden keine Fehler angezeigt,
in /etc/var/log/apache2/error_log steht folgendes:
[notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec2)

Weiß jemand einen Rat?


Gruß Christoph

chrleh schrieb:

Ich habe am Samstag Suse 9.1 auf meinem Laptop installiert, bis jetzt funktioniert alles ganz gut.
Nur kann ich keinen Lamp Server aufsetzen, sobald ich das PHP4 Modul installiere läßt sich Apache2 nicht mehr starten. Ohne PHP4 Modul funktioniert Apache2

Zum Vergrößern anklicken....

Kommt irgendeine Fehlermeldung? Ich habe ja auch ein Problem (siehe Post), das ich Apache2 nicht starten kann. Vielleicht ist es ja das gleiche :?:

Gruss Bram

Habe 3 update von 9.0 gemacht - keine Probleme mit Apache und PHP4 Modul

chrleh schrieb:

Nur kann ich keinen Lamp Server aufsetzen, sobald ich das PHP4 Modul installiere läßt sich Apache2 nicht mehr starten. Ohne PHP4 Modul funktioniert Apache2.

Zum Vergrößern anklicken....

Siehe auch folgendes posting:
http://www.linux-club.de/viewtopic.php?t=6207

Nachdem ich einen Lösung für mein Problem gesucht habe, habe ich dein Posting gelesen - und siehe da ich kann dein beschriebenes Verhalten bei genau reproduzieren - ohne php4-Modul (also auch ohne phpMyAdmin) lässt sich apache2 starten, sonst nicht :-((

Jetzt muss ich mal die SuSE Mailingliste durchsuchen ... vielleicht gibt es dort ja eie Lösung

Gruß
kroe

kroe schrieb:

Jetzt muss ich mal die SuSE Mailingliste durchsuchen ... vielleicht gibt es dort ja eie Lösung

Zum Vergrößern anklicken....

Dort gibt es zwar einen langen thread genau zu diesem Thema allerdings bislang fast ohne Ergebnis (s.u.) - also ohne apache2-mod_php4 funktioniert es aber mit lässt sich der apache nicht starten :-(

Das ist doch sch....

Btw. einer hat gepostet, dass er nach der x-ten Neuinstallation mal als filesystem ext3 auprobiert hätte und damit sei es gegangen (logisch erschien ihm das alleings auch nicht) - und das hat noch jemand ausprobiert und es funktioniert; siehe: http://www.linux-club.de/viewtopic.php?t=6144
(aber das ist wirklich eine unschöne Lösung :-( )

Viele Grüße
kroe

Hallo Liste,
habe hier das gleiche Problem. apache2 lässt sich nur mit MPM=worker, oder als MPM=prefork nur ohne PHP starten.
Auf einem anderen Rechner funktioniert es aber komischerweise.
Nun meine Frage: bewegt Ihr Euch alle auf einer ATHLON-Plattform?
Auf dem Athlon habe ich das apache Problem. Auf einem dual-P3 nicht.

Mir ist auch aufgefallen, dass es auf der SuSE 9.1 keinen speziellen Athlon-Kernel mehr gibt - nur noch default und SMP.
Bringt vielleicht ein selbstgebauter Athlon Kernel was?

Ich hab mein Problem ja schon in einem anderen Posting beschrieben (nämlich genau das selbe).

Folgendes habe ich in der Zwischenzeit festgestellt:

Auf meinem Laptop (athlonXP2000+) funzt es nicht.
Mit EXT3 auf dem Laptop funzt es auch nicht.
Auf meinem PC (Athlon 1900+) funzt es tadellos - mit genau derselben Installation(auch mit RaiserFS) - inkl. phpMyAdmin.

Das Problem muss also irgendwie auf den Athlon-Mobile bezogen sein.

Komische Gschicht :x

Hoffe da findet einer mal ne Lösung :?:

Gruß

Klaus

Hallo Liste,
also am kernel liegt es glaube ich nicht.
Habe mir gerade einen Athlon-Kernel gebacken und es funktioniert trotzdem nicht.

Ein Versuch php neu zu bauen via src.rpm schlägt auch fehl, da die SuSE-developer Pakete als required definieren, die es unter 9.1 gar nicht mehr gibt (z.B. apache-devel).
Alles in allem bin ich ziemlich angepisst und gelange immer mehr zu der Überzeugung, dass es besser gewesen wäre, die schöne Kohle in irgendetwas Sinnvolles zu stecken.
In Zukunft werde ich wohl die Finger von den .1-SuSE-Distributionen die Finger lassen, da gab's auch in der Vergangenheit immer Probleme.

Hallo Liste!
Mir gehts genauso, es will einfach nicht funktionieren. Aber es besteht Hoffunug, ich hatte mit SuSe telefoniert und die sagten mir, daß es wohl einen Patch zu diesem Problem geben werde. Wann?, wie? und warum das Problem überhaupt auftritt ??? - naja vielleicht löst es ja vorher jemand anderes!
ciiao devildoll

Hallo Liste,
bin dem Problem weiter auf der Spur und habe folgendes festellen können.
Ein "strace rcapache2 start" liefert auf einem funktionierendem System folgendes zurück:

---- schnipp ----
waitpid(-1, 0xbfffe734, WNOHANG) = -1 ECHILD (No child processes)
sigreturn() = ? (mask now [])
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
write(1, "\0337\33[?25l\r\33[80C\33[10D\33[1;32mdone\33["..., 43 done
) = 43
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
read(255, "\n\n# Inform the caller not only v"..., 8192) = 73
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
munmap(0x401fe000, 4096) = 0
exit_group(0) = ?


Auf einem nicht funktionierendem System folgendes:

---- schnipp ----

waitpid(-1, 0xbfffe7a4, WNOHANG) = -1 ECHILD (No child processes)
sigreturn() = ? (mask now [])
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
fcntl64(1, F_GETFD) = 0
fcntl64(1, F_DUPFD, 10) = 10
fcntl64(1, F_GETFD) = 0
fcntl64(10, F_SETFD, FD_CLOEXEC) = 0
dup2(2, 1) = 1
fcntl64(2, F_GETFD) = 0
write(1, "\0337\33[?25l\r\33[80C\33[10D\33[1;31mfailed"..., 45 failed
) = 45
dup2(10, 1) = 1
fcntl64(10, F_GETFD) = 0x1 (flags FD_CLOEXEC)
close(10) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
read(255, "\n\n# Inform the caller not only v"..., 8192) = 73
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
munmap(0x40202000, 4096) = 0
exit_group(7) = ?


Der Fehler liegt offensichtlich in einem falschen syscall fcntl64().
Also hier sind Gurus gefragt. Bin mit meinem Latein am Ende.

Also ich hab das gleiche Problem. Hab gerade mal eine Supportanfrage an SuSE gestellt. Muss ja wohl eine Möglichkeit geben den Mist zum laufen zu bringen.

Es folgt die unsaubere (aber funktionierende) Lösung:

Umbenennen der /usr/lib/librecode.so.0

In was soll die umbenannt werden? oder ist das egal?

Hallo Liste,

ja in was soll die denn umbenannt werden. Ich will jetzt endlich mal meinen apache haben, grrrr

keulator schrieb:

ja in was soll die denn umbenannt werden.

Zum Vergrößern anklicken....

Ich habe das jetzt mal getestet und es funktioniert
einfach mv /usr/lib/librecode.so.0 /usr/lib/librecode.so.0_orig (oder irgendwie anders benennen ist ja sowieso nur ein symlink).

Vielen Dank an heinnoon , aber wie soll ein normaler Mensch da drauf kommen ;-) ?

Viele Grüße
kroe

Hallo Liste,
kann noch eine andere Lösung anbieten:
per Yast2 alle apache2 und php-Pakete deinstallieren und dann per Yast2 wieder alle apache2 und php-Pakete reinstallieren.
dann lässt sich apache2 mit prefork und php starten (zumindest bei mir).
Leider musste ich dann feststellen, dass offensichtlich einige php-Funktionen fehlen oder nicht funktionieren (z.B. mysql_connect() ).
Hat jemand anderes auch schon diese Erfahrung gemacht ?

Nachdem dann apache endlich am Laufen war, hab' ich dann mal die USB-Unterstützung getestet.
Für alle, die das auch probiren wollen kann ich nur sagen: viel Vergnügen.

Fazit: SuSE 9.1 ist ein klassischer Fall für den Mülleimer und schade um's Geld. Werde mich mal nach was anderem umsehen

Das is voll zum brechen! Alles lief so wunderbar bis auf der behämmerte Schoschone mit PHP4 :twisted:
Es is bei mir auch das Problem mit der librec, ich habe sie umbenannt und dann lief er zwar, dafür funktionierte der mail() Befehl nicht, obwohl Postfix vor PHP installiert wurde :x

So etwas hätte ich nicht von SuSE erwartet! Ich habe die Kiste 3 mal Platt gemacht um sicherzustellen, das ich keinen Mist gebaut habe, aber wenn man hier die Beiträge liest, ist meiner ja kein Einzelfall

Ich hätte viel lieber meien Apachen/Comanchen/Schonen 1.3.x behalten, denn der funzte wenigsten immer zuverlässig!
Hab eben eine bitterböse Mail an den Support von SuSE geschickt :twisted:

Aufmerksam habe ich alle Comments gelesen und in der Zwischenzeit mehrfach installiert:

Und ... es geht, und zwar habe ich:

PC (AthlonXP2500+) mit ASROCK Board: SATA, RAID

Und ich wollte Samba und Apache+php4, MySQL, DNS, etc.:

Auf Hinweise hin wie folgt installiert:

hda1 = EXT3(/), hda2 = SWAP(swap) und hda3 = REISERFS (/home ?)
Minimal System(engl.) und dazu den kl. WebServer ohne php4-Modul.
Ende Install. Es funktioniert tadellos - anschliessend Installation ergänzt durch Gnome und
was auch immer inkl. phpMyAdmin.
Klappt immer noch, all Systems running!

Das dürfte einige eurer Annahmen über Board werfen(Athlon)! Hoffe es hilft euch ein wenig und das GrünePacket bekommt,
teuer erworben, doch noch nen Sinn!

Gruß

Wenn mas von Anfang an ohne PHP installiert, tritt der Fehler nicht auf, da die Fehlerquelle die php-recode Libary ist

Aber ohne php bringt mir das niX -> Lamp :roll:

Hier die offizielle Antwort von SuSE:

http://portal.suse.com/sdb/de/2004/05/fhassel_php4_91.html

Gruß

Medic