Seiten laufen gut: aber wp-login.php ist blank

hallo und guten Abend community,

mehrere Seiten laufen gut.

Aber jeweils der Zugriff auf wp-login.php ist blank

Nutzt du ein vermeintliches Security Plugin?

Hallo u. guten Abend Sir Ector,

vielen Dank für deine schnelle Antwort. Also auf Anhieb würde ich sagen: nein: aber ich kann ja nochmals genauer nachsehen. Es sind insges. ca 5 Seiten auf dem Server.

Interessant: gestern noch hatte ich auf einer der fünf Seiten einen Error: - die Log-Speicher sind übergelaufen....

M.a.W: hier nochmals die errorlogs von gestern: sehr sehr auffällig scheint mir das hier zu sein:

[Sun Dec 31 13:51:07.736641 2017] [log_config:warn] [pid 7309] (27)File too large: [client 91.XX.YYY.EEE:] AH00646: Error writing to logs/access_log, referer: http://www.foo.com/
[Sun Dec 31 17:57:45.102761 2017] [log_config:warn] [pid 9981] (27)File too large: [client 91.XX.YYY.EEE:] AH00646: Error writing to logs/access_log, referer: http://www.foo.com/
[Sun Dec 31 17:57:46.336060 2017] [log_config:warn] [pid 9981] (27)File too large: [client 91.XX.YYY.EEE:] AH00646: Error writing to logs/access_log, referer: http://www.foo.com/wp-content/plugins/wp-job-manager/assets/css/frontend.css?ver=1.29.2

Von Zeit zu Zeit gab die(se Seite) einen Fehler raus.:

[Sun Dec 31 17:57:45.102761 2017] [log_config:warn] [pid 9981] (27)File too large: [client 91.XX.YYY.EEE:] AH00646: Error writing to logs/access_log, referer: http://www.foo.com/
[Sun Dec 31 17:57:46.336060 2017] [log_config:warn] [pid 9981] (27)File too large: [client 91.XX.YYY.EEE:] AH00646: Error writing to logs/access_log, referer: http://www.foo.com/wp-content/plugins/wp-job-manager/assets/css/frontend.css?ver=1.29.2

und dann hat mein Serveradmin das geloest.

Jetzt- also heute folgendes Verhalten:

Jetzt laufen die Seiten - ich kann die Seiten sehen - aber mich nicht einloggeb, also - ich kann jetzt nicht mehr auf die Login-Page mehrerer WP-Seiten kommmen: Die Seiten sind alle als Seiten erreichbar - aber nicht die jeweiligen Login-Pages;

foo.com/wp-login.php
bar.com/wp-login.php.... etc, etx,
site.com/wp-login.php

ist also niht erreichbar; Ich weiß im Moment nicht warum das so ist?

unten hab ich noch weitere Log-Daten:

eine moeglichkeit hier beschrieben:

[Mon Jan 01 16:26:03.229924 2018] [core:notice] [pid 17589] AH00052: child pid 24869 exit signal Segmentation fault (11)
[Mon Jan 01 16:39:54.242584 2018] [core:notice] [pid 17589] AH00052: child pid 24872 exit signal Segmentation fault (11)
[Mon Jan 01 16:39:56.245833 2018] [core:notice] [pid 17589] AH00052: child pid 24870 exit signal Segmentation fault (11)
[Mon Jan 01 16:39:56.245959 2018] [core:notice] [pid 17589] AH00052: child pid 24871 exit signal Segmentation fault (11)
[Mon Jan 01 16:39:56.246014 2018] [core:notice] [pid 17589] AH00052: child pid 24873 exit signal Segmentation fault (11)
[Mon Jan 01 16:49:06.968278 2018] [core:notice] [pid 17589] AH00052: child pid 25032 exit signal Segmentation fault (11)
[Mon Jan 01 16:53:03.287697 2018] [core:notice] [pid 17589] AH00052: child pid 25034 exit signal Segmentation fault (11)

SirEctor: ich werd jetzt mal noch nachsehen ob ich denn ggf. noch problematische Plugins hab.

hallo Sir Ector, hallo b3317133,:-P

viele Dank für Eure Beiträge!!! :-P:-P

Also ich bin immmern och am Suchen:

