Segmentation fault - Same cron used on 3 accounts but only 1 failing
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.
[QUOTE]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, "
Can someone guide me on what exactly is going on here?
Can someone guide me on what exactly is going on here?
-
Thanks cPRex :-) I will dig deeper and revert back 0 -
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?? 0 -
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.0 -
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 0 -
ok, executing gdb on the extracted file yields the following: [QUOTE] 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 ?? () 0 -
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. 0 -
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: 0 -
Since it's in wp-content, maybe it has already been removed? 0 -
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! 0 -
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. 0 -
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. 0 -
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?? 0 -
Could you post the ticket number so I could review that? 0 -
Sure! here you go. 94357157 0 -
Looking now! 0 -
Thanks cPRex :-) 0 -
I'm working with one of our supervisors now to see if we can get you some better details. Hold the line... 0 -
Whatever the support person did, the problem is gone. He said that he changed the following: [QUOTE] /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.0 -
I worked with a supervisor on this and I ended up just replying to the ticket myself. I believe there was an issue with the 1024M change, although I'm still not sure what, but it was only being applied to the user's web content, which would not effect the cron/command line values for PHP. 0 -
Thank you very much Rex, It's really awesome that you are able to assist on this one! So Much respect ! 0 -
You're very welcome! 0 -
You're very welcome!
I did respond to the ticket in case you wanted to know0 -
For sure, as did I just now with some final clarification. 0
Please sign in to leave a comment.
Comments
24 comments