作曲家从SSH自动"杀死"

Question

我在本地构建了一个完整的应用程序,现在尝试在我一直做的远程服务器上安装(git pull,解决冲突,更新实体,清除缓存...)但是我的新应用程序需要几个包,所以在制作之后从github拉出并解决冲突,我正在尝试安装捆绑包,所有这些都会产生同样的问题.

我的服务器"杀死"了这个过程吗？

我整天搜索但找不到问题.我从php.ini的php配置是:

此错误从未发生过,我在2年前在此服务器上安装了许多软件包.有类似经历的人？

谢谢.

编辑:

我做了一个"php composer.phar诊断",我得到以下内容:

问题可能出在"composer.json"中？

Answer 1

可能是与PHP CLI内存限制配置相关的问题.您可以使用以下命令诊断CLI PHP的内存分配:

php -i | grep memory

并php.ini使用以下命令查看CLI版本:

php -i | grep 'php.ini'

顺便说一下,我建议使用作曲家依赖的正确开发工作流程如下:

但只是你知道,你通常应该update在你的机器上运行,然后提交/部署composer.lock文件,并且只install在你的服务器上运行 以将依赖项与锁定文件同步,以确保你只得到你正确测试的东西.这样你也可以运行内存不足的服务器而不会出现任何问题.

希望这有帮助

Answer 2

谢谢@Matteo，

问题是否有可能是服务器上剩余的可用 RAM 量？

我已经验证了内存量限制，但不认为这是问题所在。

php-cli -i | grep memory

不过，我已经解决了我的问题。事实上，可以通过三种方法来解决：

1. 安装没有 Composer 的捆绑包

这不是推荐的解决方案，但通常知道如何执行它非常有用，特别是在非常过时的项目中并且您担心命令可能生成的问题composer update

本指南假设您的本地服务器上没有内存限制问题，因此所有命令都可以与composer一起正常工作。

首先，您必须在本地计算机上安装捆绑包，例如：

composer require jms/serializer-bundle

安装该包后，您只需将该包添加到您的 AppKernel.php 文件中：

// in AppKernel::registerBundles()
  $bundles = array(
  // ...
  new JMS\SerializerBundle\JMSSerializerBundle(),
  // ...
);

其次，从包目录中打开composer.json，例如

// \vendor\jms\serializer-bundle\JMS\SerializerBundle\composer.json
"require": {
    "php": ">=5.4.0",
    "jms/serializer": "^1.0.0",
    "phpoption/phpoption": "^1.1.0",
    "symfony/framework-bundle": "~2.3|~3.0"
},

对于“require 部分”中的每个bundle，打开相应的composer.json 以识别所有必需的bundle。

目的是复制所有这些包的目录并将它们上传到远程服务器的“vendor”目录中（注意维护相同的大目录层次结构）

例如：

如果您从 jms/serializer 包中打开composer.json，您可以看到：

// vendor/jms/serializer/composer.json
"require": {
    "php": ">=5.4.0",
    "jms/metadata": "~1.1",
    "jms/parser-lib": "1.*",
    "phpcollection/phpcollection": "~0.1",
    "doctrine/annotations": "1.*",
    "doctrine/instantiator": "~1.0.3"
},

现在，您应该从 jms/metadata、jms/parser-lib 和 phpcollection/phpcollection 打开composer.json，以识别您必须上传到远程服务器的其他包。

目标是不丢失任何依赖项。

最后，从远程服务器打开/vendor/composer/autoload_namespaces.php并添加捆绑包依赖项的所有名称空间。您应该将此文件与本地的“autoload_namespaces.php”进行比较。

2.添加交换空间

您有三个选择：创建新的交换分区、创建新的交换文件或在现有 LVM2 逻辑卷上扩展交换。建议您扩展现有逻辑卷。

3.将本地的composer更新为仅安装在远程

这是进行良好编程实践的推荐选项。当composer update第三个项目完成时，我们不知道会发生什么错误，但是当您有足够的时间进行开发并且该项目从现在开始就是您的时，您应该将该项目完全升级。首先在本地服务器上更新并composer update解决出现的所有冲突。最后，随着服务器上的composer.json和composer.lock更新，从现在到永远只需要运行acomposer install来安装和更新新包的所有依赖项。

Matteo的解释是正确的，该composer update命令占用的内存比composer install.

但正如您所知，您通常应该在计算机上运行更新，然后提交/部署composer.lock文件，并且仅在服务器上运行安装以将依赖项与锁定文件同步，以确保您只获得测试过的内容适当地。这样您也可以运行内存不足的服务器而不会出现任何问题。