There has been a critical error – Alpine, Nginx, MariaDB, PHP7

  • G’day,

    I’m just starting to play with an Alpine Linux (latest) container on my Proxmox (latest) server instance. I want to run a few rather small WordPress site, and figured that as Alpine Linux was a really lightweight distro, that would be a good way to ensure I use no more resources than required.

    So, I have worked out a procedure to get Nginx, MariaDB, PHP-7, Logrotate and Let’s Encrypt up and running, but am having issues with WordPress installing. I get the dreaded “There has been ac ritical error on this website” message and the following in the nginx/site_error.log:

    Stack trace:
#0 /var/www/site.org/wp-includes/blocks/archives.php(115): register_block_type_from_metadata()
#1 /var/www/site.org/wp-includes/class-wp-hook.php(292): register_block_core_archives()
#2 /var/www/site.org/wp-includes/class-wp-hook.php(316): WP_Hook->apply_filters()
#3 /var/www/site.org/wp-includes/plugin.php(484): WP_Hook->do_action()
#4 /var/www/site.org/wp-settings.php(560): do_action()
#5 /var/www/site.org/wp-admin/setup-config.php(33): require('/var/www/site.org...')
#6 {main}
  thrown in /var/www/site.org/wp-includes/blocks.php on line 203" while reading response header from upstream, client: 10.255.69.101, server: site.org, request: "GET /wp-admin/setup-config.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "site.org"
2021/06/16 19:00:17 [error] 702#702: *17 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Error: Call to undefined function json_decode() in /var/www/site.org/wp-includes/blocks.php:203

    I’m stumped at this point and really am unsure where to look next to see what I need to do to get this running…

    This is the output from apk info:

    alpine-baselayout
