Segmentation fault - Same cron used on 3 accounts but only 1 failing

[BlueSteam]

Hello,

My client has 3 websites that uses amazon mailster to send out campaign emails.

The same cron that is setup on all 3 accounts is is working perfectly on 2 of them except one.

Running an strace on the command in question results in a segmenation fault as seen below in the last few lines of output. This is not the full output as it is very long but this is the last few lines.

lstat("/home/#####/public_html/wp-content/plugins/elementor/core/logger", {st_mode=S_IFDIR|0755, st_size=77, ...}) = 0
openat(AT_FDCWD, "/home/#####/public_html/wp-content/plugins/elementor/core/logger/loggers/logger-interface.php", O_RDONLY) = 13
fstat(13, {st_mode=S_IFREG|0644, st_size=1268, ...}) = 0
read(13, "<?php\nnamespace Elementor\\Core\\L"..., 1268) = 1268
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7faaa4d00018} ---
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault (core dumped)
[[email protected] ~]#

Can someone guide me on what exactly is going on here?

 

[cPRex]

Hey there! It would be best to examine the core dump file that was created with the "files" or "gdb" command. More details on working with those can be found here:

How to determine what program or application created a core dump file

Introduction Please keep in mind that the process of identifying core dump files and troubleshooting non cPanel related software with core dump files are tasks that are best handled by a systems ...

support.cpanel.net

I would expect the core dump file to have the details necessary to see what went wrong on the system, although it seems it is likely related to the PHP execution on the files in the "logger" directory you mention.

 

[BlueSteam]

Thanks cPRex

I will dig deeper and revert back

 

[BlueSteam]

The core dump that is created is a lz4 file.

/var/lib/systemd/coredump/core.php.1011.8f11432c493f4f4c889105b3ac2db525.91169.1630068842000000.lz4

running the command file /var/lib/systemd/coredump/core.php.1011.8f11432c493f4f4c889105b3ac2db525.91169.1630068842000000.lz4

just yields the following:

/var/lib/systemd/coredump/core.php.1011.8f11432c493f4f4c889105b3ac2db525.91169.1630068842000000.lz4: LZ4 compressed data (v1.4+)

Am I missing something??

 

[cPRex]

That's interesting - I haven't seen one of those get turned into an LZ4.

Normally I would do this on the file:

gdb core filename.core

but you may have unzip that file first before you can work with it as it is in the lz4 format. But, that's already outside of a cPanel software issue at that point.

 

[BlueSteam]

The file is being generated by a cron job that is executing a php script for amazon mailster.

I will see about unzipping the file first and then running gdb

 

[BlueSteam]

ok, executing gdb on the extracted file yields the following:

Core was generated by `/opt/cpanel/ea-php74/root/usr/bin/php /home/######/public_html/wp-content/plu'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00000000006692a1 in ?? ()

 

[cPRex]

That's progress! So...either that "plu" file has an issue, or PHP 7.4 is broken. Since other PHP pages are working, there's likely some issue with that file.

What happens if you manually execute that command? You could also strace that command of PHP executing that plu page to see if you can repeat the error.

 

[BlueSteam]

So here is a doozy for you....this file is supposedly meant to be in the wp-content folder which as we all know is a wordpress location.

However, there is no such file plu in that location.

 

[cPRex]

Since it's in wp-content, maybe it has already been removed?

 

[BlueSteam]

I don't know...maybe the cron creates the file there and then as part of the cron it cleans it up??

I don't know but this is bizarre!

 

[cPRex]

You could always execute the cron manually to see if that is the case.

However, with the details provided, I'm confident there isn't anything on the cPanel side of things happening that would cause this, and the issue seems specific to that cron or user's files.

 

[BlueSteam]

which is weird because this exact same cron is running on 2 other sites from the same client without issues. :-(
This account was a restore from another server about 2 weeks ago and it worked 100% there.

Only on the new server it doesn't. We don't have the old files to go back and look if the plu file existed there.

 

[BlueSteam]

I opened a support ticket with cPanel about this as well asking for their assistance as this had me stumped and I got a snotty reply from them telling me that they do not really want to assist me because it is not cPanel related.

I have to be honest, I get better, more respectful and kinder assistance from you here FOR FREE than I do from the the team that I am actually paying a PREMIUM license for on a monthly basis.

The support team after whining and complaining about helping me said that they have increased the php memory limit to 256M which was set to 128M. However, I cannot understand this at all because I set the PHP memory limit on the respective cPanel account to 1024M in the event it was that and I verified it was set by running a phpinfo() page and yet it was still failing.

The support staff say that they increased it to 256M and it worked without an issue.

So where the heck did he set it if it was not in the MultiPHP INI Editor? We don't run cloudlinux so where would he have set this??

 

[cPRex]

Could you post the ticket number so I could review that?

 

[BlueSteam]

Sure! here you go.

94357157

 

[cPRex]

Looking now!

 

[BlueSteam]

Thanks cPRex

 

[cPRex]

I'm working with one of our supervisors now to see if we can get you some better details. Hold the line...

 

[BlueSteam]

Whatever the support person did, the problem is gone. He said that he changed the following:

/opt/cpanel/ea-php74/root/etc/php.ini without restarting the web server again because CLI doesn't require the web server to be restarted.

but how does that allow the users account that is running the cron job to run with more memory? I would have thought that upping the memory limit in the MultiPHP INII Editor for the domain would have been sufficient.

Even running a phpinfo() on the domain yielded results showing that the 1024M I set was taking affect and yet the support person said that he upped it to 256M and it worked. so I'm very confused on this one.