Quando un processo viene completato (o perché esce o viene terminato utilizzando un segnale) tutti i file e le connessioni che mantiene aperti vengono automaticamente chiusi dal sistema operativo. Non è chiuso in modo pulito, utilizzando il protocollo MySQL per chiudere le connessioni (supponendo che ce ne sia uno). È semplice cadere a livello TCP/IP e il server dall'altra parte scopre semplicemente che sta parlando a una porta chiusa. Ciò non accade sempre all'istante, a volte ci vuole del tempo prima che il server si accorga che l'interlocutore se n'è andato. Quando ciò accade, considera la connessione interrotta e ripulisce le cose dalla sua parte.
Non apri la connessione MySQL nel processo padre prima di usare fork() . fork() duplica le strutture dati utilizzate per gestire il lato locale della connessione e i risultati sono imprevedibili. Inoltre, quando il figlio completa (non importa come), chiude la connessione (o il sistema operativo la interrompe), anche il server MySQL chiude la sua fine e il processo padre scopre che non sta parlando con nessuno.
Chiudi la connessione MySQL nel processo padre prima di usare fork() quindi apri connessioni separate nel processo padre e figlio, se necessario.
Inoltre, avvolgi qualsiasi comunicazione MySQL con il server nel processo padre tra:
pcntl_sigprocmask(SIG_BLOCK, array(SIGCHLD));
e
pcntl_sigprocmask(SIG_UNBLOCK, array(SIGCHLD));
In caso contrario, quando un processo figlio viene completato, il processo padre riceve una notifica con il SIGCHLD segnale. Un segnale ricevuto lo riprende dalla sospensione (se è stato interrotto in un sleep() chiamare quando arriva il segnale). La libreria MySQL usa sleep() come parte del protocollo MySQL per la comunicazione con il server. Se tale sleep() ritorna forzatamente prima del dovuto (a causa di un segnale ricevuto), la libreria MySQL si confonde e finisce per segnalare strani errori (come "il server MySQL è andato via") che in realtà non sono corretti.
Dai un'occhiata a questa risposta per una spiegazione dettagliata.
