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

BlueSteam

Well-Known Member
Feb 21, 2013
100
13
68
cPanel Access Level
Reseller Owner
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

Jurassic Moderator
Staff member
Oct 19, 2014
7,494
1,009
313
cPanel Access Level
Root Administrator
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:


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

Well-Known Member
Feb 21, 2013
100
13
68
cPanel Access Level
Reseller Owner
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

Jurassic Moderator
Staff member
Oct 19, 2014
7,494
1,009
313
cPanel Access Level
Root Administrator
That's interesting - I haven't seen one of those get turned into an LZ4.

Normally I would do this on the file:

Code:
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

Well-Known Member
Feb 21, 2013
100
13
68
cPanel Access Level
Reseller Owner
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
 
  • Like
Reactions: cPRex

BlueSteam

Well-Known Member
Feb 21, 2013
100
13
68
cPanel Access Level
Reseller Owner
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

Jurassic Moderator
Staff member
Oct 19, 2014
7,494
1,009
313
cPanel Access Level
Root Administrator
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

Well-Known Member
Feb 21, 2013
100
13
68
cPanel Access Level
Reseller Owner
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.

:oops::oops::oops:
 

Attachments

BlueSteam

Well-Known Member
Feb 21, 2013
100
13
68
cPanel Access Level
Reseller Owner
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

Jurassic Moderator
Staff member
Oct 19, 2014
7,494
1,009
313
cPanel Access Level
Root Administrator
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.
 
  • Like
Reactions: BlueSteam

BlueSteam

Well-Known Member
Feb 21, 2013
100
13
68
cPanel Access Level
Reseller Owner
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

Well-Known Member
Feb 21, 2013
100
13
68
cPanel Access Level
Reseller Owner
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??
 

BlueSteam

Well-Known Member
Feb 21, 2013
100
13
68
cPanel Access Level
Reseller Owner
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.