also: alles läuft auf einem vhost in einem root-server. ich habe dieses Verhalten auf drei Seiten die alle auf der neuesten wp-Version laufen.
ich habe eine WP-Seite aktiviert die auch auf dem Server läuft - aber zu war: mit WordPress 4.7.8 - und dem Theme: "Twenty Seventeen theme"
- welches übrigen auch auf den Seiten läuft, bei denen wie oben erwähnt kein login moeglich ist.

nun - ich sollte ggf noch die php-error-logs ansehen:
dazu werde ich die wp-config.php file aendern un da noch folgendes vornehmen:

define('WP_HOME','localhost/wordpress');
define('WP_SITEURL','localhost/wordpress');

hier noch einen Blick in die Session-Daten:

Session Support     enabled
Registered save handlers     files user mm
Registered serializer handlers     php_serialize php php_binary
Directive    Local Value    Master Value
session.auto_start    Off    Off
session.cache_expire    180    180
session.cache_limiter    nocache    nocache
session.cookie_domain    no value    no value
session.cookie_httponly    Off    Off
session.cookie_lifetime    3600    3600
session.cookie_path    /    /
session.cookie_secure    Off    Off
session.entropy_file    /dev/urandom    /dev/urandom
session.entropy_length    32    32
session.gc_divisor    1000    1000
session.gc_maxlifetime    3600    3600
session.gc_probability    1    1
session.hash_bits_per_character    5    5
session.hash_function    0    0
session.name    PHPSESSID    PHPSESSID
session.referer_check    no value    no value
session.save_handler    mm    mm
session.save_path    no value    no value
session.serialize_handler    php    php
session.upload_progress.cleanup    On    On
session.upload_progress.enabled    On    On
session.upload_progress.freq    1%    1%
session.upload_progress.min_freq    1    1
session.upload_progress.name    PHP_SESSION_UPLOAD_PROGRESS    PHP_SESSION_UPLOAD_PROGRESS
session.upload_progress.prefix    upload_progress_    upload_progress_
session.use_cookies    On    On
session.use_only_cookies    On    On
session.use_strict_mode    Off    Off
session.use_trans_sid    0    0

okay - hier koennte dieses hier interessant sein...

session.save_handler    mm    mm

und darüber hinaus: ggf koennte dann auch dieses noch weiterhelfen:

Zitat

..., access your server via SFTP or FTP, or a file manager in your hosting account’s control panel, navigate to /wp-content/themes/ and rename the directory of your currently active theme. This will force the default theme to activate and hopefully rule-out a theme-specific issue (theme functions can interfere like plugins).

ich halte euch auf dem Laufenden,

vg lin:razz:

Hallo u. guten Abend b3317133 und r23.

vielen Dank fuer Eure Postings u. Ideen.

da steckt vieles drinne: z.B. auch der Hinweis den Errorlog-Zeile zu googlen (siehe unten): child pid xxxxx exit signal Segmentation fault

r23:

Zitat

die WordPress 4.7.8 verwendest du jetzt aber nicht mit PHP 7.2.0?

nochmals zur Klärung wie es hier läuft... und was ich getestet habe:

Nein - ich verwende aktuell PHP Version 5.6.32
ja klar: die allerneueste Version der WP ist bei mir auf dem Server standardmässig 4.9.1
M.a.W: die Seiten laufen alle auf 4.9.1. Und alle diese Seiten haben die Blankpage bei der Login-Seite;
Die Version 4.7.8 lief auf einer Seite - in einem Vhost den ich aktiviert habe, um zu einfach mal noch ein paar Möglichkeiten zu testen.
Und siehe da: mit der alten wp version tritt der Fehler - die Blank-Page beim login - nicht auf.

by the way: Zum Ermitteln der Errorlogs würde ich so vorgehen; den debug-mode so herstellen:

define( 'WP_DEBUG', true )
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );

aber ich glaube dass wir ja jetzt schon viel haben - mit dem Hinweis auf die Logdaten; child pid xxxxx exit signal Segmentation fault
Ich denke, dass ich dem jetzt nachgehen sollte.

@ b3317133:

Zitat

Wende Dich an den Admin des Servers, der sollte das Problem in ein paar Minuten lokalisieren/lösen können.Mit WordPress 4.9.1 (das wäre die neuste Version und nicht 4.7.8 ) hat das wohl wenig/nichts zu tun, ausser ggf. wie von SirEctor angesprochen, ein "vermeintliches Security Plugin" dreht durch...