alpine-keys
ca-certificates-bundle
libtls-standalone
zlib
scanelf
libc-utils
apk-tools
busybox
libcrypto1.1
libssl1.1
ssl_client
alpine-conf
busybox-suid
busybox-initscripts
alpine-base
musl
ifupdown-ng
openrc
musl-utils
pcre
nginx
nginx-openrc
php7-common
argon2-libs
ncurses-terminfo-base
ncurses-libs
libedit
pcre2
xz-libs
libxml2
php7
ca-certificates
brotli-libs
nghttp2-libs
libcurl
php7-curl
php7-fpm
libxau
libbsd
libxdmcp
libxcb
libx11
libxext
libice
libuuid
libsm
libxt
libxpm
libbz2
libpng
freetype
libjpeg-turbo
libwebp
php7-gd
php7-openssl
php7-mysqlnd
php7-mysqli
php7-opcache
mariadb-common
libaio
libgcc
linux-pam
libstdc++
mariadb
mariadb-openrc
mariadb-client
popt
logrotate
logrotate-openrc
expat
libffi
gdbm
readline
sqlite-libs
python3
py3-ordered-set
py3-appdirs
py3-parsing
py3-six
py3-packaging
py3-setuptools
py3-cparser
py3-cffi
py3-idna
py3-asn1crypto
py3-cryptography
py3-openssl
py3-josepy
py3-pbr
py3-mock
py3-tz
py3-pyrfc3339
py3-chardet
py3-urllib3
py3-requests
py3-requests-toolbelt
py3-acme
py3-configargparse
py3-configobj
py3-distro
py3-distutils-extra
py3-future
py3-parsedatetime
py3-zope-interface
py3-zope-proxy
py3-zope-deferredimport
py3-zope-deprecation
py3-zope-event
py3-zope-hookable
py3-zope-component
certbot
certbot-nginx
icu-libs
php7-intl
oniguruma
php7-mbstring
php7-soap
php7-xml
php7-xmlrpc
libzip
php7-zip
fcgi
php7-cgi
php7-ctype
php7-dom
libintl
php7-gettext
php7-iconv
c-client
php7-imap
php7-json
libsasl
libldap
php7-ldap
libmcrypt
php7-pecl-mcrypt
php7-pdo
php7-pdo_mysql
php7-posix
php7-session
Viewing 11 replies - 1 through 11 (of 11 total)

  • php7-json

    Does this match the version of PHP that you have currently installed?

    This is the output from apk info:

    Pardon my Alpine ignorance, but what does the output of this command mean?

    Are the PHP extensions shown here extensions that are merely INSTALLED on the system? Or are they extensions that are ENABLED in the currently running PHP 7 config?

    Can you run a phpinfo(); just to confirm that JSON support is actually ENABLED in your running PHP 7 config?

    Thread Starter HiltonT

    (@hiltont)

    a2hostingrj: Yes, the versions are matching (both 7.4.19-r0)

    George Appiah: That output show installed packages. As to what’s enabled in PHP, that’s a good question – I had naively assumed that by installing the package it would have enabled the module.

    From the output of phpinfo() it seems that it has been. Maybe. I’m not 100% sure…

    Configure Command './configure' '--build=x86_64-alpine-linux-musl' '--host=x86_64-alpine-linux-musl' '--prefix=/usr' '--program-suffix=7' '--libdir=/usr/lib/php7' '--datadir=/usr/share/php7' '--sysconfdir=/etc/php7' '--localstatedir=/var' '--with-layout=GNU' '--with-pic' '--with-pear=/usr/share/php7' '--with-config-file-path=/etc/php7' '--with-config-file-scan-dir=/etc/php7/conf.d' '--disable-short-tags' '--enable-bcmath=shared' '--with-bz2=shared' '--enable-calendar=shared' '--enable-ctype=shared' '--with-curl=shared' '--enable-dba=shared' '--with-dbmaker=shared' '--with-gdbm' '--with-lmdb' '--enable-dom=shared' '--with-enchant=shared' '--enable-exif=shared' '--with-ffi=shared' '--enable-fileinfo=shared' '--enable-ftp=shared' '--enable-gd=shared' '--with-freetype' '--with-jpeg' '--with-webp' '--with-xpm' '--disable-gd-jis-conv' '--with-gettext=shared' '--with-gmp=shared' '--with-iconv=shared' '--with-imap=shared' '--with-imap-ssl' '--enable-intl=shared' '--enable-json=shared' '--with-kerberos' '--with-ldap=shared' '--with-ldap-sasl' '--with-libedit' '--with-libxml' '--enable-mbstring=shared' '--with-mysqli=shared,mysqlnd' '--with-mysql-sock=/run/mysqld/mysqld.sock' '--enable-mysqlnd=shared' '--enable-opcache=shared' '--with-openssl=shared' '--with-system-ciphers' '--with-password-argon2' '--enable-pcntl=shared' '--with-external-pcre' '--enable-pdo=shared' '--with-pdo-dblib=shared' '--with-pdo-mysql=shared,mysqlnd' '--with-pdo-odbc=shared,unixODBC,/usr' '--with-pdo-pgsql=shared' '--with-pdo-sqlite=shared' '--with-pgsql=shared' '--enable-phar=shared' '--enable-posix=shared' '--with-pspell=shared' '--without-readline' '--enable-session=shared' '--enable-shmop=shared' '--enable-simplexml=shared' '--with-snmp=shared' '--enable-soap=shared' '--with-sodium=shared' '--enable-sockets=shared' '--with-sqlite3=shared' '--enable-sysvmsg=shared' '--enable-sysvsem=shared' '--enable-sysvshm=shared' '--with-tidy=shared' '--enable-tokenizer=shared' '--with-unixODBC=shared,/usr' '--enable-xml=shared' '--enable-xmlreader=shared' '--with-xmlrpc=shared' '--enable-xmlwriter=shared' '--with-xsl=shared' '--with-zip=shared' '--with-zlib' '--disable-phpdbg' '--enable-fpm' '--enable-embed' '--enable-litespeed' 'build_alias=x86_64-alpine-linux-musl' 'host_alias=x86_64-alpine-linux-musl'

    • This reply was modified 3 years, 5 months ago by HiltonT.

    You can run this code from the command line:

    php -i | grep 'json'

    You should see an output like this:

    root@server:~# php -i | grep 'json'
