我有两个同时排队的工作，一个工作人员连续运行它们。builds/这两个作业都从我的 Rails 项目的根目录中复制一些文件，并将它们放入一个临时文件夹中。
第一份工作总是成功的，从来没有问题——哪个工作先运行也没有关系。第一个将起作用。
第二个在尝试复制文件时收到此错误：
没有这样的文件或目录 - /Users/apps/Sites/my-site/releases/20130829065128/builds/foo
该版本文件夹已有两周的历史，不应仍在服务器上。它是空的，只有一个 public/uploads 目录，没有别的。我已经杀死了所有的工人并多次重新启动它们，并多次重新部署了 Rails 应用程序。当我删除该发布目录时，它会再次出现。
我现在不知道该怎么办。为什么这个工人总是在这个旧的发布目录中创建/查看？为什么只有第二个工人会这样做？我正在使用以下方法获取路径：
Rails.root.join('builds')- Rails.root 显然是 2 周前的 capistrano 版本？我还应该提到这只发生在生产环境中。我能做些什么 ？
在导致旧版本代码运行的部署上，救援没有重新启动（停止和启动）。每个工作人员继续为队列服务，从而导致奇怪的错误或行为。
根据路径名称，您似乎正在使用 Capistrano 进行部署。
您在使用capistrano-resque宝石吗？如果没有，你应该看看。
我遇到了完全相同的问题，这就是我解决它的方法：
就我而言，问题是 capistrano 如何处理 PID 文件，这些文件指定当前存在哪些工作人员。这些文件通常存储在tmp/pids/. 您需要告诉 capistrano 不要将它们存储在每个发布文件夹中，而是存储在shared/tmp/pids/. 否则，在您进行新部署后，resque 不知道当前正在运行哪些工作程序。它查看新版本的 pids 文件夹并没有找到任何文件。因此，它假定不存在需要关闭的工人。Resque 只是创造了新的工人。并且所有其他工作人员仍然存在，但您无法在 Resque-Dashboard 中看到它们。如果您检查服务器上的进程，您只能看到它们。
这是您需要做的：
在您的 deploy.rb 中添加以下行（顺便说一句，我使用的是 Capistrano 3.5）
append :linked_dirs, ".bundle", "tmp/pids"
set :resque_pid_path, -> { File.join(shared_path, 'tmp', 'pids') }
在服务器上，htop在终端中运行以启动 htop，然后按 T，查看当前正在运行的所有进程。很容易发现所有这些 resque-worker-processes。您还可以看到附加到它们的发布文件夹的名称。
您需要手动杀死所有工作进程。退出 htop 并键入以下命令以终止所有 resque 进程（我希望它完全干净）：
sudo kill -9 `ps aux | grep [r]esque | grep -v grep | cut -c 10-16`
现在您可以进行新的部署了。您还需要再次启动 resque-scheduler。
我希望这会有所帮助。