Gitlab从7.11升级到8.0后无法启动postgresql、redis和sidekiq
Gitlab can't start postgresql, redis and sidekiq after upgrade from 7.11 to 8.0
我从 Gitlab 7.11 更新到 8.0。由于根分区上缺少space,我通过
卸载了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
服务器是运行Ubuntu14.04。如何让 Gitlab 支持 start/stop postgresql、redis 和 sidekiq?
经过几个小时的尝试和新问题的出现,我最终降级到 7.11,然后逐步升级到 7.12、7.13、7.14,最后升级到 8.0。升级后没有问题。
您的问题很可能是由于 runsvdir 服务失败而导致的:
ps auxw
在我的例子中,错误或警告会非常明显:
runsvdir -P /opt/gitlab/service 日志:ar/log/gitlab/sidekiq:文件不存在 svlogd:暂停:无法重命名 c
确保您的机器有足够的 space 使用:
df /
删除可能占用 space 的文件。例如日志、backups 等...在我的例子中,我有 25GB 的 backups 和只有 30GB 的驱动器。我的 / 已 100% 使用且不允许我的日志轮换。
停止 gitlab 使用:
gitlab-ctl stop
手动终止所有遗留进程。使用 ps auxw 识别剩余进程并 kill -9 它们。
重启 gitlab 使用:
gitlab-ctl start
我有一个非常相似的问题,我看到了像
这样的错误
file "current" could not be renamed
最终通过杀死所有 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
重新启动并没有解决它,因为runsv、svlogd 显然也没有重新启动(重新启动整个系统,但是, 会修复此问题)。
我还应该说,这个问题直到更改为 /var/log/gitlab/
后的第二天才出现。据我了解,直到那时 svlogd 才尝试 move/rename 日志文件(例如:/var/log/gitlab/gitlab-workhorse/current)。我应该注意到这一点,因为安装路径中的 "new" 日志文件在替换后没有立即写入。
简单地实现 logrotate(任何影响 svlogd/runit 之外的文件指针的东西)可能会遇到同样的问题——即使你重新启动 gitlab-omnibus。
在那种情况下可以帮助你
systemctl stop gitlab-runsvdir && systemctl start gitlab-runsvdir
我从 Gitlab 7.11 更新到 8.0。由于根分区上缺少space,我通过
卸载了Gitlab 7sudo gitlab-ctl uninstall
并通过
安装了 8 个sudo apt-get install gitlab-ce
我遇到了一些其他问题,我在网上找到了解决方案,并最终设法解决了 8 和 运行。我已经确认数据仍然存在。问题是我无法通过 gitlab-ctl
:
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
服务器是运行Ubuntu14.04。如何让 Gitlab 支持 start/stop postgresql、redis 和 sidekiq?
经过几个小时的尝试和新问题的出现,我最终降级到 7.11,然后逐步升级到 7.12、7.13、7.14,最后升级到 8.0。升级后没有问题。
您的问题很可能是由于 runsvdir 服务失败而导致的:
ps auxw
在我的例子中,错误或警告会非常明显:
runsvdir -P /opt/gitlab/service 日志:ar/log/gitlab/sidekiq:文件不存在 svlogd:暂停:无法重命名 c
确保您的机器有足够的 space 使用:
df /
删除可能占用 space 的文件。例如日志、backups 等...在我的例子中,我有 25GB 的 backups 和只有 30GB 的驱动器。我的 / 已 100% 使用且不允许我的日志轮换。
停止 gitlab 使用:
gitlab-ctl stop
手动终止所有遗留进程。使用 ps auxw 识别剩余进程并 kill -9 它们。
重启 gitlab 使用:
gitlab-ctl start
我有一个非常相似的问题,我看到了像
这样的错误file "current" could not be renamed
最终通过杀死所有 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
重新启动并没有解决它,因为runsv、svlogd 显然也没有重新启动(重新启动整个系统,但是, 会修复此问题)。
我还应该说,这个问题直到更改为 /var/log/gitlab/
后的第二天才出现。据我了解,直到那时 svlogd 才尝试 move/rename 日志文件(例如:/var/log/gitlab/gitlab-workhorse/current)。我应该注意到这一点,因为安装路径中的 "new" 日志文件在替换后没有立即写入。
简单地实现 logrotate(任何影响 svlogd/runit 之外的文件指针的东西)可能会遇到同样的问题——即使你重新启动 gitlab-omnibus。
在那种情况下可以帮助你
systemctl stop gitlab-runsvdir && systemctl start gitlab-runsvdir