我有两个同时排队的工作，一个工人连续运行它们。这两个作业都复制了我的Rails项目根目录中builds/目录中的一些文件，并将它们放入一个临时文件夹中。
第一份工作总是成功，从来没有问题 - 哪个工作先运行也没关系。第一个将起作用。
第二个在尝试复制文件时收到此错误：
没有这样的文件或目录 - / Users / apps / Sites / my-site / releases / 20130829065128 / builds / foo
该版本文件夹已有两周时间了，不应该仍在服务器上。它是空的，只包含一个公共/上传目录，没有别的。我已经杀死了我的所有工作人员并多次重新启动它们，并多次重新部署Rails应用程序。当我删除那个版本目录时，它再次成功。
此时我不知道该怎么做。为什么这个工作者总是在这个旧版本目录中创建/查看？为什么只有第二个工人这样做？我通过使用：
来获取路径 Rails.root.join('builds') - Rails.root显然是一个2周的capistrano发行版？我还应该提到这只发生在生产环境中。我能做什么
？
答案 0 :(得分：0)
部署中没有重新启动（停止和启动）Rescue，导致运行旧版本的代码。每个工作人员继续为队列提供服务，导致奇怪的错误或行为。
根据路径名称，您似乎正在使用Capistrano进行部署。
您使用的是capistrano-resque宝石吗？如果没有，你应该看看。
答案 1 :(得分：0)
我有完全相同的问题，这就是我如何解决它：
在我的情况下，问题是capistrano如何处理PID文件，该文件指定当前存在哪些工作人员。这些文件通常存储在tmp/pids/中。您需要告诉capistrano不要将它们存储在每个版本文件夹中，而是存储在shared/tmp/pids/中。否则，在进行新部署后，resque不知道当前正在运行哪些工作线程。它会查看新版本的pids-folder并找不到文件。因此，它假定不存在需要关闭的工人。 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-processes（我喜欢让它完全清理）：
sudo kill -9 `ps aux | grep [r]esque | grep -v grep | cut -c 10-16`
现在您可以进行新部署。您还需要再次启动resque-scheduler。
我希望有所帮助。