Laravel Flysystem 和 Rackspace CRON 上传失败并显示 401，而按需上传正常

Question

我们的系统每小时生成各种发票并将其上传到云端。也可以通过单击我们前端的按钮按需创建发票。

当手动请求创建上述发票时，它永远不会上传失败。至于 cron 在一段时间后生成的发票，所有上传都失败了:

Client error response
[status code] 401
[reason phrase] Unauthorized
[url] https://storage101.dfw1.clouddrive.com/v1/MossoCloudFS_930575/ <...> .pdf" @ Guzzle\Http\Exception\BadResponseException->factory 

这应该意味着 token 已经过期，它可能是。 Rackspace token 持续 24 小时，但 Laravel 的存储应自动刷新 token 。

---

现在这里有一些有趣的事实:

1) 每次使用 Capistrano 部署我们的代码时， token 似乎都会刷新，并且 cron 上传会再次工作一段时间。这里需要注意的重要一点是，每次部署都会创建一个类似于此 /releases/201605190925 的新文件夹，提取代码，从头开始安装依赖项，如果一切顺利，则将此文件夹与 Apache 显示的文件夹进行符号链接(symbolic link).

2) Laravel 作业在与 www-data 不同的进程中处理

3) 很难追踪部署后上传工作是否超过 24 小时。我怀疑有时它的作用不止于此。但很难追踪，因为并非每个小时都有需要生成的发票。部署的开发人员比我等更多。

4) 当 cron 失败并且我收到失败通知时，我可以立即去成功生成发票。在那之后，cron 仍然失败。所以这两个实例似乎在某处存储了不同的 token 。

5) 使用 php artisan cache:clear 清理缓存似乎没有任何影响

6) 可能已经尝试重启 Apache 服务但没有结果

因为它已经持续了一段时间，所以我已经测试了各种东西，甚至一度联系过 Rackspace，但他们从他们那里找不到任何奇怪的东西......提醒我只是为了捕获 401 错误，更新 token ，然后重试。但是 Laravel 和 Flysystem 应该自己在某个地方处理它

由于 Flysystem、Laravel 或 Rackspace 似乎没有其他人遇到类似问题，我怀疑这是 cron 进程的某种独特问题。我只是希望很快我们就可以准备好系统的重构版本，问题就会消失。至于现在它仍在开发中，可能还需要一个月。

---

不要认为它与代码有关，但无论如何这是上传行:

Storage::put($folder . '/' . $filename, file_get_contents($filePath));

这是我们的配置:

'default' => 'rackspace',

'disks' => [
    'rackspace' => [
        'driver'    => 'rackspace',
        'username'  => ' ... ',
        'key'       => ' ... ',
        'container' => ' ... ',
        'endpoint'  => 'https://identity.api.rackspacecloud.com/v2.0/',
        'region'    => 'DFW',
    ]
]

---

如有任何想法，我们将不胜感激。

Answer 1

在将近 2.5 个月后，我再次尝试找到问题的解决方案。当我重读@Tommmm 更新时，我认为这次真的很成功。

所以你重新启动了工作队列，我开始思考我运行主管/工作人员的方式。

php artisan queue:work database --daemon --sleep=10 tries=3

---

--Daemon(因为它在 StackOverflow post by @the-shift-exchange 中得到了很好的解释)

在 Laravel >=4.2 中添加了一个 --daemon 命令。它的工作方式就是直接继续运行队列，而不是在处理完每个队列后重新启动整个框架。这是一个可选命令，可显着降低队列的内存和 CPU 要求。

--daemon 命令的重要一点是，当您升级您的应用程序时，您需要使用 queue:restart 专门重启您的队列，否则您可能会遇到各种奇怪的错误，例如您的队列在内存中仍会保留旧代码。

---

由于应用程序永远不会再次启动，我觉得 token 也永远不会更新。至于应用程序的其余部分仍然更新 token 并使用新 token 。这就解释了为什么所有的点击操作都有效，只有后台任务失败了。至于部署临时解决我们问题的原因是每次部署后我们都有 queue:restart。

我很确定情况确实如此，现在有两种可能性可以开始。要么你在一段时间后重启你的工作人员(对于 Rackspace 为 <24 小时)，要么你不与 --daemon 一起运行工作人员。

---

编辑:

已确认将以下内容添加到 Kernel.php 会在每 6 小时后重新启动守护进程。

$schedule->command('queue:restart')->cron('0 */6 * * *')