Bin schnon mit dem Serveradmin im engen Austausch. Als er erfahren hat, dass es mit der WordPress 4.7.8 läuft, aber mit der ganz neuen nicht mehr,
hat er gesagt dass es aller Vorraussicht nach nicht am Server aber an der Wprdüress liegt.

Zitat

WordPress verwendet Cookies und keine Session. Wenn du wirklich Sessions in deinem System über Plugins oder Themes verwende solltest, achte auf die ChangeLog von PHP http://php.net/ChangeLog-7.php Da waren in der Vergangenheit leider einige Fehler...Deine Fehlermeldung aus der Log hat aber eine sehr geringen Bezug zu PHP und wordPress. Google nach "child pid xxxxx exit signal Segmentation fault"

.....und das ist eine sehr sehr gute Idee: "child pid xxxxx exit signal Segmentation fault" - haben sie doch genau mit einer Blank-Page zu tun.

Zitat

https://stackoverflow.com/questions/7745…apache-error-lo I am using Apache/PHP/MySQL stack. Using as framework CakePHP. Every now and then I get a blank white page. I can't debug it through Cake, so I peek in the apache error.log and here's what I get:

Code

[Wed Oct 12 15:27:23 2011] [notice] child pid 3580 exit signal Segmentation fault (11)
[Wed Oct 12 15:27:34 2011] [notice] child pid 3581 exit signal Segmentation fault (11)
[Wed Oct 12 15:30:52 2011] [notice] child pid 3549 exit signal Segmentation fault (11)
[Wed Oct 12 16:04:27 2011] [notice] child pid 3579 exit signal Segmentation fault (11)
zend_mm_heap corrupted
[Wed Oct 12 16:26:24 2011] [notice] child pid 3625 exit signal Segmentation fault (11)
[Wed Oct 12 17:57:24 2011] [notice] child pid 3577 exit signal Segmentation fault (11)
[Wed Oct 12 17:58:54 2011] [notice] child pid 3550 exit signal Segmentation fault (11)
[Wed Oct 12 17:59:52 2011] [notice] child pid 3578 exit signal Segmentation fault (11)

What is this segmentation fault, how can I fix this, I have no clue and would be greatfully greatful.

Code

PHP Version 5.3.4, OSX local development 
Server version: Apache/2.2.17 (Unix)
CakePhp: 1.3.10

Attach gdb to one of the httpd child processes and reload or continue working and wait for a crash and then look at the backtrace. Do something like this:

Code

$ ps -ef|grep httpd
0     681     1   0 10:38pm ??         0:00.45 /Applications/MAMP/Library/bin/httpd -k start
501   690   681   0 10:38pm ??         0:00.02 /Applications/MAMP/Library/bin/httpd -k start
Now attach gdb to one of the child processes, in this case PID 690 (columns are UID, PID, PPID, ...)

Code

$ sudo gdb
(gdb) attach 690
Attaching to process 690.
Reading symbols for shared libraries . done
Reading symbols for shared libraries ....................... done
0x9568ce29 in accept$NOCANCEL$UNIX2003 ()
(gdb) c
Continuing.

Wait for crash... then:

Code

(gdb) backtrace

Or

Code

(gdb) backtrace full

Should give you some clue what's going on. If you file a bug report you should include the backtrace. If the crash is hard to reproduce it may be a good idea to configure Apache to only use one child processes for handling requests. The config is something like this:

StartServers 1
MinSpareServers 1
MaxSpareServers 1

Alles anzeigen

und zum Abschluss gibt es auf dem obengeannten Stackoverflow-Thread noch folgenden Hinweis:

Zitat

Have you tried to increase output_buffering in your php.ini? What does "zend_mm_heap corrupted" mean?

Also ich werde nochmals alles untersuchen:

• - nach der SirEctor-Idee eines Plugins der Fehler verursacht, - Merkwürdig allerdings ist dass ich im Grunde der Reihe nach alle Seiten abgeschaltet hab.
• - nach Moeglichkeiten die mit dem Server zu tun haben, Die Ideen von exit signal Segmentation fault sind sehr sehr interesant, haben sie doch genau mit einer Blank-Page zu tun.

