Gitlab从7.11升级到8.0后无法启动postgresql、redis和sidekiq答案

【问题标题】：Gitlab can't start postgresql, redis and sidekiq after upgrade from 7.11 to 8.0Gitlab从7.11升级到8.0后无法启动postgresql、redis和sidekiq
【发布时间】：2015-12-21 02:04:09
【问题描述】：

我从 Gitlab 7.11 更新到 8.0。由于根分区空间不足，我通过

卸载了Gitlab 7

sudo gitlab-ctl uninstall

并通过安装 8

sudo apt-get install gitlab-ce

我遇到了一些其他问题，我在网上找到了解决方案，最终设法让 8 启动并运行。我已经确认数据仍然存在。问题是我无法通过gitlab-ctl启动postgresql、redis和sidekiq服务：

administrator@development:/var/opt/gitlab$ sudo gitlab-ctl restart
ok: run: gitlab-git-http-server: (pid 15873) 1s
ok: run: logrotate: (pid 15879) 0s
ok: run: nginx: (pid 15972) 0s
timeout: run: postgresql: (pid 2191) 7089s
timeout: run: redis: (pid 21277) 52584s, got TERM
timeout: run: sidekiq: (pid 5200) 1882s, got TERM
ok: run: unicorn: (pid 16308) 0s

不过，我可以通过以下方式启动 postgresql：

sudo su - gitlab-psql -c \
  '/opt/gitlab/embedded/bin/postgres -D /var/opt/gitlab/postgresql/data/'

和redis通过：

sudo su -s '/bin/sh' -c \
  '/opt/gitlab/embedded/bin/redis-server /var/opt/gitlab/redis/redis.conf' gitlab-redis

服务器运行的是 Ubuntu 14.04。如何让 Gitlab 启动/停止 postgresql、redis 和 sidekiq？

【问题讨论】：

标签： postgresql redis gitlab sidekiq

【解决方案1】：

经过几个小时的尝试和新问题的出现，我最终降级到 7.11，然后逐步升级到 7.12、7.13、7.14，最终升级到 8.0。升级后没有问题。

【讨论】：

【解决方案2】：

您的问题很可能是由于 runsvdir 服务未能使用：

ps auxw

在我的情况下，错误或警告将非常明显：

runsvdir -P /opt/gitlab/service log: ar/log/gitlab/sidekiq: 文件不存在 svlogd: 暂停: 无法重命名 c

确保您的机器有足够的空间使用：

df /

删除可能占用空间的文件。例如日志、备份等……在我的情况下，我有 25GB 的备份和只有 30GB 的驱动器。我的 / 已 100% 处于使用状态，并且不允许我的日志轮换。

使用以下命令停止 gitlab：

gitlab-ctl stop

手动杀死任何遗留的进程。使用 ps auxw 识别剩余进程并杀死 -9 个。

使用以下命令重启 gitlab：

gitlab-ctl start

【讨论】：

这应该是公认的答案！它确实有效，我做了pgrep -f postgres | xargs kill -9 并在我做了gitlab-ctl stop 之后对sidekiq 和redis 重复了这一点，然后做了gitlab-ctl start 一切都进展顺利（gitlab 11.9 - 11.10）

【解决方案3】：

我遇到了一个非常相似的问题，我看到了类似

的错误

文件“当前”无法重命名

最终通过杀死所有runsv和svlogd进程解决，然后gitlab-ctl restart

对我来说根本原因是以下变化：

gitlab-ctl stop && mv /var/log/gitlab{,_BAK} && mount /dev/gitlab-vg/logs-lv /var/log/gitlab && gitlab-ctl start

...有效地将路径“/var/log/gitlab/”替换为已安装的卷

因此，从 Gitlab 下更改指针，更具体地说是 runit，确实导致该进程管理器无法重新启动诸如 sidekiq、workhorse、nginx 等服务。使用gitlab-ctl restart 重新启动并没有解决它，因为显然是 runv,svlogd也不会重新启动（但是，重新启动整个系统，会解决这个问题）。

我还应该说，这个问题直到更改为 /var/log/gitlab/ 的第二天才显现出来。据我了解，直到那时 svlogd 才尝试移动/重命名日志文件（例如：/var/log/gitlab/gitlab-workhorse/current）。我应该注意到这一点，因为安装路径中的“新”日志文件在替换后没有立即写入。

简单地实现 logrotate（任何影响 svlogd/runit 之外的文件指针的东西）可能会遇到同样的问题——即使你重新启动 gitlab-omnibus。

【讨论】：

【解决方案4】：

在那种情况下可以帮助你

systemctl stop gitlab-runsvdir && systemctl start gitlab-runsvdir

【讨论】：