Weitere Informationen und den Download findest du auf der offiziellen Anlaufstelle de.wordpress.org
Ergebnis 1 bis 10 von 10
Like Tree6Likes
  • 1 Post By SirEctor
  • 1 Post By b3317133
  • 1 Post By r23
  • 2 Post By b3317133
  • 1 Post By r23

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

  1. #1
    lin
    lin ist offline
    PostRank: 6
    Registriert seit
    01.12.2013
    Beiträge
    675

    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
    Lin ;) :: super toolkits http://wpgear.org/


  2. #2
    PostRank: 10 Avatar von SirEctor
    Registriert seit
    28.10.2008
    Beiträge
    9.797
    Nutzt du ein vermeintliches Security Plugin?
    lin likes this.
    Das Geheimnis des Könnens liegt im Wollen!

  3. #3
    lin
    lin ist offline
    PostRank: 6
    Registriert seit
    01.12.2013
    Beiträge
    675
    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:

    Code:
    [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.:

    Code:
    [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:

    Code:
    [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.
    Lin ;) :: super toolkits http://wpgear.org/

  4. #4
    PostRank: 10 Avatar von b3317133
    Registriert seit
    21.11.2014
    Beiträge
    2.280
    Wende Dich bzgl. der Fehler auf jeden Fall an den Hoster, das sieht für mich nicht nach einem Plugin-Problem aus.
    lin likes this.

  5. #5
    lin
    lin ist offline
    PostRank: 6
    Registriert seit
    01.12.2013
    Beiträge
    675
    hallo Sir Ector, hallo b3317133,


    viele Dank für Eure Beiträge!!!

    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:

    Code:
    define('WP_HOME','localhost/wordpress');
    define('WP_SITEURL','localhost/wordpress');
    hier noch einen Blick in die Session-Daten:

    Code:
    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...

    Code:
    session.save_handler    mm    mm

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

    ..., 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
    Geändert von lin (03.01.2018 um 00:17 Uhr)
    Lin ;) :: super toolkits http://wpgear.org/

  6. #6
    r23
    r23 ist offline
    PostRank: 10
    Registriert seit
    09.12.2006
    Beiträge
    3.897
    Zitat Zitat von lin Beitrag anzeigen
    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.
    die WordPress 4.7.8 verwendest du jetzt aber nicht mit PHP 7.2.0?

    Zitat Zitat von lin Beitrag anzeigen
    nun - ich sollte ggf noch die php-error-logs ansehen:
    sinnvoll!

    Zitat Zitat von lin Beitrag anzeigen
    dazu werde ich die wp-config.php file aendern un da noch folgendes vornehmen:

    Code:
    define('WP_HOME','localhost/wordpress');
    define('WP_SITEURL','localhost/wordpress');
    keine gute Idee. Warum? ... und eine URL beginnt mit http:// pp https://

    Zitat Zitat von lin Beitrag anzeigen
    hier noch einen Blick in die Session-Daten:

    [CODE]
    Session Support enabled

    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"

    Viel Glück

    Ralf
    lin likes this.

  7. #7
    PostRank: 10 Avatar von b3317133
    Registriert seit
    21.11.2014
    Beiträge
    2.280
    Zitat Zitat von lin Beitrag anzeigen
    Also ich bin immmern och am Suchen: also: alles läuft auf einem vhost in einem root-server.
    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...
    Geändert von b3317133 (03.01.2018 um 09:32 Uhr)
    lin and JABA-Hosting like this.

  8. #8
    lin
    lin ist offline
    PostRank: 6
    Registriert seit
    01.12.2013
    Beiträge
    675
    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:
    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:

    Code:
    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:
    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.

    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.

    https://stackoverflow.com/questions/...pache-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

    A segementation fault is an internal error in php (or, less likely, apache). Oftentimes, the segmentation fault is caused by one of the newer and lesser-tested php modules such as imagemagick or subversion. Try disabling all non-essential modules (in php.ini), and then re-enabling them one-by-one until the error occurs. You may also want to update php and apache. If that doesn't help, you should report a php bug.
    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
    und zum Abschluss gibt es auf dem obengeannten Stackoverflow-Thread noch folgenden Hinweis:

    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
    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
    Lin ;) :: super toolkits http://wpgear.org/

  9. #9
    lin
    lin ist offline
    PostRank: 6
    Registriert seit
    01.12.2013
    Beiträge
    675
    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/...pache-error-lo

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

    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....[...]...
    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. )
    Geändert von lin (04.01.2018 um 11:08 Uhr)
    Lin ;) :: super toolkits http://wpgear.org/

  10. #10
    r23
    r23 ist offline
    PostRank: 10
    Registriert seit
    09.12.2006
    Beiträge
    3.897
    Zitat Zitat von lin Beitrag anzeigen
    cool..

    Derick ist leiter des Q&A-PHP-Teams, trägt zum PHP Quellcode bei und ist Autor der Xdebug-Extension. Verwende xdebug
    lin likes this.

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •