chrooted PDO suddenly needs /etc/resolv.conf in the chroot

[karolyi]

Description

Hey,

With the recent 8.5.4 (FreeBSD package), my roundcube installation that runs chrooted (there is a chroot=/path entry in php-fpm.conf) stopped working.

Upon looking into the error log, PDO complained about not being able to resolve the database server hostname. Upon creating an etc/resolv.conf file in the chroot, it started working again. I wonder, did something change recently regarding how the chroot is handled?

Now if I want to run roundcube chrooted, I need to expose https://roundcubehost/etc/resolv.conf that is within the chroot, and the only way to block it would be via a webserver config entry.

Can somebody please enlighten me if this is intended of if it's a newly introduced bug?

PHP Version

PHP 8.5.4 (cli) (built: Mar 28 2026 02:22:24) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.5.4, Copyright (c) Zend Technologies
    with Zend OPcache v8.5.4, Copyright (c), by Zend Technologies

Operating System

FreeBSD 14.4-RELEASE

[devnexen]

Hi @karolyi this is definitely not a PHP bug ; PHP doesn't handle DNS itself — it delegates to the system.
I would try to seek if there is a change in the related PHP port/package and/or Roundcube (e.g. The database connection previously used an IP address or a Unix socket, and some config change (Roundcube update, DSN change) switched it to a hostname ?).

Hopes it helps.

[karolyi]

Hey @devnexen,

thanks for your reply!

No changes on my end, only the package update —and a roundcube update but the previous version has the same effect with the newer PHP.

I'll look into the FreeBSD ports tree to see if there were any changes and will touch base shortly.

[karolyi]

Strange. I think it's not PHP then. I see that I've been using php8.5.4 for at least 10 days now. I also see that the FreeBSD packager didn't add any significant changes to the 8.5.4 packages, just bumped the version number and the respective hashes. I also peeked into the PHP changelog regarding 'chroot' or 'dns' or 'resolv' changes and saw nothing of the sort.

What changed in the meantime is, I've been upgrading from 14.3-RELEASE to 14.4-RELEASE (which involves a jail redeployment too), and to the best of my knowledge, it must have happened with that.

Apologies for bugging you guys with my problem then. It was worth a question though.

I'll give you the joy of closing this ticket as a redemptive measure :)

[devnexen]

No worries happy to have helped ;)

[kevans91]

Closing the loop a bit in case a similar report makes its way here: this was actually more of a libc thing than a chroot(2) thing. A libc change between the affected version means that more chrooted php-fpm will needs an /etc/resolv.conf because we won't accidentally get it right as often. This bug report has more details on the decision around connecting to 0.0.0.0 for the curious.