3.8. 故障排除

故障排除

这是使用 Composer 时常见陷阱的列表,以及如何避免它们。

一般

  1. 在询问任何人之前, 请先运行 composer diagnose 检查是否存在常见问题。如果全部检出,请继续执行后续步骤。

  2. 使用 Composer 遇到任何问题时,请务必使用最新版本。有关详细信息请参阅 self-update 

  3. 通过运行安装程序的检查,确保您的设置没有问题 curl -sS https://getcomposer.org/installer | php -- --check.

  4. 确保您直接从您的安装厂商 composer.json 通过 rm -rf vendor && composer update -v 障排除时,不包括与现有供应商的装置或任何可能的干扰 composer.lock 项。

  5. 尝试通过运行清除 Composer 的缓存 composer clear-cache

包没有找到

  1. 仔细检查确保在你的 composer.json 中没有拼写或者库分支和标签的名字错误。

  2. 一定要设置正确 最小稳定性。开始或一定没有问题, 设置 最小稳定性 为 "开发"。

  3. 包不是来自 Packagist包镜像站 而是应该通常在根包中被定义(包取决于所有供应商)。

  4. 使用相同的供应商和包名称在您的存储库的所有分支和标签,尤其是当维护第三方分支和使用 替换 时。

  5. 如果你更新到最近推出的版本的包,请注意,Packagist 包镜像站有 1 分钟左右延迟在新包于 Composer 中是可见的之前。

  6. 如果你更新一个包,它可能取决于更新的版本。在这种情况下,添加 --with-dependencies 参数或添加命令需要一个更新的所有依赖项。

在 travis-ci.org 中找不到依赖包

  1. 检查上面 "找不到依赖包" 的选项。

  2. 如果测试的软件包是其依赖项之一(循环依赖项)的依赖项,则问题可能是 Composer 无法正确检测到软件包的版本号导致的。如果它是通过 Git 克隆下来的,那么它通常是正常的,Composer 将检测当前分支的版本号,但是 travis 执行的是浅克隆,因此在测试拉取请求和特征分支时,进程可能会失败。最好的解决方式是通过在环境变量中使用常量比如 COMPOSER_ROOT_VERSION 来定义你所使用的版本号,例如,将其根软件包的版本定义为 dev-master,使用: before_script: COMPOSER_ROOT_VERSION=dev-master composer install 导出调用 Composer 的变量。

Jenkins 构建时包找不到

  1. 查看官方 『包找不到』 异常项。
  2. 类似于包找不到这样的失败原因常出现在 持续集成 过程中: Jenkins 在 git-clone / checkout 时将分支设置在『脱离头部』的状态。这样的结果是: Composer 无法识别当前拉取的分支的版本,并且可能无法解析包的循环依赖关系。为了解决这个问题,你可以为Jenkins脚本的Git设置添加附加行为(拉取指定的分支),你指定的分支应该和你将要拉取的分支相同。这样的话,checkout 时不会在脱离头部的状态并且也可以正确的识别包之间的依赖关系。

我在 composer.json 里面定义了一个含有包的依赖关系,但它好像没有生效。

 的相关参数配置在 根目录composer.json 中。他们是不能被继承的。你可以通过阅读 『why can't composer load repositories recur...』 这篇文章了解原因。 解决这个问题的最简单的方法就是在项目根目录下的 composer.json 中删除或者重新定义想引用的

我已经锁定一个依赖特定的 commit 但得到意想不到的结果。

虽然 Composer 支持依赖锁定到一个特定的 commit 使用 #commit-ref 语法,有一些警告,每个人都应该考虑到。最重要的是 记录, 但是经常被忽视:

注意:虽然这是方便的,它不应该如何使用包从长远来看,因为它有技术限制。 composer.json 元数据仍将从您指定的分支机构名称前的散列读取。因为在某些情况下,它将不是一个实际的解决方法,只要可以你应该总是试图切换到标记的版本就。

没有这个限制的简单方法。因此,强烈建议您不要使用它。

需要重写包版本

假设你的项目依赖于软件包 A ,这又取决于包的特定版本 B (说明 0.1)。但是你需要一个不同版本的上述的包 B (说明 0.11).

您可以通过将版本0.11到0.1来解决此问题。

composer.json:

{
    "require": {
        "A": "0.2",
        "B": "0.11 as 0.1"
    }
}

更多信息请参阅 别名

内存限制错误

在某些命令中, Composer 可能会出现下面的错误:

PHP Fatal error: Allowed memory size of XXXXXX bytes exhausted <...>

在这种情况下, PHP 应该增加 memory_limit 的值。

注意: Composer 的内部增加 memory_limit 到了 1.5G

要获取当前 memory_limit 值,请运行:

php -r "echo ini_get('memory_limit').PHP_EOL;"

试增加 php.ini 文件中的限制 (例如 /etc/php5/cli/php.ini ,类似Debian 系统):

; Use -1 for unlimited or define an explicit value like 2G
memory_limit = -1

Composer 还遵循 COMPOSER_MEMORY_LIMIT 环境变量定义的内存限制 :

COMPOSER_MEMORY_LIMIT=-1 composer.phar <...>

或者,你可以使用命令行参数来增加限制:

php -d memory_limit=-1 composer.phar <...>

当激活 shell fork 炸弹保护时,cPanel 实例上也会发生此问题。有关更多信息,请参阅 cPanel 站点上的 fork bomb功能文档 。

Xdebug 对 Composer 的影响

