nach umstellung apache 2.2 nach 2.4

  • moin alle zusammen


    komme irgendwie nicht klar...

    nach der umstellung von apache auf 2.4 wird die server index seite nicht mehr angezeigt, nur:


    Code
    1. svwrap
    2. $Revision: 1.60d $
    3. Error in line 1082
    4. cannot fork, most likely the process limit RLIMIT_NPROC is exceeded


    woher kommen die werte in die httpd.conf her?

    im bereich virtualhost serverip:80


    Code
    1. SetEnv RLIMIT_CPU 45
    2. SetEnv RLIMIT_NPROC 128
    3. SetEnv RLIMIT_AS 256000000
    4. SetEnv RLIMIT_NOFILE 200


    oder auch die:

    im bereich virtualhost serverip:443

    Code
    1. SetEnv RLIMIT_CPU 480
    2. SetEnv RLIMIT_NPROC 64
    3. SetEnv RLIMIT_AS 1024000000
    4. SetEnv RLIMIT_NOFILE 200

    bitte klärt mich auf wo die httpd.conf diese werte her bekommt :(

  • Das Template des Apache 2.4 findet man unter /usr/local/pd-admin2/httpd-2.4/conf/httpd24.conf-template

    Dort finden sich die Werte für den vhost des Backends. Angegeben sind nur die Werte für :80. Für :443 werden diese übernommen.


    Auch alles andere zum Apache 2.4 findet sich ebenfalls unter /usr/local/pd-admin2/httpd-2.4/

  • Ich habe es gerade Mal nachgeschaut. Bei mir ist das CPU Limit auch 480. Der Wert scheint mir aus der httpd_vhost.pl zu kommen. Zumindest konnte ich dies nirgends finden... Hatte es mir bisher aber auch nie näher angeschaut und lediglich Änderungen für :80 im Template vorgenommen.


    Wenn das RLIMIT_NPROC Limit erreicht wurde, sollte geprüft werden wodurch. Denn die bedeutet ja, dass entsprechend viele Skripte bzw Prozesse ausgeführt würden.

  • jetzt bin hier wieder an der selben stelle

    Code
    1. svwrap
    2. $Revision: 1.60d $
    3. Error in line 1082
    4. cannot fork, most likely the process limit RLIMIT_NPROC is exceeded

    wie ich damals es gelöst habe, weiß ich nicht mehr, aber das komische ist das es sich nur auf die index.php(besser gesagt auf die scripte im htdocs, auch zu probe erstelle phpinfo.php hat den selben fehler) bezieht

    pd-admin an sich geht ohne probleme und sonstige web-mailer usw


    ich habe das forum schon durchstöbert und sämtliche ansätze ausprobiert. aber den fehler bekomme ich nicht weg


    hilft mir bitte der ursache auf den grund zu gehen... :-(


    in den log ist nur...

    Code
    1. domain 80.187.108.223 - - [14/Mar/2019:22:07:53 +0100] "GET / HTTP/1.1" 200 201 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:65.0)

    in den error logs ist hier nichts

  • hatte ich schon alles erhöht und auch nix geholfen

    aber frage an der stelle... hat die Angebotsverwaltung was mit der Hauptadresse vom Server auch was zu tun

    den Fehler habe ich nur beim Aufruf der hauptdomain/subdomain des servers, also eigentlich die seite die "It's works" anzeigen sollte, ich habe index.php da liegen habe die den Fehler produziert

  • Limit CPU-Zeit 120 sec

    Limit Prozessanzahl 300 Stück

    Limit Arbeitsspeicher pro Prozess 256 MB

    Limit Dateien pro Prozess 200

    so ist es aktuell im angebot


    das sind die werte aus der nano /usr/local/pd-admin2/conf/httpd.conf-template

    Code
    1. SetEnv RLIMIT_CPU 128
    2. SetEnv RLIMIT_NPROC 256
    3. SetEnv RLIMIT_AS 512000000
    4. SetEnv RLIMIT_NOFILE 200

    das komische ist aber immer noch das es in der /usr/local/pd-admin2/conf/httpd.conf

    für :80 so steht

    Code
    1. SetEnv RLIMIT_CPU 128
    2. SetEnv RLIMIT_NPROC 256
    3. SetEnv RLIMIT_AS 512000000
    4. SetEnv RLIMIT_NOFILE 200

    und : 443 so

    Code
    1. SetEnv RLIMIT_CPU 480
    2. SetEnv RLIMIT_NPROC 64
    3. SetEnv RLIMIT_AS 1024000000
    4. SetEnv RLIMIT_NOFILE 200

    hier hat sich nach wie vor nix geändert.... ka woher die werte kommen


  • Führt man

    Shell-Script
    1. strace -vvfe trace=write,open,read -s 4096 -o strace.log /opt/pdadmin/bin/httpd_vhosts.pl

    aus, sieht man dass dort RLIMIT_NPROC 64 in die httpd.conf geschrieben wird. Ich hab nur flüchtig drüber geschaut, konnte aber nicht sehen, dass die Werte irgendwo her kommen. Daher gehe ich davon aus, dass die Werte direkt aus der httpd_vhosts.pl kommen.

  • jetzt bin hier wieder an der selben stelle

    Code
    1. svwrap
    2. $Revision: 1.60d $
    3. Error in line 1082
    4. cannot fork, most likely the process limit RLIMIT_NPROC is exceeded

    wie ich damals es gelöst habe, weiß ich nicht mehr, aber das komische ist das es sich nur auf die index.php(besser gesagt auf die scripte im htdocs, auch zu probe erstelle phpinfo.php hat den selben fehler) bezieht

    pd-admin an sich geht ohne probleme und sonstige web-mailer usw

    Das RLIMIT_NPROC bezieht sich ja auf die Anzahl an gleichzeitigen Prozessen. Sprich zum Zeitpunkt des Fehlers müssten 64 Prozesse gleichzeitig laufen. Vorstellbar wäre, dass z.b. eine Brute-Force-Attacke auf phpMyAdmin oder Roundcube stattfindet und dadurch das Limit erreicht wird. Es sollte daher bei Auftreten des Fehlers das access_log und die Prozessliste analysiert werden.

  • nehme mal wieder zeit um zu versuchen das Problem aus der Welt zu schaffen

    error logs sind nur die einträge


    und access ...


    Code
    1. domain 80.187.110.92 - - [18/Mar/2019:17:41:54 +0100] "GET / HTTP/1.1" 200 201 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:65.0) Gecko/20100101 $
    2. domain 80.187.110.92 - - [18/Mar/2019:17:41:55 +0100] "GET / HTTP/1.1" 200 201 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:65.0) Gecko/20100101

    also eigentlich ganz normale einträge

  • aber bei euch allen, müsste es doch auch der selbe wert stehen und funktioniert denke ich mal alles


    hat es evtl was mit benutzer was zu tun?

    den die index.php gehört dem user www

    ist das der fehler? sollte es was anderes sein?

  • ich habe das immer so handhabt, weil ich auch damals verschiedene server hatte,

    und der inhalt der index war immer Links auf dem Server liegende Programme, wie z.b Link zu pd-admin kundernverwaltung, squirrelmail, usw

    geht der Kunde auf die hauptdomain des servers, hat er alles dazu passende Links parat

    an sich kann man es auch anders lösen, aber ich hatte es schon immer so gehabt