Problem with PHP-FPM after upgrade from Wheezy to Jessie

  • Hello,


    i updated an server from wheezy to jessie.


    Now i want to run the installer for i-msco from version 1.3.16 to 1.4.7


    I tried with all PHP Version from 5.6 , 7.0 till 7.1


    Installer stops here


    Creating config file /etc/php/7.1/mods-available/xsl.ini with new version
    Setting up php7.1-zip (7.1.8-1+0~20170803184529.6+jessie~1.gbp1357c1) ...


    Creating config file /etc/php/7.1/mods-available/zip.ini with new version
    Processing triggers for systemd (215-17+deb8u7) ...
    Processing triggers for libapache2-mod-php7.1 (7.1.8-1+0~20170803184529.6+jessie~1.gbp1357c1) ...
    Errors were encountered while processing:
    php7.1-fpm
    E: Sub-process /usr/bin/dpkg returned an error code (1)


    [ERROR] autoinstaller::Functions::build: An error occurred while performing build steps
    root@granaton:/usr/local/src/imscp-1.4.7#


    I tried to remove apache and php already.


    Anymore ideas ?


    THX and best wishes


    Niels

  • BBCODE please !

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206



      • Your Distribution and its codename: Jessie 8.9
      • The i-MSCP version in use 1.4.7
      • The i-MSCP server implementation in use for the concerned service (for instance: ITK, Fcgid, PHP-FPM, Proftpd, Vsftpd ...) PHP-FPM
      • The PHP version in use if your problem belongs to PHP: 7.1
      • The service logs (generally located under /var/log) if any
      • The exact steps to reproduce the problem
      Shell-Script
      1. root@:~# /etc/init.d/php7.1-fpm restart[....] Restarting php7.1-fpm (via systemctl): php7.1-fpm.serviceJob for php7.1-fpm.service failed. See 'systemctl status php7.1-fpm.service' and 'journalctl -xn' for details. failed!
    • Shell-Script
      1. root@g:~# systemctl status -l php7.1-fpm.service
      2. ● php7.1-fpm.service - The PHP 7.1 FastCGI Process Manager Loaded: loaded (/lib/systemd/system/php7.1-fpm.service; enabled) Active: failed (Result: exit-code) since Do 2017-08-03 23:04:05 CEST; 33s ago Docs: man:php-fpm7.1(8) Process: 24696 ExecStart=/usr/sbin/php-fpm7.1 --nodaemonize --fpm-config /etc/php/7.1/fpm/php-fpm.conf (code=exited, status=254) Main PID: 24696 (code=exited, status=254)
      3. Aug 03 23:04:05 lvp.dedicated.hosteurope.de php-fpm7.1[24696]: Thu Aug 3 23:04:05 2017 (24696): Fatal Error Unable to allocate shared memory segment of 134217728 bytes: shmget: Cannot allocate memory (12)root@:~#
  • Fatal Error Unable to allocate shared memory segment of 134217728 bytes: shmget: Cannot allocate memory (12)

    Not enough shared memory is available on your server. There is surely something that eat all your memory.

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

  • great point. It seems vlogger cannot connect.


    [Fri Aug4 06:01:16 2017] [notice] vlogger: DBI usage tracker feature turned off
    [Fri Aug4 06:01:16 2017] [notice] vlogger: started CustomLog Handler -- resuming normal operations
    [Fri Aug4 06:01:16 2017] [alert] vlogger: couldn't connect to SQL server: DBI connect('database=imscp;host=127.0.0.1;port=3306','vlogger_user',...) failed: Can't connect to MySQL server on '127.0.0.1' (111) at /usr/local/sbin/vlogger line 279.


    [Fri Aug4 06:01:16 2017] [notice] vlogger: DBI usage tracker feature turned off
    [Fri Aug4 06:01:16 2017] [notice] vlogger: started CustomLog Handler -- resuming normal operations
    Fri Aug4 06:01:16 2017 (1183): Fatal Error Unable to allocate shared memory segment of 134217728 bytes: mmap: Cannot allocate memory (12)


    MYSQL is running on 127.0.0.1

  • @sfsolutions



    could be this?

    I don't think so... Do you have checked your processes table for zombies processes?


    If you cannot figure out alone, best is to give us access to the server.

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

  • @sfsolutions


    Problem mitigated. It was due to your system limitations for shared memory. You should really contact your provider because I had to lower the max memory for OPCache (from 256 to 32 MiB). Note that this problem occurred also with Nginx... This is really due to limitations on your system...


    You should contact your provider and ask him to raise the values.


    See also:

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206