Xdebug 会对 Composer 的运行造成影响,为了提高性能,Composer 运行时会关闭 Xdebug 并重启 PHP 。您可以使用环境变量来阻止此行为: COMPOSER_ALLOW_XDEBUG=1

如果你的系统开启了 Xdebug ,Composer 会始终显示一个警告信息,您可以使用环境变量来重写它:COMPOSER_DISABLE_XDEBUG_WARN=1 。设置重写后,如果您还是意外地看到此警告,那么说明重启过程已经失败:请报告这个 问题

"系统无法找到指定的路径" (Windows)

  1. 打开注册表;
  2. HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor
    HKEY_CURRENT_USER\Software\Microsoft\Command Processor 
    或 HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Command Processor 中搜索  AutoRun 键;
  3. 检查它是否包含任何不存在文件的路径,如果是这种情况,删除它们。

API 访问频率限制和 OAuth 令牌

由于 GitHub 对其 API 的访问频率做了限制, Composer 可能会提示进行身份验证,询问您的用户名和密码,以便其可以继续工作。

如果您不愿意向 Composer 提供您的 GitHub 凭据,您可以使用以下过程手动创建一个令牌:

  1. 创建 GitHub 上的 OAuth 令牌。在这里 了解更多 。

  2. 将其添加到运行的配置 composer config -g github-oauth.github.com <oauthtoken>

现在 Composer 应该在不需要身份验证的情况下就可以安装/更新。

proc_open(): 分支失败错误

如果 composer 显示 proc_open() 则在某些命令上失败:

PHP Fatal error: Uncaught exception 'ErrorException' with message 'proc_open(): fork failed - Cannot allocate memory' in phar

这可能会发生,因为 VPS 内存不足,并且没有启用交换空间。

free -m

total used free shared buffers cached
Mem: 2048 357 1690 0 0 237
-/+ buffers/cache: 119 1928
Swap: 0 0 0

若要启用交换,您可以使用例如:

/bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=1024
/sbin/mkswap /var/swap.1
/sbin/swapon /var/swap.1

可以在本 教程 之后制作一个永久交换文件。

降级模式

由于 Travis 和其他系统上的一些间歇性问题,我们引入了降级网络模式,帮助 Composer 成功完成,但禁用一些优化。当首次检测到问题时,会自动启用此功能。如果您偶尔看到这个问题,您可以不必担心(网络缓慢或过载也会导致超时),但是如果反复出现问题,您可能需要查看下面的选项找到原因并解决它。

如果您已经指向此页面,则需要检查以下几项:

  • 如果您使用的是 ESET 防病毒软件,请进入 "Advanced Settings" 并禁用 "web access protection" 下的 "HTTP-scanner"

  • 如果您使用的是 IPv6,请尝试禁用它。如果这样解决了您的问题,与您的 ISP 或服务器主机的联系,那么问题不在于 Packagist 级别,而在于您与 Packagist (即整个互联网)之间的路由规则。解决这些问题的最佳方法是,提高对有能力修复它的网络工程师的认识。请查看 IPv6 下一部分的解决方法。

  • 如果上述方法均无效,请报告错误。

操作超时(IPv6 问题)

您如果未正确配置 IPv6 ,则可能会遇到错误。一个常见的错误是:

The "https://getcomposer.org/version" file could not be downloaded: failed to
open stream: Operation timed out

我们建议您修复 IPv6 设置,如果无法做到这一点,您可以尝试以下解决方法:

Linux 解决方法:

在 linux 上,运行此命令似乎有助于 ipv4 流量具有比 ipv6 更高的 prio , 这是比完全禁用 ipv6 更好的选择:

sudo sh -c "echo 'precedence ::ffff:0:0/96 100' >> /etc/gai.conf"

Windows 解决方法:

在 windows 上唯一的办法就是完全禁用 ipv6 (无论是在 Windows 中还是在家用路由器中)。

Mac OS X 解决方法:

获取您的网络设备的名称:

networksetup -listallnetworkservices

在该设备上禁用 IPv6 (在本例中为"Wi-Fi"):

networksetup -setv6off Wi-Fi

运行 composer ...

您可以再次启用 IPv6 :

networksetup -setv6automatic Wi-Fi

也就是说,如果这可以解决您的问题,请与您的 ISP 联系,以尝试解决路由错误。这是能让每个人都能解决问题的最好方法。

Composer 与 SSH ControlMaster 挂起

当您尝试从 Git 存储库安装软件包并使用 ControlMaster 设置进行 SSH 连接时, Composer 可能会无休止的挂起,并且您会在进程列表中看到处于 defunct 状态的 sh 进程。

原因是 SSH Bug:bugzilla.mindrot.org/show_bug.cgi?...

解决方法是,在运行 Composer 之前打开与 Git 主机的 SSH 连接:

ssh -t git@mygitserver.tld
composer update

有关更多信息,请参阅 github.com/composer/composer/issue... 。

Zip 存档未正确解压

Composer 可以使用系统提供的 unzip 或者 PHP's 本身的 ZipArchive 类来解压缩。 ZipArchive 类在 Windows 上是首选。 在其他 OSes 系统中 ZIP 文件可以包含权限和符号链接,所以首选 unzip ,如果您需要这些功能,建议您安装它。

本文章首发在 LearnKu.com 网站上。

本译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
上一篇 下一篇
Summer
贡献者:7
讨论数量: 0
发起讨论 只看当前版本


暂无话题~