Fatal error insufficient shared memory reg ru

Проблемы с агентами cron

Добрый день!
Сайт на Битрикс распологается на сотинге reg.ru
У фрилансеров заказали подсайты для регионов. После этого начались проблемы на основном сайте с планировщиком.

При выполнении задачи
/opt/php/7.2-bx-optimized/bin/php -c

/www/site.ru/bitrix/modules/main/tools/cron_events.php
в планировщике возникает ошибка

u0111111$ /opt/php/7.0-bx-optimized/bin/php -c

/www/site.ru/bitrix/modules/main/tools/cron_events.php
PHP Warning: require_once(/var/www/u0111111/data/www/sbx15.hosting.reg.ru:1500/bitrix/modules/main/start.php): failed to open stream: No such file or directory in /var/www/u0111111/data/www/site.ru/bitrix/modules/main/include.php on line 10
PHP Fatal error: require_once(): Failed opening required ‘/var/www/u0111111/data/www/sbx15.hosting.reg.ru:1500/bitrix/modules/main/start.php’ (include_path=’.:’) in /var/www/u0111111/data/www/site.ru/bitrix/modules/main/include.php on line 10

на 2 подсайтах теже самые задачи выполняются без проблем.
Скрипты полностью идентичны, т.к. подсайты были полностью скопированы с основного.

В поддержке регру сначало посоветовали:
«Сравнили скрипты, различий не выявлено. Как мы можем видеть ,сейчас tlt.site.ru добавлен как автоподдомен для site.ru. Учитывая особенности CMS Битрикс, которая некорректно работает с автоподдоменами, мы рекомендуем добавить tlt.site.ru как отдельный www-домен и проверить актуальность проблемы.»

Но это результатов не дало. После этого они открестились:
«Как уже сообщалось ранее проблем со стороны хостинга не наблюдаем. Задание в планировщике написано корректно. Вопрос диагностики работы скриптов сайта выходит за рамки услуг, оказываемых специалистами технической поддержки хостинга. Для решения подобного вопроса мы рекомендуем вам обратиться к специалистам, которые занимались разработкой вашего сайта. Кроме того, интересующую вас информацию вы можете найти на тематических ресурсах, посвящённых разработке используемой вами CMS.»

Источник

I am running LAMP in VBox6.1 with Ubnutu Server 20.04.

Cause
This morning I removed all attachments to my vdi (optical disk & shared folders) and then used vboxmanage to —compact my vdi as recommended. (Compacting may be the cause of the problem or a bad php update.)

Problem
In any case, after reattaching my shared folders and rebooting my vdi, I was greeted by

Troubleshooting
I figured a bad php update knocked out apcu and redis so I ran: apt install —reinstall php8.0-apcu && apt install —reinstall php8.0-redis and this solved two parts of my problem.

However, I am currently stuck with this error:

Useful Info

• All other versions of php-fpm are working correctly
• Attempting to reinstall php8.0-fpm results i the same problem
• The are zero limits on my shared memory:
• # sysctl -a | grep kernel.shm

• I booted from LiveCD and ran e2fsck -cfyv /dev/mapper/vgubuntu-vg (no errors)
• The php8.0 php.ini confirms that shared memory is configured properly:

I also considered that maybe another application was consuming allof the shared memory and causing php8.0-fpm to fail. not the case:

So at this point, I am stumped. 🤔🤔🤔

Question:
How do I get php8.0-fpm-running again?

Источник

Fatal Error Zend OPcache cannot allocate buffer for interned strings #2293

Creating a bug report/issue:

Cannot install any software after 6.18 update.

Required Information:

• DietPi version | cat /DietPi/dietpi/.version

• Distro version | echo $G_DISTRO_NAME or cat /etc/debian_version

• Kernel version | uname -a

Linux DietPi 4.14.78-sunxi #412 SMP Fri Oct 26 11:37:04 CEST 2018 armv7l GNU/Linux

• SBC device | echo $G_HW_MODEL_DESCRIPTION or (EG: RPi3)

OrangePi Zero (armv7l)

• Power supply used | (EG: 5V 1A RAVpower)

• SDcard used | (EG: SanDisk ultra)
  EMTEC 16GB, class 10

Additional Information (if applicable):

• Software title | (EG: Nextcloud)
  Any
• Was the software title installed freshly or updated/migrated?
  Fresh
• Can this issue be replicated on a fresh installation of DietPi?
  I don’t know
• dietpi-bugreport ID
  9444d4b6-b4e7-4096-9996-a532804506cf

Steps to reproduce:

1. For instance try to install LinuxDash
   sudo dietpi-software install 63

Expected behaviour:

• Install the software and reboot

Actual behaviour:

Tue Nov 27 00:11:50 2018 (4528): Fatal Error Zend OPcache cannot allocate buffer for interned strings
/DietPi/dietpi/dietpi-software: line 7469: / 1024 / 1024: syntax error: operand expected (error token is «/ 1024 / 1024»)

• Also this error somewhere in between:

Tue Nov 27 00:32:17 2018 (6687): Fatal Error Zend OPcache cannot allocate buffer for interned strings

The text was updated successfully, but these errors were encountered:

@Twilight0
Thanks for your report.

The command that fails is: php -r ‘print(PHP_INT_MAX);’
Works well here on VirtualBox Stretch and dietpi-software install 63 went through without error:

Fatal Error Zend OPcache cannot allocate buffer for interned strings

Something with PHP OPcache module seems to be broken.

OPcache can be configured via: opcache.interned_strings_buffer in php.ini / opcache.ini . The only case where we touch this is on Nextcloud install. But using the value we add there opcache.interned_strings_buffer=8 works well here as well. Default is 4 .

Can you check if/where you set this value:
grep ‘opcache.interned_strings_buffer’ /etc/php/7.0/*/*.ini /etc/php/7.0/*/*/*.ini

Possibly a reinstall of the OPcache module will fix: apt-get -y install —reinstall php7.0-opcache

I am sorry but I get frustrated easily sometimes and re-installed DietPi from scratch. I ‘ll provide report if necessary from the fresh install or close and comment it if everything is fine.

I will close this issue as it looks like it is ok on fresh installations. I had tweaked something according to this comment when tried to installed nextcloud on 6.17, probably something broke: #2192 (comment)

Reopening this issue. yeah I tried installing nextcloud once again since you claim it has been fixed for 6.18.
And it failed gloriously with the same error. And yes I tried this after re-installing php7.0-opcache.

So this is the output of grep ‘opcache.interned_strings_buffer’ /etc/php/7.0/*/*.ini /etc/php/7.0/*/*/*.ini :

/etc/php/7.0/cli/php.ini:;opcache.interned_strings_buffer=4
/etc/php/7.0/fpm/php.ini:;opcache.interned_strings_buffer=4
/etc/php/7.0/mods-available/opcache.ini:opcache.interned_strings_buffer=8
/etc/php/7.0/phpdbg/php.ini:;opcache.interned_strings_buffer=4
/etc/php/7.0/cli/conf.d/10-opcache.ini:opcache.interned_strings_buffer=8
/etc/php/7.0/fpm/conf.d/10-opcache.ini:opcache.interned_strings_buffer=8
/etc/php/7.0/phpdbg/conf.d/10-opcache.ini:opcache.interned_strings_buffer=8

@Twilight0
Thanks for testing. Jep this issue is a different one than: #2192 (comment)

We will have to do some research about when/why this issue can occur. I am stuck currently since everything looks as expected.

