chr.istoph, der Blog

Es gibt hier 2 Möglichkeiten segfaults mit gdb anzuschauen. Zum debuggen benötigt man erstmal gdb und die debugs-symbole des Endsprechenden Modules. In meinem aktiven Fall war das, das soap Modul:

dnf install -y gdb
debuginfo-install php74-php-soap

Für das debugen eines coredumps muss man in der /etc/opt/remi/php82/php-fpm.d/www.conf folgendes einstellen:

rlimit_core = 0

Reload nicht vergessen: systemctl reload php74-php-fpm.service

Dem Kernel muss ein Pfad angegeben werden, der auch von php-fpm geschrieben werden kann. Achtung, im cordump können auch sensible Informationen stehen. Daher sollte ein Pfad gewählt werden, der nicht vom Webserver ausgeliefert wird:

echo '/tmp/coredump-%e.%p' > /proc/sys/kernel/core_pattern

Dann kann man sich den coredump anschauen, in dem man das Programm und den Dump angibt:

gdb /opt/remi/php82/root/usr/sbin/php-fpm coredump-php-fpm.852720

Dan gibt es noch die Möglichkeit des live Debuggings. Dafür habe ich die Parameter in php-fpm angepasst, dass nur noch 1 Prozess gestartet wird. So habe ich die Möglichkeit die segfaults sofort mitzubekommen (ob dies ein gangbarer Weg im produktiv Umgebungen ist, müsst ihr selbst Endscheiden):

/etc/opt/remi/php82/php-fpm.d/www.conf

pm.max_children = 1
pm.start_servers = 1
pm.min_spare_servers = 1
pm.max_spare_servers = 1

Reload nicht vergessen: systemctl reload php74-php-fpm.service

Mit `ps` kann man sehen das jetzt nur noch 2 Prozesse vorhanden sind. Wir hängen uns an den chaild:

ps axfu 
...
root      171156  0.0  0.0 493916 11688 ?        Ss   10:46   0:00 php-fpm: master process (/etc/opt/remi/php82/php-fpm.conf)
apache    189306  0.0  0.1 497068 26096 ?        S    10:53   0:00  \_ php-fpm: pool www

Dann kann ich mich mit gdb an den chaild Prozess hängen:

gdb -p 189306
...
(gdb) continue 
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x00007f60ce1f1c75 in __strlen_avx2 () from /lib64/libc.so.6

Backtrace, gibt einen den Output des laufenden Prozesses:

(gdb) bt
#0  0x00007f60ce1f1c75 in __strlen_avx2 () from /lib64/libc.so.6
#1  0x00007f60c1cdeb6d in get_param (function=function@entry=0x7f60cc2720c0, 
    param_name=param_name@entry=0x18 , index=, response=response@entry=1)
    at /usr/src/debug/php82-php-8.2.0~rc3-16.el8.remi.x86_64/ext/soap/soap.c:3978
#2  0x00007f60c1cdfe54 in serialize_response_call2 (body=body@entry=0x557c1ae411d0, function=function@entry=0x7f60cc2720c0, 
    function_name=function_name@entry=0x7f60cc256078 "openSessionResponse", uri=uri@entry=0x7f60cc2660c0 "urn:soapService", 
    ret=ret@entry=0x7ffcc3881630, version=version@entry=1, main=1, node=0x0)
    at /usr/src/debug/php82-php-8.2.0~rc3-16.el8.remi.x86_64/ext/soap/soap.c:3292
#3  0x00007f60c1ce509b in serialize_response_call (function=0x7f60cc2720c0, function_name=0x7f60cc256078 "openSessionResponse", 
    uri=0x7f60cc2660c0 "urn:soapService", ret=0x7ffcc3881630, headers=0x0, version=1)
    at /usr/src/debug/php82-php-8.2.0~rc3-16.el8.remi.x86_64/ext/soap/soap.c:3660
