관리자 화면이나 사이트 전체가 500 을 내고, PHP 로그에 플러그인 디렉터리 안의 파일을 찾지 못했다는 치명적 오류가 남는다.
PHP Fatal error: Uncaught Error: Failed opening required
'/var/www/html/wp-content/plugins/jetpack/jetpack_vendor/automattic/jetpack-assets/actions.php'
(include_path='.:/usr/local/lib/php')
in .../jetpack/vendor/jetpack-autoloader/class-version-loader.php:109
스택 추적을 따라가면 wp-settings.php → 플러그인의 autoload_packages.php → 오토로더 순으로 이어진다. 즉 WordPress 가 부팅하면서 플러그인을 적재하다가 죽는 것이라, 관리자 화면으로 들어가 플러그인을 끄는 정상 경로 자체가 막힌다.
플러그인의 vendor 디렉터리가 불완전하다. 흔한 경로는 다음과 같다.
Jetpack 처럼 자체 오토로더를 쓰는 플러그인은 버전별 파일 맵을 먼저 읽기 때문에, 파일 하나만 없어도 사이트 전체가 멈춘다.
WordPress 는 없는 플러그인을 자동으로 비활성화한다. 파일 시스템에서 이름만 바꾸면 관리자 화면이 돌아온다.
cd /var/www/html/wp-content/plugins
mv jetpack jetpack.broken
컨테이너라면 docker exec 로 같은 일을 한다. 이 시점에 사이트가 다시 뜨면 원인이 그 플러그인임이 확정된다.
df -h /var/www/html
ls -l /var/www/html/wp-content/plugins/jetpack.broken/jetpack_vendor/automattic/
ps -eo user,comm | grep -E 'php-fpm|httpd|apache2' | sort -u
디스크가 꽉 찼다면 그것부터 비운다. 공간을 확보하지 않고 재설치하면 같은 자리에서 다시 멈춘다.
WP-CLI 가 있으면 가장 간단하다.
wp plugin install jetpack --force --activate --allow-root
WP-CLI 가 없으면 공식 배포 zip 을 받아 디렉터리를 통째로 교체한다. 기존 디렉터리에 덮어쓰지 말고 지운 뒤 푼다. 덮어쓰기는 예전 버전의 잔재를 남겨 오토로더가 다시 헤맨다.
cd /tmp
curl -LO https://downloads.wordpress.org/plugin/jetpack.zip
unzip -q jetpack.zip -d /var/www/html/wp-content/plugins/
chown -R www-data:www-data /var/www/html/wp-content/plugins/jetpack
소유자는 그 서버의 웹 서버 계정으로 맞춘다. RHEL 계열 httpd 는 apache 다.
curl -sI https://example.com/wp-admin/ | head -n 1
rm -rf /var/www/html/wp-content/plugins/jetpack.broken
어느 플러그인이 문제인지 모르면 플러그인 디렉터리를 통째로 옮겨 사이트를 먼저 살린 뒤 하나씩 되돌린다.
mv /var/www/html/wp-content/plugins /var/www/html/wp-content/plugins.off
mkdir /var/www/html/wp-content/plugins
chown www-data:www-data /var/www/html/wp-content/plugins
wp-content 와 DB 를 백업한다.max_execution_time 과 memory_limit 이 너무 낮으면 업데이트가 중간에 끊긴다. 업데이트 작업용으로 여유 있게 둔다.wp-content 를 반드시 볼륨으로 잡는다. 이미지 안에 두면 재배포 때마다 사라진다.display_errors = Off
log_errors = On
error_log = /var/log/php/error.log