> Hallo Raketenwilli, > > genau das wusste ich nicht - wie FPM da agiert. Aber bist Du sicher, dass der Master-Prozess die Connections poolt? Ich habe das gestern zu ergoogeln versucht, aber keine Beschreibung gefunden. Naja. Einer muss es ja tun. Und die Kindprozesse können es definitiv nicht. Zumindest hält der Masterprozess mit der ID 26280 (neben den eigentlich arbeitenden Kindern) auch die entsprechenden Libarys geladen: `~$ sudo lsof | grep php | grep mysql` „sagt“ (verkürzt): ~~~ php-fpm8. 26280 root mem … …/mysqli.so php-fpm8. 26280 root mem … …/mysqlnd.so ~~~ (Für die die Kindprozesse gilt das auch, diese laden aber teilweise mehr Erweiterungen.) Für Nicht-Linuxer: Dateien mit der Endung '.so' sind, grob gesagt, das was unter Windows DLLs sind: dynamisch ladbare Erweiterungen. Und falls sich jemand wundert, wieso denn bitte der Vaterprozess eine höhere PID hat als die Kinder ([Liste in meinem obigen Beitrag](https://forum.selfhtml.org/self/2022/sep/23/mysqli-datenbank-zwischen-zwei-abfragen-schliessen/1802317#m1802317)): > **Raspbian** GNU/Linux 11 (bullseye) auf 4 Prozessoren ( ARMv7 Processor rev 3 (v7l) ) **läuft seit 127 Tagen**, 4 Stunden und 53 Minuten. ProzessIDs sind endlich (min=0, max=64535) und werden also wiederverwendet (sonst bekämen vor allem Server schnell ein Problem). Da sind frei gewordene ProzessIDs schon ein paar Mal erneut benutzt worden... z.B. nach einem Update und Restart des Apache oder PHP, was in den letzten 4 Monaten sicher schon ein paar Mal vorgekommen ist. Und dann erscheint die Reihenfolge eher als „zufällig“ statt „aufsteigend“. > Das mit localhost unter Windoof in der hosts-Datei muss ich, wenn ich heute mal Zeit für meine Windose finde und mich ins Büro verbinden kann, überprüfen. Ja. Einige Kommentare (im Web) verkünden auch, dass es alternativ Probleme gäbe, wenn unter Windows IPv6 konfiguriert sei und der `localhost` auch auf `::1` verweise, der MySQL-Server dort aber nicht lausche… Die dort auch empfohlene Deaktivierung des Eintrags in `c:\windows\system32\drivers\etc\hosts` würde ich (wegen unbekannter aber erwartbarer Nebenwirkungen) nicht empfehlen, sondern dann eben für den Verbindungsaufbau die „127.Klo.1“ angeben wollen.

> Hallo Raketenwilli, > > genau das wusste ich nicht - wie FPM da agiert. Aber bist Du sicher, dass der Master-Prozess die Connections poolt? Ich habe das gestern zu ergoogeln versucht, aber keine Beschreibung gefunden. Naja. Einer muss es ja tun. Zumindest hält der Masterprozess mit der ID 26280 (neben den eigentlich arbeitenden Kindern) auch die entsprechenden Libarys geladen: `~$ sudo lsof | grep php | grep mysql` „sagt“ (verkürzt): ~~~ php-fpm8. 26280 root mem … …/mysqli.so php-fpm8. 26280 root mem … …/mysqlnd.so ~~~ (Für die die Kindprozesse gilt das auch, diese laden aber teilweise mehr Erweiterungen.) Für Nicht-Linuxer: Dateien mit der Endung '.so' sind, grob gesagt, das was unter Windows DLLs sind: dynamisch ladbare Erweiterungen. Und falls sich jemand wundert, wieso denn bitte der Vaterprozess eine höhere PID hat als die Kinder ([Liste in meinem obigen Beitrag](https://forum.selfhtml.org/self/2022/sep/23/mysqli-datenbank-zwischen-zwei-abfragen-schliessen/1802317#m1802317)): > **Raspbian** GNU/Linux 11 (bullseye) auf 4 Prozessoren ( ARMv7 Processor rev 3 (v7l) ) **läuft seit 127 Tagen**, 4 Stunden und 53 Minuten. ProzessIDs sind endlich (min=0, max=64535) und werden also wiederverwendet (sonst bekämen vor allem Server schnell ein Problem). Da sind frei gewordene ProzessIDs schon ein paar Mal erneut benutzt worden... z.B. nach einem Update und Restart des Apache oder PHP, was in den letzten 4 Monaten sicher schon ein paar Mal vorgekommen ist. Und dann erscheint die Reihenfolge eher als „zufällig“ statt „aufsteigend“. > Das mit localhost unter Windoof in der hosts-Datei muss ich, wenn ich heute mal Zeit für meine Windose finde und mich ins Büro verbinden kann, überprüfen. Ja. Einige Kommentare (im Web) verkünden auch, dass es alternativ Probleme gäbe, wenn unter Windows IPv6 konfiguriert sei und der `localhost` auch auf `::1` verweise, der MySQL-Server dort aber nicht lausche… Die dort auch empfohlene Deaktivierung des Eintrags in `c:\windows\system32\drivers\etc\hosts` würde ich (wegen unbekannter aber erwartbarer Nebenwirkungen) nicht empfehlen, sondern dann eben für den Verbindungsaufbau die „127.Klo.1“ angeben wollen.

> Hallo Raketenwilli, > > genau das wusste ich nicht - wie FPM da agiert. Aber bist Du sicher, dass der Master-Prozess die Connections poolt? Ich habe das gestern zu ergoogeln versucht, aber keine Beschreibung gefunden. Naja. Einer muss es ja tun. Zumindest hält der Masterprozess mit der ID 26280 (neben den eigentlich arbeitenden Kindern) auch die entsprechenden Libarys geladen: `~$ sudo lsof | grep php | grep mysql` „sagt“ (verkürzt): ~~~ php-fpm8. 26280 root mem … …/mysqli.so php-fpm8. 26280 root mem … …/mysqlnd.so ~~~ (Für die die Kindprozesse gilt das auch, diese laden aber teilweise mehr Erweiterungen.) Für Nicht-Linuxer: Dateien mit der Endung '.so' sind, grob gesagt, das was unter Windows DLLs sind: dynamisch ladbare Erweiterungen. Und falls sich jemand wundert, wieso denn bitte der Vaterprozess eine höhere PID hat als die Kinder ([Liste in meinem obigen Beitrag](https://forum.selfhtml.org/self/2022/sep/23/mysqli-datenbank-zwischen-zwei-abfragen-schliessen/1802317#m1802317)): > **Raspbian** GNU/Linux 11 (bullseye) auf 4 Prozessoren ( ARMv7 Processor rev 3 (v7l) ) **läuft seit 127 Tagen**, 4 Stunden und 53 Minuten. ProzessIDs sind endlich (min=0, max=64535) und werden also wiederverwendet (sonst bekämen vor allem Server schnell ein Problem). Da sind frei gewordene ProzessIDs schon ein paar Mal erneut benutzt worden... z.B. nach einem Update und Restart des Apache oder PHP, was in den letzten 4 Monaten sicher schon ein paar Mal vorgekommen ist. Und dann erscheint die Reihenfolge eher als „zufällig“ statt „aufsteigend“. > Das mit localhost unter Windoof in der hosts-Datei muss ich, wenn ich heute mal Zeit für meine Windose finde und mich ins Büro verbinden kann, überprüfen. Ja. Einige Kommentare (im Web) verkünden auch, dass es alternativ Probleme gäbe, wenn unter Windows IPv6 konfiguriert sei und der localhost auch auf ::1 verweise, der MySQL-Server dort aber nicht lausche…

> Hallo Raketenwilli, > > genau das wusste ich nicht - wie FPM da agiert. Aber bist Du sicher, dass der Master-Prozess die Connections poolt? Ich habe das gestern zu ergoogeln versucht, aber keine Beschreibung gefunden. Naja. Einer muss es ja tun. Zumindest hält der Masterprozess mit der ID 26280 (neben den eigentlich arbeitenden Kindern) auch die entsprechenden Libarys geladen: `~$ sudo lsof | grep php | grep mysql` „sagt“ (verkürzt): ~~~ php-fpm8. 26280 root mem … …/mysqli.so php-fpm8. 26280 root mem … …/mysqlnd.so ~~~ (Für die die Kindprozesse gilt das auch, diese laden aber teilweise mehr Erweiterungen.) Für Nicht-Linuxer: Dateien mit der Endung '.so' sind, grob gesagt, das was unter Windows DLLs sind: dynamisch ladbare Erweiterungen. Und falls sich jemand wundert, wieso denn bitte der Vaterprozess eine höhere PID hat als die Kinder ([Liste in meinem obigen Beitrag](https://forum.selfhtml.org/self/2022/sep/23/mysqli-datenbank-zwischen-zwei-abfragen-schliessen/1802317#m1802317)): > **Raspbian** GNU/Linux 11 (bullseye) auf 4 Prozessoren ( ARMv7 Processor rev 3 (v7l) ) **läuft seit 127 Tagen**, 4 Stunden und 53 Minuten. ProzessIDs sind endlich (min=0, max=64535) und werden also wiederverwendet (sonst bekämen vor allem Server schnell ein Problem). Da sind frei gewordene ProzessIDs schon ein paar Mal erneut benutzt worden... z.B. nach einem Update und Restart des Apache oder PHP, was in den letzten 4 Monaten sicher schon ein paar Mal vorgekommen ist. Und dann erscheint die Reihenfolge eher als „zufällig“ statt „aufsteigend“.

> Hallo Raketenwilli, > > genau das wusste ich nicht - wie FPM da agiert. Aber bist Du sicher, dass der Master-Prozess die Connections poolt? Ich habe das gestern zu ergoogeln versucht, aber keine Beschreibung gefunden. Naja. Einer muss es ja tun. Zumindest hält der Masterprozess mit der ID 26280 (neben den eigentlich arbeitenden Kindern) auch die entsprechenden Libarys geladen: `~$ sudo lsof | grep php | grep mysql` „sagt“: ~~~ php-fpm8. 26280 root mem .../mysqli.so php-fpm8. 26280 root mem .../mysqlnd.so ~~~ (Für die die Kindprozesse gilt das auch, diese laden aber teilweise mehr Erweiterungen.) Für Nicht-Linuxer: Dateien mit der Endung '.so' sind, grob gesagt, das was unter Windows DLLs sind: dynamisch ladbare Erweiterungen. Und falls sich jemand wundert, wieso denn bitte der Vaterprozess eine höhere PID hat als die Kinder ([Liste in meinem obigen Beitrag](https://forum.selfhtml.org/self/2022/sep/23/mysqli-datenbank-zwischen-zwei-abfragen-schliessen/1802317#m1802317)): > **Raspbian** GNU/Linux 11 (bullseye) auf 4 Prozessoren ( ARMv7 Processor rev 3 (v7l) ) **läuft seit 127 Tagen**, 4 Stunden und 53 Minuten. ProzessIDs sind endlich (min=0, max=64535) und werden also wiederverwendet (sonst bekämen vor allem Server schnell ein Problem). Da sind frei gewordene ProzessIDs schon ein paar Mal erneut benutzt worden... z.B. nach einem Update und Restart des Apache oder PHP, was in den letzten 4 Monaten sicher schon ein paar Mal vorgekommen ist. Und dann erscheint die Reihenfolge eher als „zufällig“ statt „aufsteigend“.

> Hallo Raketenwilli, > > genau das wusste ich nicht - wie FPM da agiert. Aber bist Du sicher, dass der Master-Prozess die Connections poolt? Ich habe das gestern zu ergoogeln versucht, aber keine Beschreibung gefunden. Naja. Einer muss es ja tun. Zumindest hält der Masterprozess mit der ID 26280 (neben den eigentlich arbeitenden Kindern) auch die entsprechenden Libarys geladen: `~$ sudo lsof | grep php | grep mysql` „sagt“: ~~~ php-fpm8. 26280 root mem .../mysqli.so php-fpm8. 26280 root mem .../mysqlnd.so ~~~ (Für die die Kindprozesse gilt das auch, diese laden aber teilweise mehr Erweiterungen.) Für Nicht-Linuxer: Dateien mit der Endung '.so' sind, grob gesagt, das was unter Windows DLLs sind: dynamisch ladbare Erweiterungen. Und falls sich jemand wundert, wieso denn bitte der Vaterprozess eine höhere PID hat als die Kinder ([Liste in meinem obigen Beitrag](https://forum.selfhtml.org/self/2022/sep/23/mysqli-datenbank-zwischen-zwei-abfragen-schliessen/1802317#m1802317)): > **Raspbian** GNU/Linux 11 (bullseye) auf 4 Prozessoren ( ARMv7 Processor rev 3 (v7l) ) **läuft seit 127 Tagen**, 4 Stunden und 53 Minuten. ProzessIDs sind endlich (min=0, max=64535) und werden also wiederverwendet (sonst bekämen vor allem Server schnell ein Problem). Da sind frei gewordene ProzessIDs schon ein paar Mal erneut benutzt worden... z.B. nach einem Update und Restart des Apache oder PHP, was in den letzten 4 Monaten sicher schon ein paar Mal vorgekommen ist. Und dann erscheint die Reihenfolge eher als „zufällig“ statt „aufsteigend“.

> Hallo Raketenwilli, > > genau das wusste ich nicht - wie FPM da agiert. Aber bist Du sicher, dass der Master-Prozess die Connections poolt? Ich habe das gestern zu ergoogeln versucht, aber keine Beschreibung gefunden. Naja. Einer muss es ja tun. Zumindest hält der Masterprozess mit der ID 26280 (neben den eigentlich arbeitenden Kindern) auch die entsprechenden Libarys geladen: `~$ sudo lsof | grep php | grep mysql` „sagt“: ~~~ php-fpm8. 26280 root mem .../mysqli.so php-fpm8. 26280 root mem .../mysqlnd.so ~~~ (Für die die Kindprozesse gilt das auch, diese laden aber teilweise mehr Erweiterungen.) Für Nicht-Linuxer: Dateien mit der Endung '.so' sind, grob gesagt, das was unter Windows DLLs sind: dynamisch ladbare Erweiterungen. Und falls sich jemand wundert, wieso denn bitte der Vaterprozess eine höhere PID hat als die Kinder ([Liste in meinem obigen Beitrag](https://forum.selfhtml.org/self/2022/sep/23/mysqli-datenbank-zwischen-zwei-abfragen-schliessen/1802317#m1802317)): > **Raspbian** GNU/Linux 11 (bullseye) auf 4 Prozessoren ( ARMv7 Processor rev 3 (v7l) ) **läuft seit 127 Tagen**, 4 Stunden und 53 Minuten. ProzessIDs sind endlich (max=64536) und werden wiederverwendet. Da sind frei gewordene ProzessIDs schon ein paar Mal erneut benutzt worden... z.B. nach einem Update und Restart des Apache oder PHP, was in den letzten 4 Monaten sicher schon ein paar Mal vorgekommen ist. Und dann erscheint die Reihenfolge eher als „zufällig“ statt „aufsteigend“.

> Hallo Raketenwilli, > > genau das wusste ich nicht - wie FPM da agiert. Aber bist Du sicher, dass der Master-Prozess die Connections poolt? Ich habe das gestern zu ergoogeln versucht, aber keine Beschreibung gefunden. Naja. Einer muss es ja tun. Zumindest hält der Masterprozess mit der ID 26280 (neben den eigentlich arbeitenden Kindern) auch die entsprechenden Libarys geladen: `~$ sudo lsof | grep php | grep mysql` „sagt“: ~~~ php-fpm8. 26280 root mem .../mysqli.so php-fpm8. 26280 root mem .../mysqlnd.so ~~~ (Für die die Kindprozesse gilt das auch, diese laden aber teilweise mehr Erweiterungen.) Für Nicht-Linuxer: Dateien mit der Endung '.so' sind, grob gesagt, das was unter Windows DLLs sind: dynamisch ladbare Erweiterungen. Und falls sich jemand wundert, wieso denn bitte der Vaterprozess eine höhere PID hat als die Kinder ([Liste in meinem obigen Beitrag](https://forum.selfhtml.org/self/2022/sep/23/mysqli-datenbank-zwischen-zwei-abfragen-schliessen/1802317#m1802317)): > Raspbian GNU/Linux 11 (bullseye) auf 4 Prozessoren ( ARMv7 Processor rev 3 (v7l) ) **läuft seit 127 Tagen**, 4 Stunden und 53 Minuten. ProzessIDs sind endlich (max=64536) und werden wiederverwendet. Da sind frei gewordene ProzessIDs schon ein paar Mal erneut benutzt worden... z.B. nach einem Update und Restart des Apache oder PHP, was in den letzten 4 Monaten sicher schon ein paar Mal vorgekommen ist. Und dann erscheint die Reihenfolge eher als „zufällig“ statt „aufsteigend“.

> Hallo Raketenwilli, > > genau das wusste ich nicht - wie FPM da agiert. Aber bist Du sicher, dass der Master-Prozess die Connections poolt? Ich habe das gestern zu ergoogeln versucht, aber keine Beschreibung gefunden. Naja. Einer muss es ja tun. Zumindest hält der Masterprozess mit der ID 26280 (neben den eigentlich arbeitenden Kindern) auch die entsprechenden Libarys geladen: `~$ sudo lsof | grep php | grep mysql` „sagt“: ~~~ php-fpm8. 26280 root mem .../mysqli.so php-fpm8. 26280 root mem .../mysqlnd.so ~~~ (Für die die Kindprozesse gilt das auch, diese laden aber teilweise mehr Erweiterungen.) Für Nicht-Linuxer: Dateien mit der Endung '.so' sind, grob gesagt, das was unter Windows DLLs sind: dynamisch ladbare Erweiterungen. Und falls sich jemand wundert, wieso denn bitte der Vaterprozess eine höhere PID hat als die Kinder ([Liste in meinem obigen Beitrag](https://forum.selfhtml.org/self/2022/sep/23/mysqli-datenbank-zwischen-zwei-abfragen-schliessen/1802317#m1802317)): > Raspbian GNU/Linux 11 (bullseye) auf 4 Prozessoren ( ARMv7 Processor rev 3 (v7l) ) **läuft seit 127 Tagen**, 4 Stunden und 53 Minuten. ProzessIDs sind endlich (max=64536) und werden wieder vwerwendet. Da sind die frei gewordene ProzessIDs schon ein paar Mal wieder verwendet worden... z.B. nach einem Update und Restart des Apache oder PHP, was in den letzten 4 Monaten sicher schon ein paar Mal vorgekommen ist.

> Hallo Raketenwilli, > > genau das wusste ich nicht - wie FPM da agiert. Aber bist Du sicher, dass der Master-Prozess die Connections poolt? Ich habe das gestern zu ergoogeln versucht, aber keine Beschreibung gefunden. Naja. Einer muss es ja tun. Zumindest hält der Masterprozess (neben den eigentlich arbeitenden Kindern) auch die entsprechenden Libarys geladen: `~$ sudo lsof | grep php | grep mysql` „sagt“: ~~~ php-fpm8. 26280 root mem .../mysqli.so php-fpm8. 26280 root mem .../mysqlnd.so ~~~ (Für die die Kindprozesse gilt das auch, diese laden aber teilweise mehr Erweiterungen.) Für Nicht-Linuxer: Dateien mit der Endung '.so' sind, grob gesagt, das was unter Windows DLLs sind: dynamisch ladbare Erweiterungen. Und falls sich jemand wundert, wieso denn bitte der Vaterprozess eine höhere PID hat als die Kinder (Liste in meinem obigen Beitrag): > Raspbian GNU/Linux 11 (bullseye) auf 4 Prozessoren ( ARMv7 Processor rev 3 (v7l) ) **läuft seit 127 Tagen**, 4 Stunden und 53 Minuten. Da sind die frei gewordene ProzessIDs (max=64536) schon ein paar Mal wieder verwendet worden...