#4  0x00007f60c1ced386 in zim_SoapServer_handle (execute_data=0x7f60cc213090, return_value=)
    at /usr/src/debug/php82-php-8.2.0~rc3-16.el8.remi.x86_64/ext/soap/soap.c:1484
#5  0x00007f60cbcbe4f5 in xdebug_execute_internal () from /opt/remi/php82/root/usr/lib64/php/modules/xdebug.so
#6  0x0000557c196a02c8 in ZEND_DO_FCALL_SPEC_RETVAL_UNUSED_HANDLER ()
    at /usr/src/debug/php82-php-8.2.0~rc3-16.el8.remi.x86_64/Zend/zend_vm_execute.h:1844
#7  execute_ex (ex=0x18) at /usr/src/debug/php82-php-8.2.0~rc3-16.el8.remi.x86_64/Zend/zend_vm_execute.h:56047
#8  0x00007f60cbcbda4c in xdebug_execute_ex () from /opt/remi/php82/root/usr/lib64/php/modules/xdebug.so
#9  0x0000557c196a1932 in zend_execute (op_array=0x7f60cc280000, return_value=0x0)
    at /usr/src/debug/php82-php-8.2.0~rc3-16.el8.remi.x86_64/Zend/zend_vm_execute.h:60379
#10 0x0000557c1962ed15 in zend_execute_scripts (type=type@entry=8, retval=retval@entry=0x0, file_count=file_count@entry=3)
    at /usr/src/debug/php82-php-8.2.0~rc3-16.el8.remi.x86_64/Zend/zend.c:1780
#11 0x0000557c195c849a in php_execute_script (primary_file=) at /usr/src/debug/php82-php-8.2.0~rc3-16.el8.remi.x86_64/main/main.c:2537
#12 0x0000557c1946e662 in main (argc=, argv=)
    at /usr/src/debug/php82-php-8.2.0~rc3-16.el8.remi.x86_64/sapi/fpm/fpm/fpm_main.c:1891

Die jeweiligen stop’s bekommt man mit frame:

(gdb) frame 1
#1  0x00007f60c1cdeb6d in get_param (function=function@entry=0x7f60cc2720c0, 
    param_name=param_name@entry=0x18 , index=, response=response@entry=1)
    at /usr/src/debug/php82-php-8.2.0~rc3-16.el8.remi.x86_64/ext/soap/soap.c:3978