b3317133

Zitat

Wende Dich an den Admin des Servers, der sollte das Problem in ein paar Minuten lokalisieren/lösen können.Mit WordPress 4.9.1 (das wäre die neuste Version und nicht 4.7.8 ) hat das wohl wenig/nichts zu tun, ausser ggf. wie von SirEctor angesprochen, ein "vermeintliches Security Plugin" dreht durch...

melde mich wieder u. halte uch auf dem Laufenden,

Nochmals vielen Dank an Euch SirEctor, b3317133 und r23 - ihr seit total klasse - eure Ideen u. Hinweise helfen sehr viel weiter. Vielen Dank!!!

Lin ;)

guten Morgen, r23 (Ralf), b3317133, SirEctor,

vorweg vielen Dank für Eure Hilfe - in diesem u. in vielen anderen Threads.

Es geht wieder. Alles i.O. jetzt ;)

Wir haben gestern Nacht noch weitergearbeitet - im Anschluss an die von dir Ralf geäußerten Ideen zu dem Errorlog u. den Befunden, die man in dem Stackoverflow-Thread (S.u.) machen konnte [dort war auch von Blank-pages die Rede], hab ich nochmals mit dem Serveradmin gesprochen. Dazu hast auch du b3317133 geraten.
In dem Zusammenhang mit gdb haben wir dann noch weitere Optionen (wie strace, ltrace) diskutiert. Und mein Admin ist dann noch fündig geworden. Vorweg: Es ist alles wieder okay - die Blank-Pages sind weg. ;) Kann Euch später noch mehr schreiben.

Zu strace,ltrace u. gdb : Alle diese Möglichkeiten u. Ansätze werden hier kurz u. prägnant beschrieben: https://derickrethans.nl/what-is-php-doing.html

• strace
• ltrace
• gdb

Hier nochmals der Ausgangsbefund - die geloggten Fehler: [Wed Jan 03 19:11:22.607971 2018] [core:notice] [pid 17589] AH00052: child pid 3419 exit signal Segmentation fault (11)
Der Artikel auf Stackoverflow: https://stackoverflow.com/questions/7745…apache-error-lo

Derick Rethans zu den Ansätzen strace ltrace gdb : https://derickrethans.nl/what-is-php-doing.html

Zitat

What is PHP doing?

Sometimes when you have a long running PHP script, you might wonder what the hell it is doing at the moment. There are a few tools that can help you to find out, without having to stop the script. Some of these work only on Linux.

strace

The first tool that you can use is strace. strace is a tool that traces system calls. System calls are made by PHP for reading/writing from/to the network and/or files; this also includes reading and writing to databases over the network or Unix domain sockets. strace will also show other system calls such as time. You can use strace by running something like:

Code

strace -p <processid>

The processid you can figure out by running ps aux | grep php and then guessing the correct one from the list - probably the one that uses 100% CPU time. It is also possible to run strace directly with your program's arguments:

ltrace

The ltrace tool can be run and used in the same way as strace, and will tell you which intra-library functions are being called. It produces a lot more information than strace but it should give a good hint of all the C-library functions that are being called. Not as useful as strace though.

gdb

If neither strace or ltrace produce any output, it's likely that your script or extension is doing lots of computing. To then figure out in which PHP function your script currently is, you can use the gdb tool.

gdb—the GNU debugger—is a general purpose debugger for C/C++ applications and provides the same functions as Xdebug provides for PHP script debugging. Again, you can either run gdb with new arguments, and then type on the (gdb) prompt run:

Code

gdb --args php yourscript.php
(gdb) run

Or with an already running process and then running cont on the prompt:

Code

gdb -p <processid>
(gdb) cont

Once the script gets to a state in which you are interested to see what it is doing, you can press Ctrl-C. At that moment you come back at the (gdb) prompt where you can run bt to get a list of all the C-level functions that PHP has been calling. For example....[...]...

Alles anzeigen

mehr dazu hier: https://derickrethans.nl/what-is-php-doing.html

Also - alles wieder okay.

Euch r23 (Ralf), b3317133, SirEctor, ganz vielen Dank!!!!! ;)

vg
ps (Werde euch ggf noch mehr schreiben... - wenn ich noch mehr details hab. )