/usr/sbin/apachectl restart: configuration broken, ignoring restart

0lli

0lli

Registered User
hallo,

habe einen vserver.de. augenblickliche uptime 7days 5 minutes
(obwohl ich diesen reboot vor 7 Tagen nicht angefordert habe!
es muss der s4y umzug gewesen sein.)

am 20-Mai, nachdem ich das access_log gzip-ed hatte,
habe ich mit "apachectl restart" den access_log wieder aktiviert, was auch funktioniert hat. heute sehe ich in /var/log/httpd

-rw-r--r-- 1 root root 0 May 30 03:01 access_log

size 0, das ist komisch. ich mache also

# apache restart
/usr/sbin/apachectl restart: configuration broken, ignoring restart
/usr/sbin/apachectl restart: (run 'apachectl configtest' for details)
# apachectl configtest
PHP Fatal error: Unable to start session mm module in Unknown on line 0

das ist noch komischer.

sonst scheint alles prima zu laufen. traffic ist auch normal.
und es sind ueber 400MB free disk space.

waere schoen, wenn jemand so freundlich waere, mir zu sagen, ob nun ein reboot notwendig ist oder was man sonst tun koennte.

ciao 0lli
 
disk size heute 422M statt 1024M! "df -h"

hallo,

nochmal dazu.

sehe gerade mit "df -h", dass disk size heute 422M statt 1024M!

Filesystem Size Used Avail Use% Mounted on
vzfs 422M 412M 9.7M 98% /

also loeschen wir mal ein file:

-rw------- 1 root root 7057020 Jun 1 08:39 root.gz