3978			if ((tmp = zend_hash_str_find_ptr(ht, param_name, strlen(param_name))) != NULL) {

Eine liste des Sourcecodes bekommt man mit list, Voraussetzung sind hier die installierten debug symbole:

(gdb) list
3973		if (ht == NULL) {
3974		  return NULL;
3975		}
3976	
3977		if (param_name != NULL) {
3978			if ((tmp = zend_hash_str_find_ptr(ht, param_name, strlen(param_name))) != NULL) {
3979				return tmp;
3980			} else {
3981				ZEND_HASH_FOREACH_PTR(ht, tmp) {
3982					if (tmp->paramName && strcmp(param_name, tmp->paramName) == 0) {

Die Ausgabe der im frame gespeicherten variablen:

(gdb) info locals 
tmp = 
ht = 0x7f60cc260428

(gdb) print param_name
$1 = 0x18 

What a great step to release the library on my birthday. The coming year will bring some more exciting releases. Thanks to textshell everyone who contributed to it.
https://tty.uchuujin.de/2020/11/journey-of-termpaint/

Beim updaten von Debian 8 auf 9 ist beim updaten von OpenVPN openvpn:amd64 2.3.4-5+deb8u2 2.4.0-6+deb9u2 folgendes Problem im Server Log aufgetaucht:

Jan 16 08:57:05 gw openvpn[21175]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Jan 16 08:57:05 gw openvpn[21175]: TLS Error: TLS handshake failed
Jan 16 08:57:05 gw openvpn[21175]: TCP/UDP: Closing socket
Jan 16 08:57:05 gw openvpn[21175]: SIGUSR1[soft,tls-error] received, process restarting


Es stellte sich herraus das die von easy-rsa erstelte crl.pem abgelaufen war. Dies Prüft man mit:

openssl crl -in easy-rsa2/keys/crl.pem -text

Im der Server Konfigurationsdatei wurde die Certificate Revocation List (CRL) geprüft:

crl-verify ./easy-rsa2/keys/crl.pem

Eigentlich wäre es schön wenn die crl.pem automatisch mit neuem Ablaufdatum erstellt würde. Meine Vorgehensweise um dies mit easy-rsa mitteln zum machen war:

cd /etc/openvpn/easy-rsa2
source ./vars
./list-crl
/revoke-full 

Hier habe ich ein bereits abgelaufenes Zertifikat noch einmal revokert.

Nach dem neu anlegen eines Zabbix Hosts, wurde mir der Server dauerhaft mit 50% packet loss angezeigt.

Dies lag offensichtlich daran, dass der Hinzugefügt Hostname im IPv6 Dual-Stack Modus betreiben wurde. So wurde 50% IPv4 Pings korrekt verarbeitet, aber auch 50% IPv6 traffic nicht. Das einfachste ist es den Host von DNS auf IP Überwachung umzustellen. Configuration => Hosts => den jeweiligen Host auswählen und bei „Connect to“ die IP angeben und auswähle.

Ich habe aber dem Zabbix Server einfach auch eine IPv6 Adresse verpasst und bin mal gespannt auf welche Probleme ich noch stoßen werden.

Meine Support anfrage:

Nach dem Neuaufsätzen des Servers ist das von Ihnen Konfigurierte IPv6 Netz ist nicht
funktionsfähig:

Von Intern:
1. ex3k14.rz14.hetzner.de 0.0% 3 4.5 2.2 1.0 4.5 1.9
2. ???

Von Extern:
1. 2a00:fe0:2::1 0.0% 42 0.5 0.8 0.4 10.9 1.6
2. bb2-ks.as34953.net 0.0% 42 21.2 22.2 20.9 29.7 1.6
3. 2a00:fe0:0:8::2 0.0% 42 27.2 27.6 26.6 29.8 0.6
4. decix-gw.hetzner.de 0.0% 42 29.1 29.1 28.1 37.3 1.4
5. core1.hetzner.de 0.0% 42 29.7 28.9 27.8 30.5 0.6
6. core22.hetzner.de 0.0% 41 34.4 33.5 32.6 34.4 0.5
7. juniper2.rz11.hetzner.de 0.0% 41 34.2 34.2 32.3 46.4 2.1
8. ???

Antwort Support:

Sehr geehrte Damen und Herren,

haben Sie schon einmal geprüft ob das Problem auch im Rescue-System besteht? Damit
könnten wir einen Fehler in der Konfiguration ausschließen.

Was für eine Blöde Antwort, das System ist gerade frich aufgesetzt. Zudem erreiche ich mein Gateway danach geht es erst nicht weiter. Meine Vermutung hier war das es sich um den gleich Fehler handelt wie: ipv6-probleme-bei-hetzner

Meine Antwort:

Ja, das Problem ist im Rescue-System reproduzierbar!

Antwort Support:

Sehr geehrter Herr Hueffelmann,

wir würden das Ticket zur Bearbeitung gerne an unsere Netzwerkabteilung
weiterleiten, diese ist jedoch nur von 8 – 16 Uhr erreichbar. Wenn Sie dies
dennoch wünschen dann schreiben Sie uns bitte einfach erneut.

„Dennoch“?

Morgens um 09:00

Das Problem besteht weiter hin, bitte leiten sie das Ticket jetzt an
die Netzwerk abteilung weiter.

Antwort Support:

Sehr geehrter Herr Hueffelmann,

Ihr IPv6-Subnet ist dem falschen Rechenzentrum zugeordnet und kann daher nicht im
RZ 14 genutzt werden. Wir haben das Netz entsprechend gekündigt und Sie können
über den Robot ein neues bestellen.

Ein neues Netz hätte man mir auch gestern Abend zusenden können. Quasi nach der erste anfrage.