HestiaCP Configure: Internal Server Error 500

Hi,

On my (recently updated 1.9.9) HestiaCP, if I connect to the admin page, click the Config cog and then click “Configure” (the button), I end up on an internal server error 500

The log shows this error:

2026/08/11 20:48:59 [error] 1119#0: *143 FastCGI sent in stderr: "PHP message: PHP Fatal error: Uncaught TypeError: array_filter(): Argument #1 ($array) must be of type array, null given in /usr/local/hestia/web/edit/server/index.php:157
Stack trace:
#0 /usr/local/hestia/web/edit/server/index.php(157): array_filter()
#1 {main}
thrown in /usr/local/hestia/web/edit/server/index.php on line 157" while reading response header from upstream, client: 90.73.239.214, server: _, request: "GET /edit/server/ HTTP/2.0", upstream: "fastcgi://unix:/run/hestia-php.sock:", host: "nnn.nnn.nnn.nnn:8083", referrer: "``https://nnn.nnn.nnn.nnn:8083/list/server/``"
2026/08/11 20:49:33 [error] 17572#0: *1 FastCGI sent in stderr: "PHP message: PHP Fatal error: Uncaught TypeError: array_filter(): Argument #1 ($array) must be of type array, null given in /usr/local/hestia/web/edit/server/index.php:157
Stack trace:
#0 /usr/local/hestia/web/edit/server/index.php(157): array_filter()
#1 {main}
thrown in /usr/local/hestia/web/edit/server/index.php on line 157" while reading response header from upstream, client: 90.73.239.214, server: _, request: "GET /edit/server/ HTTP/2.0", upstream: "fastcgi://unix:/run/hestia-php.sock:", host: "``nnn.nnn.nnn.nnn``:8083", referrer: "``https://nnn.nnn.nnn.nnn:8083/list/server/``"

Another server, Configure works fine and show s the correct sections.

Thanks for any idea?
Steve J

Hi,

please provide us the output of this command:

sed -n '150,165p' /usr/local/hestia/web/edit/server/index.php

Looks like a issue with database.conf in /usr/local/hestia/conf/

// List Database hosts
exec(HESTIA_CMD . "v-list-database-hosts json", $output, $return_var);
$db_hosts = json_decode(implode("", $output), true);
unset($output);
$v_mysql_hosts = array_values(
array_filter($db_hosts, function ($host) {
return $host["TYPE"] === "mysql";
}),
);
$v_mysql = count($v_mysql_hosts) ? "yes" : "no";
$v_pgsql_hosts = array_values(
array_filter($db_hosts, function ($host) {
return $host["TYPE"] === "pgsql";
}),

Do you have any database server installed? like mysql, mariadb, postgresql?

show the output of:

v-list-database-hosts json

Obviously something with a remaining old DB that was installed directly with the basic provider DB tools:

[
Invalid key value format. Could not extract key name from: #HOST='localhost' USER='root' PASSWORD='nnnnn' CHARSETS='UTF8,LATIN1,WIN1250,WIN1251,WIN1252,WIN1256,WIN1258,KOI8' MAX_DB='500' U_SYS_USERS='' U_DB_BASES='1' SUSPENDED='no' TIME='08:11:31' DATE='2024-08-26' PORT='3306'
Error: Invalid object format: #HOST='localhost' USER='root' PASSWORD='nnnnnnn' CHARSETS='UTF8,LATIN1,WIN1250,WIN1251,WIN1252,WIN1256,WIN1258,KOI8' MAX_DB='500' U_SYS_USERS='' U_DB_BASES='1' SUSPENDED='no' TIME='08:11:31' DATE='2024-08-26' PORT='3306'

I don’t use any DB installed from HestiacCP.
All of my DBs are self-contained into docker containers. Nothing outside.

I remember that at some point, HestiaCP was struggling with databases since it referenced one existing one that was not present… That’s probably why it shows U_DB_BASES='1'

Probably need to cleanup something with a SQL command. But how :slight_smile:

If I type mysql or mariadb, I get
Can't connect to local server through socket '/run/mysqld/mysqld.sock'

Check the file:

cat /usr/local/hestia/conf/mysql.conf

show me the output

you will see something like this: #HOST=‘localhost’ USER=‘root’ PASSWORD=‘…’ …

make it: HOST=‘localhost’ USER=‘root’ PASSWORD=‘…’ … as @sahsanu mention need to uncomment it, remove the #

You commented out the lines in conf file /usr/local/hestia/conf/mysql.conf, remove the # in front of the HOST keys in that file.

Ok that did it.
Funny thing is I had two lines and it looks like if I uncomment the first one it works.

If I comment the first one it doesn’t work.
If I uncomment it and comment the 2nd one it doesn’t work either…
If both are uncommented, it works.

Isn’t the second line setting HOST again overriding the first one?

But now I get error messages by email:
Can’t connect to MySQL localhost:3306
ERROR 2002 (HY000): Can’t connect to local server through socket ‘/run/mysqld/mysqld.sock’ (2)

I’ll tinker with the password in the my.cnf, etc… until it works.

You can use v-delete-database-host mysql localhost and delete the db since you are working with docker.

I will.
This command doesn’t work as it doesn’t know which HOST to suppress.
I tried with only one line at a time and the correct matching password in /root/mysql.conf

I will check all references to all mysql conf files and clean up or correct the credentials by hand.

That’s weird
If I uncomment both HOST=… in the /usr/local/hestia/conf/mysql.conf file, the configure button works.
The order of the HOST= doesn’t matter.

If I set either password in /root/.my.cnf then HestiaCP works but I keep getting a hestiacp mail with the error:
Can't connect to MySQL localhost:3306
ERROR 2002 (HY000): Can't connect to local server through socket '/run/mysqld/mysqld.sock' (2)

Then I stopped and restarted mysqld on my server but it fails no matter what with those errors:
provider_bzip2=force_plus_permanent'
provider_lz4=force_plus_permanent'
provider_lzma=force_plus_permanent'
provider_lzo=force_plus_permanent'
provider_snappy=force_plus_permanent'

If I comment just one of the lines in /usr/local/hestia/conf/mysql.conf then I don’t get the errors anymore but I can’t reach the configure section with the error 500, no matter what password matches in /usr/local/hestia/conf/mysql.conf

And /run/mysql doesn’t ever see any kind of socket file there, even though owner and chmod rights are fine.

apt install mariadb-plugin-provider-bzip2 mariadb-plugin-provider-lz4 mariadb-plugin-provider-lzma mariadb-plugin-provider-lzo mariadb-plugin-provider-snappy

And whether mariadb starts:

systemctl restart mariadb
systemctl status mariadb --no-pager -l

Ok mariadb did start this time.

And apparently, no more error message.
Once again, you made my day :slight_smile: