How to properly restart Apache(mod-php) when updating FFI_LIB libraries in ffi.preload
Nessuno ha ancora preso questa issue.
- Lingua principale
- C
- Stelle
- 40.4k
- Fork
- 8.1k
- Merge medio
- 2g 13h
- PR unite (30g)
- 96
Descrizione
Description
apache(prefork) 2.4.62
php 8.2.28
I already have a properly functioning FFI configuration with connected libraries.
My question is whether a complete restart of the Apache process (full stop and then start) is always necessary when the library (.so) needs to be updated.
Once, to update the library, I overwrote the file at the path specified by FFI_LIB with an updated file and tried apachectl graceful. I confirmed that all Apache worker processes restarted, but the result showed that it was still referencing the old library rather than the updated one.
After some experimentation, I found that when I changed the FFI_LIB path in the header (.h) file configured in ffi.preload and then tried apachectl graceful, it successfully referenced the new library.
However, when I examined pmap -p <APACHE PID>, I observed the following two mappings:
00007fcce5531000 20K r---- /home/abc/xyz.so.02
00007fcce5536000 252K r-x-- /home/abc/xyz.so.02
00007fcce5575000 52K r---- /home/abc/xyz.so.02
00007fcce5582000 12K r---- /home/abc/xyz.so.02
00007fcce5585000 4K rw--- /home/abc/xyz.so.02
...
00007fccf36bc000 20K r---- /home/abc/xyz.so.01
00007fccf36c1000 252K r-x-- /home/abc/xyz.so.01
00007fccf3700000 52K r---- /home/abc/xyz.so.01
00007fccf370d000 12K r---- /home/abc/xyz.so.01
00007fccf3710000 4K rw--- /home/abc/xyz.so.01
The Apache process was running normally, and the library functions were working properly, but I'm still unsure if this result is normal. If I were to update 100 times, would I end up with about 100 such mappings?
When using ffi.preload and needing to update the connected library, which of the following approaches is correctly understood?
-
Use symbolic links for changes. (At least from what I've observed, this doesn't guarantee consistent behavior.)
e.g.,xyz.so -> /home/abc/xyz.so.01 (symbolic link) xyz.so.01 xyz.so.02 -
Always change the FFI_LIB path in the ffi.preload header file.
e.g.,#define FFI_LIB "/home/abc/xyz.so.0.2" -
Always use
apachectl stopfollowed bystartfor updates.
e.g.,$ sudo apachectl stop && sudo apachectl start
Approach #3 works without issues, but completely stopping and starting the master process is burdensome in a live server on-premises environment.
It would be great if there's a general method that can be used with apachectl graceful.
Below is a simplified version of my php.ini and ffi.preload header file for testing:
zend_extension=opcache
extension=ffi
ffi.enable=preload
ffi.preload=/home/abc/preload.h
opcache.enable=1
opcache.preload_user=nobody
opcache.preload=/home/abc/preload.php
#define FFI_SCOPE "XYZ"
#define FFI_LIB "/home/abc/xyz.so"
#include <stdint.h>
void xyz_hello_world(void);
int32_t xyz_this_year(void);
size_t xyz_multiply(int32_t v);
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Direzione di ricerca
Inizia con le impostazioni ffi.preload e opcache mostrate in php.ini e preload.h, quindi traccia come apachectl graceful influisce sulla libreria condivisa caricata ed esamina l'output di pmap descritto. Determina se gli aggiornamenti ripetuti lasciano vecchi mappings e se graceful reload è supportato; documenta il comportamento confermato e una procedura di aggiornamento sicura.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Valutazione
- Stack tecnologico
- apache, c, php
- Ambito
- backend, operating-systems
- Tipo di issue
- Bug
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Stato di attività
- Ferma
- Chiarezza
- Da chiarire
- Idoneità per principianti
- 25/100