# rm root.gz
rm: remove `root.gz'? y

]# df -h
Filesystem Size Used Avail Use% Mounted on
vzfs 412M 406M 6.6M 99% /

und ohne was anderes zu machen, gleich danach nochmal,
weil es so unglaublich ist, und siehe da schon ein wenig besser :-):

# df -h
Filesystem Size Used Avail Use% Mounted on
vzfs 461M 406M 55M 88% /

mehr wird's leider nicht, bei nochmaligem "df -h".

was ist passiert mit der disk size?

ciao 0lli
 
disk size wieder normal, aber apachectl restart geht immernoch nicht

hi,

sehe gerade mit "df -h",
disk size ist jetzt wieder groesser, aber immernoch nicht korrekt (size 740M, used 394M) und apachectl restart geht immernoch nicht.

kann es sein, am 30.mai war die disk size auch zu klein
und der available space gegen null und das fuehrte zu dem
fehler.

wie kann man ein webserver reload auf der shell machen?

(dies im confixx angefordert, wurde nie ausgefuehrt.
ich musste bisher immer manuell ./confixx_counterscript.pl
aufrufen.)

p.s.: ich habe noch die urspruengliche konfiguration des vserver.de

so meldet es sich:

Apache/1.3.23 (Unix) (Red-Hat/Linux) mod_ssl/2.8.7 OpenSSL/0.9.6b PHP/4.1.2

ciao 0lli
 
Last edited by a moderator:
wegen dem counterskript musst du unter user root
crontab -e

diese zeile einfügen:
*/1 * * * * /root/confixx/confixx_counterscript.pl

dann läuft das counterskript wie es laufen soll
 
Last edited by a moderator:
0lli said:
Unable to start session mm module
Click to expand...
Du hast Probleme mit der libmm. (siehe auch hier)

Such das passende mm-Packet zu Deinem Linux auf rpmseek.com.

Wegen dem 'df': Es ist ein vServer und damit auch nur eine virtuelle Platte. Die variiert regelmässig. Dennoch solltest Du immer den versprochenen Platz haben, solange Du ihn anforderst.

huschi.
 
Last edited by a moderator:
libmm?

hallo,

danke fuer deine antwort. auf rpmseek.com finden ich:

libmm-1.3.0-alt2.i586.rpm Alt Linux Sisyphus 1.3.0 alt2 i586
libmm-1.3.0-alt2.src.rpm Alt Linux Sisyphus 1.3.0 alt2 i686
libmm-1.2.2-alt1.i586.rpm Alt Linux 2.2 1.2.2 alt1 i586
libmm-1.2.2-alt1.src.rpm Alt Linux 2.2 1.2.2 alt1 i686
libmm-1.1.3-ipl3mdk.i586.rpm Alt Linux 2.0 1.1.3 ipl3mdk i586
libmm-1.1.3-ipl3mdk.src.rpm Alt Linux 2.0 1.1.3 ipl3mdk i686
libmm-1.1.3-ipl4mdk.i586.rpm Alt Linux 2.0 Updates 1.1.3 ipl4mdk i586
libmm-1.1.3-ipl4mdk.src.rpm Alt Linux 2.0 Updates 1.1.3 ipl4mdk i686

das sagt mir leider garnichts. soll da eines davon passen?

und warum soll libmm jetzt probleme machen, wo ich
doch garnichts am server geaendert habe!?!

ciao 0lli
 
hmmmm, schonmal deine httpd.conf angeschaut?

die libmm brauchst du für redhat (7.3 oder 9 - was auch immer du hast)
 
Last edited by a moderator:
0lli said:
und warum soll libmm jetzt probleme machen, wo ich
doch garnichts am server geaendert habe!?!
Click to expand...
Das sagen sie aaaaaalllllllleeeeeee.....
;)

Bei rpmseek mußt Du die 'erweiterte Suche' nehmen, RedHat anklicken und 'mm' als Packet suchen (oder 'libmm.so' als 'in Packet enthalten').

Du kannst natürlich auch vorher Deine eigenen Version überprüfen:
rpm -q mm

huschi.
 
Huschi said:
Wegen dem 'df': Es ist ein vServer und damit auch nur eine virtuelle Platte. Die variiert regelmässig. Dennoch solltest Du immer den versprochenen Platz haben, solange Du ihn anforderst.
Click to expand...
Bei mir(auch vserver@s4y) varriert der Speicherplatz(also das was bei df unter "Size" steht) nicht :confused:
 
was mach ich nun mit libmm?

meine disk size ist heute abend auch wieder von alleine auf's volle 1GB gegangen. (allerdings war's heute morgen
bei gut 400M mal voll! denn ich konnte ein file nicht erzeugen!
kam "error, device full"!)

anonsten soweit so gut, aber was mach ich nun mit libmm?
(ich brauche das oben genannte access_log file eigentlich nicht.)

kann ich den vserver in dem zustand wie er jetzt ist lassen?

geht ja sonst alles andere [anscheins].

ciao 0lli
 
Die libmm wird von PHP und nicht von Apache gebraucht. Und zwar - warum auch immer - für das Session-Handling.
Es scheint ja auch, daß Du eine korrekte Version drauf hast. Du siehst mich also ratlos...
Ich würde wahrscheinnlich einfach eine neue RPM drüber bügeln und schauen ob es dann funzt.
Du könntest natürlich noch die Verlinkung in /usr/lib/ prüfen.
Bei mir sehen die so aus:
Code: 
# ll /usr/lib/libmm.so*
lrwxrwxrwx    1 root     root           16 Nov  1  2003 /usr/lib/libmm.so -> libmm.so.11.0.23
lrwxrwxrwx    1 root     root           16 Jul  7  2003 /usr/lib/libmm.so.11 -> libmm.so.11.0.23
-rwxr-xr-x    1 root     root        19506 Nov 18  2003 /usr/lib/libmm.so.11.0.23
Wobei dies noch ein RH7.3 ist mit einem aktuellen mm-Packet.

huschi.
 
ll

bei mir kommt:

# ll /usr/lib/libmm.so*

lrwxrwxrwx 1 root root 16 Nov 1 2002 /usr/lib/libmm.so.11 -> libmm.so.11.0.23
-rwxr-xr-x 1 root root 19546 Jul 24 2002 /usr/lib/libmm.so.11.0.23

habe auch noch, wie oben gesagt, RH7.3
 
Das sieht so aus, als ob Dir lediglich der Link libmm.so fehlt.
Einfach mal anlegen und dann nochmal den restart probieren.
Code: 
ln -s /usr/lib/libmm.11.0.23.so /usr/lib/libmm.so

huschi.
 
link fuer /usr/lib/libmm.so gemacht

nachdem ich deinen tippfehler (durchaus verzeihbar :-) uebernommen hatte (".so" war hinten), musste ich "-f" benutzen:

# ln -s -f /usr/lib/libmm.so.11.0.23 /usr/lib/libmm.so
# ll /usr/lib/libmm.so*
lrwxrwxrwx 1 root root 25 Jun 2 09:56 /usr/lib/libmm.so -> /usr/lib/libmm.so.11.0.23
lrwxrwxrwx 1 root root 16 Nov 1 2002 /usr/lib/libmm.so.11 -> libmm.so.11.0.23
-rwxr-xr-x 1 root root 19546 Jul 24 2002 /usr/lib/libmm.so.11.0.23

das muesste also jetzt so passen.
aber es kommt immernoch derselbe fehler:

# apachectl configtest
PHP Fatal error: Unable to start session mm module in Unknown on line 0
 
am besten alles absichern und neuinstallieren lassen :)

Probier mal:
Code: 
PHP Fatal error: Unable to start session mm module in Unknown on line 0

1) Remove /tmp/session_mm.sem or give access permission to the user running php4.
2) increase the limit on shared memmory (echo "33554432" > /proc/sys/kernel/shmmax).
This is mainly needed on non-i386 archs. The default is 8MB, but that seems too low.

herein schauen -> http://bugs.php.net/bug.php?id=13595

eventl. auch mal das /tmp leeren, hoffe es hilft dir
 
Last edited by a moderator:
Sorry für den Tippfehler, aber schau mal auf die Uhrzeit... Gääääähn. ;)
Wenn Du -f nutzen mußtest, dann existierte der Link bereits. Dann stimmte aber die Ausgabe von 'll /usr/lib/libmm*' nicht... :confused:

Egal. Dein Problem besteht ja noch immer.
Bei google habe ich diese PHP-Bugs-Seite gefunden:
http://bugs.php.net/bug.php?id=13595
Darin sind vorallem folgende Vorschläge:
a)
rm /etc/session_mm.sem (falls vorhanden)
oder
rm /tmp/sess*

b)
strace -e trace=file -o output /usr/sbin/apache -X
und schauen was eigendlich schief läuft.
(evtl. in einer 2.Shell den Restart ausführen.)

c)
Resultat aus b) war bei einem ein fehlerhafter Eintrag in der php.ini:
session.save_path=/dev/null

d)
Tritt der Fehler auch auf, wenn Du PHP als CLI nutzt?

huschi.
 
hey huschi :) lies mal den post über dir :) das gleiche steht dort doch auch :
 
Last edited by a moderator:
Hey Society,
<MOD>es wäre schön, wenn Du die Quotes immer auf das wesentliche kürzen könntest oder ganz wegläßt. Das macht das Lesen der Beiträge deutlich einfacher.</MOD>

Und zur Entschuldigung:
Ich habe kurz nach Olli's posting angefangen zu antworten, bin aber (beruflich) abgelenkt worden, so daß ich über eine halbe Stunde im Editor hängen geblieben bin...
Du warst halt schneller... ;)

huschi.
 
danke fuer eure recherchen und antworten.

1. habe in /tmp alle 4 session files geloescht.

2. in /etc/php.ini steht

session.save_path = /tmp

> d) Tritt der Fehler auch auf, wenn Du PHP als CLI nutzt?

wie soll das gehen?

ich weiss nicht was apachectl configtest macht, aber es kommt immernoch derselbe fehler.

> strace -e trace=file -o output /usr/sbin/apache -X

was das command tut, ist mir schleierhaft. habe es nicht ausprobiert, denn in usage von strace steht nicht, was "trace=file" macht.

PHP laeuft jedenfalls einwandfrei auf den user web accounts.
 
You must log in or register to reply here.
Back
Top