/etc/php/7.4/cli/conf.d/20-json.ini,
json
json support => enabled
json support => yes
Available serializers => php, json, igbinary
root@server:~#

    Alternatively, you could create an empty file with .php extension (eg test.php) in the WordPress directory. Add the following one-liner in the file and save.

    <?php phpinfo(); ?>

    Open the file in your browser (eg https://example.com/test.php).

    You should see a nicely formatted page like this, showing your complete PHP configuration as well as all the installed extensions and their state (enabled/disabled).

    What you’re specifically looking for is “JSON Support”, which should say “Enabled”.

    Thread Starter HiltonT

    (@hiltont)

    wordpress:/etc/php7/conf.d# php -i | grep ‘json’
    Configure Command => ‘./configure’ ‘–build=x86_64-alpine-linux-musl’ ‘–host=x86_64-alpine-linux-musl’ ‘–prefix=/usr’ ‘–program-suffix=7’ ‘–libdir=/usr/lib/php7’ ‘–datadir=/usr/share/php7’ ‘–sysconfdir=/etc/php7’ ‘–localstatedir=/var’ ‘–with-layout=GNU’ ‘–with-pic’ ‘–with-pear=/usr/share/php7’ ‘–with-config-file-path=/etc/php7’ ‘–with-config-file-scan-dir=/etc/php7/conf.d’ ‘–disable-short-tags’ ‘–enable-bcmath=shared’ ‘–with-bz2=shared’ ‘–enable-calendar=shared’ ‘–enable-ctype=shared’ ‘–with-curl=shared’ ‘–enable-dba=shared’ ‘–with-dbmaker=shared’ ‘–with-gdbm’ ‘–with-lmdb’ ‘–enable-dom=shared’ ‘–with-enchant=shared’ ‘–enable-exif=shared’ ‘–with-ffi=shared’ ‘–enable-fileinfo=shared’ ‘–enable-ftp=shared’ ‘–enable-gd=shared’ ‘–with-freetype’ ‘–with-jpeg’ ‘–with-webp’ ‘–with-xpm’ ‘–disable-gd-jis-conv’ ‘–with-gettext=shared’ ‘–with-gmp=shared’ ‘–with-iconv=shared’ ‘–with-imap=shared’ ‘–with-imap-ssl’ ‘–enable-intl=shared’ ‘–enable-json=shared’ ‘–with-kerberos’ ‘–with-ldap=shared’ ‘–with-ldap-sasl’ ‘–with-libedit’ ‘–with-libxml’ ‘–enable-mbstring=shared’ ‘–with-mysqli=shared,mysqlnd’ ‘–with-mysql-sock=/run/mysqld/mysqld.sock’ ‘–enable-mysqlnd=shared’ ‘–enable-opcache=shared’ ‘–with-openssl=shared’ ‘–with-system-ciphers’ ‘–with-password-argon2’ ‘–enable-pcntl=shared’ ‘–with-external-pcre’ ‘–enable-pdo=shared’ ‘–with-pdo-dblib=shared’ ‘–with-pdo-mysql=shared,mysqlnd’ ‘–with-pdo-odbc=shared,unixODBC,/usr’ ‘–with-pdo-pgsql=shared’ ‘–with-pdo-sqlite=shared’ ‘–with-pgsql=shared’ ‘–enable-phar=shared’ ‘–enable-posix=shared’ ‘–with-pspell=shared’ ‘–without-readline’ ‘–enable-session=shared’ ‘–enable-shmop=shared’ ‘–enable-simplexml=shared’ ‘–with-snmp=shared’ ‘–enable-soap=shared’ ‘–with-sodium=shared’ ‘–enable-sockets=shared’ ‘–with-sqlite3=shared’ ‘–enable-sysvmsg=shared’ ‘–enable-sysvsem=shared’ ‘–enable-sysvshm=shared’ ‘–with-tidy=shared’ ‘–enable-tokenizer=shared’ ‘–with-unixODBC=shared,/usr’ ‘–enable-xml=shared’ ‘–enable-xmlreader=shared’ ‘–with-xmlrpc=shared’ ‘–enable-xmlwriter=shared’ ‘–with-xsl=shared’ ‘–with-zip=shared’ ‘–with-zlib’ ‘–disable-phpdbg’ ‘–enable-fpm’ ‘–enable-embed’ ‘–enable-litespeed’ ‘build_alias=x86_64-alpine-linux-musl’ ‘host_alias=x86_64-alpine-linux-musl’
    /etc/php7/conf.d/00_json.ini,
    json
    json support => enabled
    wordpress:/etc/php7/conf.d#

    I’m just starting to play with an Alpine Linux (latest) container on my Proxmox (latest) server instance. I want to run a few rather small WordPress site, and figured that as Alpine Linux was a really lightweight distro, that would be a good way to ensure I use no more resources than required.

    That’s a good idea… but sometimes, such a well-intentioned decision can backfire completely. Two things to keep in mind:

    1) While mainstream web server OSes like Debian, Ubuntu, CentOS, etc may have a larger footprint than, say, Alpine, the actual effect of these “unnecessary software” on a web server performance is often minimal, if any. So there may not be as much performance hit as you might think when you use these larger OSes.

    2) Meanwhile server software installed from distros are optimized for the widest compatibility, not for performance. Even when you install directly from upstream sources, default binaries and configuration of software like PHP, Apache/Nginx, MySQL, etc are hardly optimized for performance.

    Meanwhile, there are WordPress “stack” scripts like WordOps (my favourite), Webinoly, EasyEngine, SideSlick, etc that have already done all the hard work of building highly optimized LEMP stacks and config for WordPress.

    One simple command (eg wo stack install for WordOps) will install a highly optimized (for performance) LEMP stack for you — Nginx, MariaDB/MySQL/PercornaDB, and PHP; along with optional utilities like Acme (LetsEncrypt SSL certs), NetData (server monitoring), etc. Plus, you also get object caching (Redis) and/or full-page cache (Nginx FastCache or Redis), and more.

    And another simple command (eg wo site create example.com --wpredis --le for WordOps) creates a WordPress site for the domain example.com, complete with server-based full-page Redis caching and auto-renewed SSL cert from LetsEncrypt.

    The only caveat is that these scripts almost always officially support Debian/Ubuntu only.

    So I guess what I’m saying is: unless you have the skill (and time) to custom compile your webserver stack from sources and tweak their config for optimal performance, you may be leaving a lot of performance gain on the table, even with a lean OS like Alpine.

    And you may actually get better overall performance (and save yourself a lot of time and troubles) by using any of these highly-optimized WordPress LEMP stacks on an OS like Ubuntu/Debian, in spite of the OS’s larger footprint.

    But that’s just my opinion (and experience).

    Good luck!

    Thread Starter HiltonT

    (@hiltont)

    Oh yeah, another thing. I can load the site.org/test.php file without any issues, but when I try and go to site.org/wordpress all I get is the downloaded /wp-config.php file. If I try and load the site.org/wp-config.php file that’s when I get the critical error message.

    Thread Starter HiltonT

    (@hiltont)

    I’ll look into WordOps. The weird thing is that most of the (current) Docker containers are built on Alpine Linux, and that includes nginx, mariadb and wordpress containers. So there’s no doubt what I’m doing is definitely possible, there’s just something I’m either doing, or not doing here that’s causing this issue I’m seeing.

    I’ve got everything else running smoothly – nginx, php7, mariadb, let’s encrypt/certbot and logrotate…

    Thread Starter HiltonT

    (@hiltont)

    I’m much more comfortable with Ubuntu 20.04 than Alpine, but I was hoping to get to love Alpine. ??

    I have been using Linux for *many* years, and have a number of Ubuntu (and even some old Centos 7) VMs in various locations that I’ve been running and maintaining for ages. And then there’s the various RPi setups I have been using for a while (all, basically, based on Debian).

    I just like the idea of a smaller world. But maybe I’ll just go back to a Ubuntu 20.04 container for now and look at getting this Alpine stuff sorted later…

    Thread Starter HiltonT

    (@hiltont)

    …by the way, I have this all running fine in a Ubuntu container. Basically the exact same setup as I’m trying in Alpine. But I like the sound of WordOps, and from the quick read up I have done it looks rather well designed. So I’m installing a new Ubuntu 20.04 container to play with WordOps. ??

    I still want to get the Alpine config working – and then I can do a real comparison of the resource usage of a fresh Alpine WordPress setup and the same under Ubuntu.

    Thread Starter HiltonT

    (@hiltont)

    santiano896: The default for multi_accept is “off”. There is no directive in my nginx.conf for this, therefore the default value of “off” should be in use.

    Therefore I can’t see this being a part of the cause for this WordPress install not working.

    • This reply was modified 3 years, 5 months ago by HiltonT.
Viewing 11 replies - 1 through 11 (of 11 total)
  • The topic ‘There has been a critical error – Alpine, Nginx, MariaDB, PHP7’ is closed to new replies.