Just, because this is the only place where we touch OPcache settings, can you try to comment all opcache.* lines inside /etc/php/7.0/mods-available/opcache.ini (not the one that loads the module itself, just the settings. Comment them with ; .
Then:

and see if the error still shows up (with default settings then).

https://forums.zend.com/viewtopic.php?t=113253
memory_limit , must this in case be as large as opcache.memory_consumption + opcache.interned_strings_buffer , so being an overall limit? But actually no chance to hit that with Nextcloud 🤔 .

@Twilight0
Okay some more to check, going through the memory limits and consumptions:

And you can also check the actual PHP memory consumption of OPcache and APCu:

Ah just saw you sent a bug report. I will also go through it there.

Issue appears limited to this device + pre-image. Could be a PREP issue (unlikely if everything else is working fine)

Which pre-image/image did you use for the OPi Zero?

Armbian’s one. Stable PREP script & stable Dietpi release. Will report back when I have time to test things out.

@Twilight0
Could you please paste the output of above mentioned commands? If all this is as expected, perhaps there is a sysctl.conf/sysctl.d/*.conf entry that somehow limits memory allocation. Not sure what’s possible there.
And could you send a bug report?

But perhaps it’s easiest of @Fourdee can try to replicate, if you have a OPi Zero there? Even it is an issue with a non-officially supported device, perhaps there is some setting outside of PHP that causes this issue that we then need to check/adjust on PHP install.

grep ‘memory_limit’ /etc/php/7.0/*/*.ini /etc/php/7.0/*/*/*.ini

/etc/php/7.0/cli/php.ini:memory_limit = -1
/etc/php/7.0/fpm/php.ini:memory_limit = 128M
/etc/php/7.0/phpdbg/php.ini:memory_limit = 128M

grep ‘opcache.memory_consumption’ /etc/php/7.0/*/*.ini /etc/php/7.2/*/*/*.ini

/etc/php/7.0/cli/php.ini:;opcache.memory_consumption=64
/etc/php/7.0/fpm/php.ini:;opcache.memory_consumption=64
/etc/php/7.0/mods-available/opcache.ini:opcache.memory_consumption=10
/etc/php/7.0/phpdbg/php.ini:;opcache.memory_consumption=64
grep: /etc/php/7.2///*.ini: No such file or directory

grep ‘apc.shm_size’ /etc/php/7.0/*/*.ini /etc/php/7.2/*/*/*.ini

/etc/php/7.0/mods-available/apcu.ini:apc.shm_size=10M
grep: /etc/php/7.2///*.ini: No such file or directory

Filesystem 1K-blocks Used Available Use% Mounted on
udev 87112 0 87112 0% /dev
tmpfs 24580 4592 19988 19% /run
/dev/mmcblk0p1 14905760 3211112 11517444 22% /
tmpfs 122888 0 122888 0% /dev/shm
tmpfs 5120 0 5120 0% /run/lock
tmpfs 122888 0 122888 0% /sys/fs/cgroup
/dev/sdb1 3658611 26655 3432225 1% /mnt/flash
/dev/sda1 976760532 749137600 227622932 77% /mnt/toshiba
tmpfs 1047552 0 1047552 0% /tmp
tmpfs 10240 1476 8764 15% /DietPi
tmpfs 51200 120 51080 1% /var/log

total used free shared buff/cache available
Mem: 240 65 58 13 116 153
Swap: 1807 0 1807

However these are after clean install plus a few things without Nextcloud marked, because in case I try installing Nextcloud, it will ruin the system with ncc maintenance error messages etc.

Details:

• Date | Mon 4 Feb 04:37:16 CET 2019
• Bug report | N/A
• DietPi version | v6.20.6 (Fourdee/master)
• Img creator | DietPi Core Team
• Pre-image | Raspbian Lite
• SBC device | RPi 3 Model A+ (armv7l) (index=3)
• Kernel version |

Letsencrypt supports Free Noip.com Dynamic DNS #1159 SMP Sun Nov 4 17:50:20 GMT 2018

Steps to reproduce:

1. Install Nextcloud through dietpi-software .

Expected behaviour:

Actual behaviour:

• Installation interrupts with error.

• Selected Nextcloud to be installed from dietpi-software . DietPi was freshly set up, nothing was on storage, yet.

Additional logs:

Log file contents:
Mon Feb 4 04:35:56 2019 (22158): Fatal Error Zend OPcache cannot allocate buffer for interned strings

No OPi specific issue then. @Akito13 could you please as well paste the outputs as mentioned above: #2293 (comment)

Nothing to do with your application that I don’t know, however, I’m confronted with this bug.

Indeed, I have a firewall in VM Pfsense that runs with 256Mb, if I pass it to 512MB of RAM, I have the error mentioned.

@jbsky
Thanks for sharing.

Possibly this error can occur on low RAM systems (256M) if the PHP/OPcache memory limits exceed available (or free?) RAM.

Strange is that the error states the interned strings buffer allocation to fail, since this one is very small (4M default, 8M as we set on Nextcloud install due to admin panel warnings/recommendation).
What should fail in the first place is the overall OPcache memory limit which is 128M by default since PHP7.0.

And you say if you set overall PHP memory limit from 512M (default on Debian) to 256M, it does not occur? Even more strange.

I will play around with a 256M memory VM as well and try to replicate.

I ran into this same issue @MichaIng and you are correct it will throw this error on low RAM systems that use more than the actually amount available.

I have an application that I cranked the instance size up and adjusted opcache.memory_consumption. Friday I turned it back down as there is no traffic over the weekend and came into that error.

I actually didn’t adjust the PHP memory limit for itself. Just the opcache memory consumption so that may help some in tracking it down.

Okay I reopen this to not forget the testing on VM. We’ll see if it depends on total memory, free memory and if total PHP memory limit has any effect.

Hmm just got on fresh 1 GiB RAM Buster VirtualBox machine:

The PHP memory limit is below the recommended value of 512MB.

The following then solves the warning:

Since we do not touch this value, it’s Debian Buster package default:

Strange that I never faced this before. New on Nextcloud side? Would be a real problem since low RAM devices (RPi1 with 256M) are perfectly able to run a single user or family Nextcloud instance and should never set memory_limit > 128M of course.

Okay, I ran some tests and was able to produce the following error on PHP-FPM start/restart:

Basically this appears in two cases:

1. The virtual memory of any PHP child process exceeds the available system memory, including swap files, minus a few megabytes.

• The assigned opcache.memory_consumption increases the virtual memory usage 1-to-1.
• The assigned opcache.interned_strings_buffer has no effect on virtual memory usage, it seems to be included in the overall OPcache memory consumption.
• memory_limit as well has no influence, also I think the border at which those are active, are different. opcache.memory_consumption limits the overall OPcache consumption, as it’s virtual/shared memory, across all PHP-FPM child processes, I guess, while memory_limit is a per-script limit.

1. opcache.interned_strings_buffer is equal or larger than opcache.memory_consumption .

• This fits the above assumption that opcache.interned_strings_buffer is included in opcache.memory_consumption .
• However default values and those applied by us on Nextcloud installs provide a every large difference between the two sizes (default: 128 vs 4, DietPi + Nextcloud: 512 vs 8), hence this cannot be a reason. EDIT: Confused with memory_limit

If I reduce system memory or raise memory usage by other processes, while keeping the above rules, I run into usual OOM killer.

Источник

Добрый день!
Сайт на Битрикс распологается на сотинге reg.ru
У фрилансеров заказали подсайты для регионов. После этого начались проблемы на основном сайте с планировщиком.

При выполнении задачи
/opt/php/7.2-bx-optimized/bin/php -c ~/php-bin/php.ini -f ~/www/site.ru/bitrix/modules/main/tools/cron_events.php
в планировщике возникает ошибка

u0111111$ /opt/php/7.0-bx-optimized/bin/php -c ~/php-bin/php.ini -f ~/www/site.ru/bitrix/modules/main/tools/cron_events.php
PHP Warning:  require_once(/var/www/u0111111/data/www/sbx15.hosting.reg.ru:1500/bitrix/modules/main/start.php): failed to open stream: No such file or directory in /var/www/u0111111/data/www/site.ru/bitrix/modules/main/include.php on line 10
PHP Fatal error:  require_once(): Failed opening required ‘/var/www/u0111111/data/www/sbx15.hosting.reg.ru:1500/bitrix/modules/main/start.php’ (include_path=’.:’) in /var/www/u0111111/data/www/site.ru/bitrix/modules/main/include.php on line 10

на 2 подсайтах теже самые задачи выполняются без проблем.
Скрипты полностью идентичны, т.к. подсайты были полностью скопированы с основного.

В поддержке регру сначало посоветовали:
«Сравнили скрипты, различий не выявлено. Как мы можем видеть ,сейчас tlt.site.ru добавлен как автоподдомен для site.ru. Учитывая особенности CMS Битрикс, которая некорректно работает с автоподдоменами, мы рекомендуем добавить tlt.site.ru как отдельный www-домен и проверить актуальность проблемы.»

Но это результатов не дало. После этого они открестились:
«Как уже сообщалось ранее проблем со стороны хостинга не наблюдаем. Задание в планировщике написано корректно. Вопрос диагностики работы скриптов сайта выходит за рамки услуг, оказываемых специалистами технической поддержки хостинга. Для решения подобного вопроса мы рекомендуем вам обратиться к специалистам, которые занимались разработкой вашего сайта. Кроме того, интересующую вас информацию вы можете найти на тематических ресурсах, посвящённых разработке используемой вами CMS.»

Заранее благодарю за помощь!

1С-Битрикс: Управление сайтом 17.5.16.

Если на вашем сервере наблюдается нехватка оперативной памяти, часть процессов завершаются в аварийном режиме.

Как правило, в системном журнале /var/log/messages при этом присутствуют подобные записи:

Jul 27 15:30:04 ovzhost67 kernel: [656617.064898] Out of memory in UB 1234567: OOM killed process 617206 (mysqld) score 0 vm:373508kB, rss:68004kB, swap:0kB

Одни из причин возникновения проблемы:

• ваш сайт стал более популярным, количество посещений увеличилось;
• на ваши сайты проводится атака по подбору паролей;
• были установлены ресурсоёмкие плагины;
• было установлено дополнительное ресурсоёмкое ПО.

Решение проблемы

Ниже приведены действия, которые могут помочь устранить проблему. Желательно применять их в совокупности.

Защитите админку сайта

Очень часто причиной нехватки ОЗУ является brute-force атака на админку сайта. В этом случае злоумышленники пытаются взломать админку сайта простым подбором паролей. Это характеризуется большим количеством запросов в журналах сайтов (Как просмотреть журналы сайтов? ), например, таких:

70.32.89.233 - - [31/Dec/2014:07:17:50 +0300] mysite.ru POST /wp-login.php HTTP/1.0 302 0 "-" "-" "-" 0.348-0.222
70.32.89.233 - - [31/Dec/2014:07:17:51 +0300] mysite.ru POST /wp-login.php HTTP/1.0 302 0 "-" "-" "-" 0.339-0.210
70.32.89.233 - - [31/Dec/2014:07:17:51 +0300] mysite.ru POST /wp-login.php HTTP/1.0 302 0 "-" "-" "-" 0.334-0.206
70.32.89.233 - - [31/Dec/2014:07:17:52 +0300] mysite.ru POST /wp-login.php HTTP/1.0 302 0 "-" "-" "-" 0.333-0.207
70.32.89.233 - - [31/Dec/2014:07:17:52 +0300] mysite.ru POST /wp-login.php HTTP/1.0 302 0 "-" "-" "-" 0.347-0.222

В данном примере видно, что атакуют админку WordPress. Для других CMS примеры аналогичны, меняется только URL админки.

Для снижения нагрузки на CPU и защиты вашего сайта установите дополнительную форму аутентификации на админку сайта:

Как защитить админку WordPress?

Как защитить админку Joomla?

Оптимизация сайта

Удаление ненужных расширений и плагинов сайтов. Удаление ресурсоёмких плагинов.

Включение кэша сайта

Особенно актуально для Bitrix, однако будьте осторожны, кэш Bitrix может быстро разрастись и занять много места на диске.

Установка Nginx

«Nginx» занимается отдачей статического контента (css, изображения, текст) гораздо быстрее чем «Apache». Установка «Nginx» снимет часть нагрузки с «Apache».

Установка акселератора (ускорителя) PHP

Производится самостоятельно, либо в рамках услуги «Администрирование сервера».

Оптимизация Mysql

Для тестирования Mysql рекомендуем воспользоваться скриптом Mysqltuner.

Также, оптимизация Mysql возможна в рамках услуги «Администрирование сервера».

Повышение тарифного плана

Если проблемы все еще остались, рекомендуем перейти на более высокий тарифный план: Как повысить тариф VPS

I am running LAMP in VBox6.1 with Ubnutu Server 20.04.

Cause
This morning I removed all attachments to my vdi (optical disk & shared folders) and then used vboxmanage to --compact my vdi as recommended. (Compacting may be the cause of the problem or a bad php update.)

Problem
In any case, after reattaching my shared folders and rebooting my vdi, I was greeted by

● php8.0-fpm.service loaded failed failed The PHP 8.0 FastCGI Process Manager
...
Starting The PHP 8.0 FastCGI Process Manager...
php-fpm8.0[5192]: [15-Jan-2023 07:41:57] NOTICE: PHP message: PHP Warning:  PHP Startup: Unable to load dynamic library 'apcu.so' (tried: /usr/lib/php/20200930/apcu.so (/usr/lib/php/20200930/apcu.so: cannot open shared object file: No such file or directory), /usr/lib/php/20200930/apcu.so.so (/usr/lib/php/20200930/apcu.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
php-fpm8.0[5192]: [15-Jan-2023 07:41:57] NOTICE: PHP message: PHP Warning:  PHP Startup: Unable to load dynamic library 'redis.so' (tried: /usr/lib/php/20200930/redis.so (/usr/lib/php/20200930/redis.so: cannot open shared object file: No such file or directory), /usr/lib/php/20200930/redis.so.so (/usr/lib/php/20200930/redis.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
php-fpm8.0[5192]: Sun Jan 15 07:41:57 2023 (5192): Fatal Error Insufficient shared memory!
php8.0-fpm.service: Main process exited, code=exited, status=254/n/a
php8.0-fpm.service: Failed with result 'exit-code'.
ystemd[1]: Failed to start The PHP 8.0 FastCGI Process Manager.
....

Troubleshooting
I figured a bad php update knocked out apcu and redis so I ran: apt install --reinstall php8.0-apcu && apt install --reinstall php8.0-redis and this solved two parts of my problem.

However, I am currently stuck with this error:

● php8.0-fpm.service loaded failed failed The PHP 8.0 FastCGI Process Manager
...
Starting The PHP 8.0 FastCGI Process Manager...
php-fpm8.0[4226]: Sun Jan 15 08:39:51 2023 (4226): Fatal Error Insufficient shared memory!
php8.0-fpm.service: Main process exited, code=exited, status=254/n/a
php8.0-fpm.service: Failed with result 'exit-code'.
Failed to start The PHP 8.0 FastCGI Process Manager.
...

Useful Info

• All other versions of php-fpm are working correctly
• Attempting to reinstall php8.0-fpm results i the same problem
• The are zero limits on my shared memory:
• # sysctl -a | grep kernel.shm

    kernel.shm_next_id = -1
    kernel.shm_rmid_forced = 0
    kernel.shmall = 18446744073692774399
    kernel.shmmax = 18446744073692774399
    kernel.shmmni = 4096

• I booted from LiveCD and ran e2fsck -cfyv /dev/mapper/vgubuntu-vg (no errors)
• The php8.0 php.ini confirms that shared memory is configured properly:

root@test:~# php8.0 -i | grep -i sysvshm
/etc/php/8.0/cli/conf.d/20-sysvshm.ini,
sysvshm
sysvshm support => enabled
root@test:~# php8.0 -i | grep -i sysvsem
/etc/php/8.0/cli/conf.d/20-sysvsem.ini,
sysvsem
sysvsem support => enabled
root@test:~# php8.0 -i | grep -i sysvmsg
/etc/php/8.0/cli/conf.d/20-sysvmsg.ini,
sysvmsg
sysvmsg support => enabled
root@test:~# php8.0 -i | grep -i shmop
/etc/php/8.0/cli/conf.d/20-shmop.ini,
shmop
shmop support => enabled

I also considered that maybe another application was consuming allof the shared memory and causing php8.0-fpm to fail… not the case:

# ipcs -m --human

------ Shared Memory Segments --------
key        shmid      owner      perms      size       nattch     status      
0x64000630 4          root       600          1.1M     4                     

So at this point, I am stumped. 🤔🤔🤔

Question:
How do I get php8.0-fpm-running again?