php / php/php-src

How to properly restart Apache(mod-php) when updating FFI_LIB libraries in ffi.preload

Đang mở
#18,263 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Extension: ffi Feature SAPI: apache2handler Status: Needs Triage
Ngôn ngữ chính
C
Star
40.4k
Fork
8.2k
Merge trung bình
2 ngày 13 giờ
Pull request đã merge (30 ngày)
96

Mô tả

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?

  1. 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
    
  2. Always change the FFI_LIB path in the ffi.preload header file.
    e.g.,

    #define FFI_LIB "/home/abc/xyz.so.0.2"
    
  3. Always use apachectl stop followed by start for 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);

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Hướng nghiên cứu

Bắt đầu với các thiết lập ffi.preload và opcache được hiển thị trong php.ini và preload.h, sau đó theo dõi cách apachectl graceful ảnh hưởng đến thư viện dùng chung đã được tải và kiểm tra đầu ra pmap được mô tả. Xác định liệu các lần cập nhật lặp lại có để lại các mappings cũ hay không và graceful reload có được hỗ trợ hay không; ghi lại hành vi đã được xác nhận và một quy trình cập nhật an toàn.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Đánh giá

Công nghệ
apache, c, php
Lĩnh vực
backend, operating-systems
Loại issue
Lỗi
Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức độ hoạt động
Đình trệ
Độ rõ ràng
Cần làm rõ
Mức phù hợp với người mới
25/100

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.