cPanel user Cron Jobs generate error_log since 132.0.9 update
Answered
I wasn't able to find other reports of this yet, so it might just be my servers, but...
Ever since my servers updated to 132.0.9 Release Tier at 1:30am December 2nd, user crons created in cPanel > Cron Jobs with this format as used by some popular scripts:
*/5 * * * * /usr/bin/php -q /home/username/public_html/phpscript/cron
Now generates an error_log to /home/username/error_log with the following notice every 5 minutes:
PHP Warning: PHP Startup: Unable to load dynamic library 'xsl.so' (tried: /opt/cpanel/ea-php83/root/usr/lib64/php/modules/xsl.so (/lib64/libxslt.so.1: undefined symbol: xmlGenericErrorContext, version LIBXML2_2.4.30), /opt/cpanel/ea-php83/root/usr/lib64/php/modules/xsl.so.so (/opt/cpanel/ea-php83/root/usr/lib64/php/modules/xsl.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
I've attempted to search for anything similar here on support.cpanel.net , but with this Zendesk forum it's like a needle in a haystack and the closest thing I could find was a post from like 8 years ago where someone mention XSL being integrated to the XML PHP extension.
I've run server software updates in WHM, I've recompiled via EasyApache (and there is no XSL extension available), and rebooted my servers after yum clean all / yum update. No help.
One major clue - the issue only occurs with crons that were created in user accounts via cPanel > Cron Jobs with the /usr/bin/php -q command appended at the start. User crons without /usr/bin/php -q do not seem to be generating the issue.
Has anyone else discovered this?
-
Hey there! The XSL package is built in to modern versions of PHP, so that isn't something that you should have to enable to get things working.
Can you run this command on the server for me?
ls -lah /opt/cpanel/ea-php83/root/usr/lib64/php/modules/xsl.so
to see if that file is present on your machine? I'm wondering if your cron is defaulting to a different version of PHP where this doesn't exist.
0 -
Thanks for the response!
The command returns:
-rwxr-xr-x 1 root root 51K Nov 19 09:56 /opt/cpanel/ea-php83/root/usr/lib64/php/modules/xsl.so
Important details in case you missed:
1. The crons in question have been setup in cPanel > Cron Jobs at least 2 years , and only started generating the error_log entries immediately after the update to 132.0.9 . Like literally within minutes of the update.
2. Only user crons that start with /usr/bin/php -q are generating the error.
0 -
It sounds like this is related to a recent CloudLinux or Imunify change - can you check this and see if that works for you?
0 -
yum update cloudlinux-release
Returns:
This system is receiving updates from CloudLinux Network server.
Last metadata expiration check: 1:20:58 ago on Tue 16 Dec 2025 05:09:17 PM EST.
Dependencies resolved.
Nothing to do.yum groupupdate ea-php83 --enablerepo=cloudlinux-ea4-rollout-12-bypass
Returns:
This system is receiving updates from CloudLinux Network server.
Last metadata expiration check: 0:00:17 ago on Tue 16 Dec 2025 06:30:37 PM EST.
Module or Group 'ea-php83' is not available.
Error: Nothing to do.0 -
That's odd - I feel like that is the same issue, though, so it might be best to create a ticket and then it can always get escalated to CloudLinux if necessary.
0 -
This is broken for PHP 8.4 now. However, my license to cPanel is through Liquid Web and cPanel support can't look at it due to support contracts. Liquid Web support is incompetent and suggests you install the non-existent ea-php84-php-xsl package.
I even tried compiling the RPMs from source but it's still broken. XSL and all the XML libraries have some weird linking. The linking works for libraries in PHP 8.3 but not PHP 8.4. XSL wants libxslt and libexslt which in turn want libxml2. The XSLT libraries are from the system ie. /lib64.
libxml2.15 removed version symbols because they were not being used apparently. However the old xslt libraries from CloudLinux 8 expect them to be there. I don't understand how the XSL extension can have different requirements from the same libraries. It should be the same code between PHP versions.
1 -
cPRex - thank you for the response, and sorry I haven't gotten back. The "holidays" presented a slew of nightmares for me. I will see if I can get my data center to open a cPanel ticket, but that's not always easy.
infomaniac50 - thank you for chiming-in, I don't feel alone now. Sorry to hear you're dealing with it also.
0 -
dnf downgrade ea-libxml2
This will at least get the XSL extension working again. The downside is that everything else gets downgraded too. This might be a security vulnerability depending on what you're doing with the server.
dnf versionlock ea-libxml2
This will pin the version of libxml2 so upcp cron jobs don't update it to libxml2.15 again. The article I linked talks about undoing the version lock.
0 -
Whoops. I forgot to actually linked the article I mentioned.
0 -
Metro2 Does the XSL extension for PHP 8.4 work for you?
ldd /opt/cpanel/ea-php84/root/usr/lib64/php/modules/xsl.so
What distro does your server use? I'm on CloudLinux 8 and it feels like there is an intersection of problems between RHEL versions and libxml2 versions. The problems presented to me are backwards from what was described in the article.
0 -
This is what it looks like when the XSL extension won't load.
ldd /opt/cpanel/ea-php84/root/usr/lib64/php/modules/xsl.so
/opt/cpanel/ea-php84/root/usr/lib64/php/modules/xsl.so: /opt/cpanel/ea-libxml2/lib64/libxml2.so.16: no version information available (required by /lib64/libexslt.so.0)
/opt/cpanel/ea-php84/root/usr/lib64/php/modules/xsl.so: /opt/cpanel/ea-libxml2/lib64/libxml2.so.16: no version information available (required by /lib64/libexslt.so.0)
/opt/cpanel/ea-php84/root/usr/lib64/php/modules/xsl.so: /opt/cpanel/ea-libxml2/lib64/libxml2.so.16: no version information available (required by /lib64/libexslt.so.0)
/opt/cpanel/ea-php84/root/usr/lib64/php/modules/xsl.so: /opt/cpanel/ea-libxml2/lib64/libxml2.so.16: no version information available (required by /lib64/libexslt.so.0)
/opt/cpanel/ea-php84/root/usr/lib64/php/modules/xsl.so: /opt/cpanel/ea-libxml2/lib64/libxml2.so.16: no version information available (required by /lib64/libxslt.so.1)
/opt/cpanel/ea-php84/root/usr/lib64/php/modules/xsl.so: /opt/cpanel/ea-libxml2/lib64/libxml2.so.16: no version information available (required by /lib64/libxslt.so.1)
/opt/cpanel/ea-php84/root/usr/lib64/php/modules/xsl.so: /opt/cpanel/ea-libxml2/lib64/libxml2.so.16: no version information available (required by /lib64/libxslt.so.1)
/opt/cpanel/ea-php84/root/usr/lib64/php/modules/xsl.so: /opt/cpanel/ea-libxml2/lib64/libxml2.so.16: no version information available (required by /lib64/libxslt.so.1)
/opt/cpanel/ea-php84/root/usr/lib64/php/modules/xsl.so: /opt/cpanel/ea-libxml2/lib64/libxml2.so.16: no version information available (required by /lib64/libxslt.so.1)
/opt/cpanel/ea-php84/root/usr/lib64/php/modules/xsl.so: /opt/cpanel/ea-libxml2/lib64/libxml2.so.16: no version information available (required by /lib64/libxslt.so.1)
/opt/cpanel/ea-php84/root/usr/lib64/php/modules/xsl.so: /opt/cpanel/ea-libxml2/lib64/libxml2.so.16: no version information available (required by /lib64/libxslt.so.1)
/opt/cpanel/ea-php84/root/usr/lib64/php/modules/xsl.so: /opt/cpanel/ea-libxml2/lib64/libxml2.so.16: no version information available (required by /lib64/libxslt.so.1)
/opt/cpanel/ea-php84/root/usr/lib64/php/modules/xsl.so: /opt/cpanel/ea-libxml2/lib64/libxml2.so.16: no version information available (required by /lib64/libxslt.so.1)
/opt/cpanel/ea-php84/root/usr/lib64/php/modules/xsl.so: /opt/cpanel/ea-libxml2/lib64/libxml2.so.16: no version information available (required by /lib64/libxslt.so.1)
/opt/cpanel/ea-php84/root/usr/lib64/php/modules/xsl.so: /opt/cpanel/ea-libxml2/lib64/libxml2.so.16: no version information available (required by /lib64/libxslt.so.1)
linux-vdso.so.1 (0x00007fff36ffb000)
libargon2.so.0 => /opt/cpanel/libargon2/lib64/libargon2.so.0 (0x00007f2f57c1c000)
libxml2.so.16 => /opt/cpanel/ea-libxml2/lib64/libxml2.so.16 (0x00007f2f578e4000)
libexslt.so.0 => /lib64/libexslt.so.0 (0x00007f2f576cd000)
libxslt.so.1 => /lib64/libxslt.so.1 (0x00007f2f5748b000)
libm.so.6 => /lib64/libm.so.6 (0x00007f2f57109000)
libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007f2f56deb000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f2f56be7000)
libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007f2f569c6000)
libc.so.6 => /lib64/libc.so.6 (0x00007f2f565f0000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f2f563d0000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2f5802e000)0 -
infomaniac50 - Honestly I haven't had a moment to test anything recently due to other more critical issues and not enough hours in a day, and currently all my clients are ea-php83 . I'm running CloudLinux v8.10.0 STANDARD standard / cPanel Version 132.0.16
0 -
It looks like CloudLinux resolved the issue in the linked article. I would say that if you're still seeing problems today it would be best to create a ticket so this can be investigated directly.
0 -
@cPRex I can't submit a ticket because everything is through LiquidWeb. Furthermore the cPanel article only talks about PHP 8.1 - PHP 8.3. Or least it used to has it was updated 17 hours ago. The author has removed the specific info about PHP versions. As long as I'm seeing updates on things I'm okay with waiting. It seems the cPanel engineers are at least somewhat aware of the problem. I can always dump hardware and software info here so anyone can setup a test box.
0 -
Of course - if you can get me reproduction steps as well as the environment, I'm happy to check as best I can!
0 -
The reproductions steps are just doing anything with php 8.4 and the XSL extension. The XSL extension refuses to load due to missing requirements in ea-libxml2 from other system libraries.
- libxslt.so
- libexslt.so
Here is some basic info I got from a checklist script Liquid Web uses to setup new servers. It is a dedicated server running on bare metal.
I've dumped the rest of the info to a Gist.
See Also: https://gist.github.com/infomaniac50/e99d5523269b7942a7675f3b73b5ab9d
- /root/checklist > checklist.txt
- dnf list --installed > installed.txt
- nm -B -D /opt/cpanel/ea-libxml2/lib64/libxml2.so.16.1.1 > gnu-nm-ea-libxml2.txt
- ldd --verbose /opt/cpanel/ea-php84/root/usr/lib64/php/modules/xsl.so > ldd-verbose-ea-php84-xsl.txt
- lshw -sanitize -notime -quiet > lshw.txt
- ea-php84 -i > php-info.txt
- php -m > php-list-modules.txt
--------------------------
"CloudLinux release 8.10 (Vladimir Aksyonov)"
--------------------------
Motherboard:
Product Name: X11SPL-F
BIOS version: 4.0
Processor:
Intel(R) Xeon(R) Gold 6226R CPU @ 2.90GHz
Memory:
64GB
Disk and Partitioning details:
Name, Size, Model Number
sda 3.7T ST4000NM000A-2HZ
sdb 893.8G MR9341-4i
Partition, Filesystem, Size, Mountpoint, Label
└─sda1 ext4 3.7T /backup
├─sdb1 vfat 200M /boot/efi
├─sdb2 ext3 1G /boot
├─sdb3 swap 8G [SWAP]
└─sdb4 ext4 884.6G /0 -
I made a bunch of edits. I don't know if this forum sends updates from edits. I'm pretty much done now. Let me know if you want anything else.
0 -
Let me try this on my end and I'll let you know what I find!
0 -
Thanks for the specific details - I did speak with CloudLinux about this and this is something they are tracking with case EA4D-731.
There is a temporary fix where you can run:
yum downgrade ea-libxml2
and that will resolve the errors, and they are working on a more permanent resolution through that case. You can follow along at https://cloudlinux.zendesk.com/hc/en-us/articles/23597026828444--opt-cpanel-ea-libxml2-lib64-libxml2-so-2-no-version-information-available-required-by-opt-cpanel-ea-php83-root-usr-bin-php for more details if you'd like.
0 -
We experienced this issue last month with ea-php83, where we first followed the suggestion from the support article and downgraded (and versionlocked) ea-libxml, however this caused issues where cPanel package updates were failing (because ea-php* packages couldn't be updated, e.g. package ea-php83-php-xml-1:8.3.27-1.el9.cloudlinux.1.x86_64 from cl-ea4 requires ea-libxml2 >= 2.15, but none of the providers can be installed).
We wrote a ticket to cPanel (#95862108), and the solution ended up being updating the ea-php83-php-xml package using one of cloudlinux' bypass repos:
# dnf upgrade ea-php83-php-xml --enablerepo=cloudlinux-ea4-rollout-12-bypassSince then, it looks like that version of ea-php83-php-xml (1:8.3.28-1.el9.cloudlinux) has also been released to the "regular" cl-ea4 repo.
Unfortunately, we're now also experiencing the issue with both ea-php84 and ea-php85.
Attempting to downgrade ea-libxml gives an error because ea-php85-php-xml (1:8.5.0-1.el9.cloudlinux) requires ea-libxml >= 2.15 (and there isn't another version of ea-php85-php-xml available in the cl-ea4 repo). We can see that ea-php84-php-xml 8.4.16-1.3.1.cpanel and ea-php84-php-xml 8.4.16-1.3.1.cpanel are available from the EA4-c9 repo, so maybe the fix is in those upgrades once they come to the cl repo..?For good measure, we've created a new ticket with cPanel (#95902987) to follow up on this issue.
(Edit: The above was written with cloudlinux 9 in mind, but as far as we can tell, it's the exact same issue with CL8. (Un-)luckily we also have a server running CL8 😅)
0 -
Yes, it would be the same CloudLinux issue on all versions until they resolve that problem. Unfortunately this one isn't up to us to fix, but after speaking with CloudLinux yesterday about this it seems that they are close to a resolution.
0 -
A quick update here:
We wrote to CloudLinux about the issue, and they have indicated that updated packages should be available in the beta repository, and should hit the stable repo within 1-2 weeks.
0 -
Thanks for sharing that timeline!
0 -
This is happening on AlmaLinux too
0 -
Update regarding libxml on ea-php84 and ea-php85: Cloudlinux has updated the relevant ea-php*-php-* libraries (such as ea-php85-php-xml: ea-php85-php-xml-1:8.5.2-1.el9.cloudlinux.2.x86_64), and it seems the issue has been resolved.
0 -
Thanks for sharing, Jens Andersen!!!
0 -
I removed the dnf version lock and everything seems to be working now. No more loader errors about libxml and PHP XSL.
0 -
Thanks for that extra confirmation infomaniac50!
0
Please sign in to leave a comment.
Comments
28 comments