一、概述

上一篇我们将Gitlab的安装部署和初始化设置部分全部讲解完成了,接下来我们介绍Gitlab在日常工作中常遇见的问题进行梳理说明。

二、Gitlab的安装和维护过程中常见问题

1、Gitlab访问出现403"Forbidden"现象

问题原因分析:

可能因较多的并发导致的访问被拒绝, Gitlab使用rack_attack做了并发访问的限制!

解决办法:

打开/etc/gitlab/gitlab.rb文件,查找 gitlab_rails['rack_attack_git_basic_auth'] 关键词,取消注释,

修改ip_whitelist白名单属性,加入Gitlab部署的IP地址。

[root@gitlab ~]# vim /etc/gitlab/gitlab.rb
......
gitlab_rails['rack_attack_git_basic_auth'] = {
'enabled' => true,
'ip_whitelist' => ["127.0.0.1","172.16.60.222"], //把gitlab服务器IP地址添加
'maxretry' => 10,
'findtime' => 60,
'bantime' => 3600
}  

然后进行重新配置

[root@gitlab ~]# gitlab-ctl reconfigure

2、Gitlab访问出现502的现象

Gitlab访问出现:Whoops, GitLab is taking too much time to respond.  

问题原因分析:

1)unicorn原8080默认端口被容器中别的进程已经占用,必须调整为没用过的
2)gitlab的timeout设置过小,默认为60

解决办法:

1)关闭gitlab服务

[root@gitlab ~]# gitlab-ctl stop

2)选择一个没有被系统占用的端口作为unicorn端口,比如8877端口(lsof -i:8877 确认此端口没有被占用) 

[root@gitlab ~]# vim /etc/gitlab/gitlab.rb
unicorn['port'] = 8877
gitlab_workhorse['auth_backend'] = "http://localhost:8877"

3)重新生成配置,并进行重启。  

[root@gitlab ~]# gitlab-ctl reconfigure
[root@gitlab ~]# gitlab-ctl restart

3、Gitlab启动失败,或重新安装时出现卡的状态  

问题现象:在卸载gitlab然后再次安装执行sudo gitlab-ctl reconfigure的时候往往会出现:ruby_block[supervise_redis_sleep] action run,会一直卡无法往下进行!

解决办法:

1)按ctrl + c 强制结束
2)执行"systemctl restart gitlab-runsvdir" 命令
3)接着再执行"gitlab-ctl reconfigure"

如果Gitlab服务器重启后,启动"gitlab-ctl start"失败,解决办法相同。

[root@gitlab ~]# systemctl restart gitlab-runsvdir
[root@gitlab ~]# gitlab-ctl reconfigure
[root@gitlab ~]# gitlab-ctl start

4、Gitlab异常关机,导致gitlab启动失败!gitlab-runsvdir方式启动没反应(僵尸状态)  

问题现象:Gitlab部署的服务器异常断电,机器重启后,尝试启动gitlab服务,启动失败!通过gitlab-runsvdir方式启动一直没有反应!一直在卡顿状态!日志也没有任务输入!

执行下面的启动命令报错:
[root@gitlab ~]# gitlab-ctl start // 或者 "gitlab-ctl restart"
fail: alertmanager: runsv not running
fail: gitaly: runsv not running
fail: gitlab-monitor: runsv not running
fail: gitlab-workhorse: runsv not running
fail: logrotate: runsv not running
fail: nginx: runsv not running
fail: node-exporter: runsv not running
fail: postgres-exporter: runsv not running
fail: postgresql: runsv not running
fail: prometheus: runsv not running

报错说"runsv not running"

那么尝试通过supervisor进程方式启动gitlab,发现一直在卡顿中,根本没有任何反应!
[root@gitlab ~]# systemctl restart gitlab-runsvdir

查看日志,发现也没有任务启动信息打印到日志中 (日志都是之前的)  

[root@gitlab ~]# /usr/bin/gitlab-ctl tail

gitlab-runsvdir启动在卡顿中,gitlab服务也没有起来  

[root@gitlab ~]# ps -ef|grep gitlab

解决方法:

通过Gitlab自己原生命令去启动服务:/opt/gitlab/embedded/bin/runsvdir-start
root@gitlab ~]# cat /etc/systemd/system/multi-user.target.wants/gitlab-runsvdir.service
[Unit]
Description=GitLab Runit supervision process
After=multi-user.target [Service]
ExecStart=/opt/gitlab/embedded/bin/runsvdir-start #最后通过这条命令启动了Gitlab
Restart=always [Install]
WantedBy=multi-user.target 执行下面的启动,虽然发现这个也会一直在卡顿中,但是不影响gitlab服务启动。
[root@gitlab ~]# /opt/gitlab/embedded/bin/runsvdir-start 重新打开一个终端窗口,发现gitlab已经有新的日志信息打入了,gitlab也服务已经起来了
[root@gitlab ~]# /usr/bin/gitlab-ctl tail
[root@gitlab ~]# ps -ef|grep gitlab 这时候关闭上面执行"/opt/gitlab/embedded/bin/runsvdir-start"的卡顿的终端窗口,发现gitlab也还是启动状态(ps -ef|grep gitlab)
[root@gitlab ~]# ps -ef|grep gitlab
[root@gitlab ~]# lsof -i:80
[root@gitlab ~]# gitlab-ctl status
run: alertmanager: (pid 29804) 1640s; run: log: (pid 29789) 1640s
run: gitaly: (pid 29795) 1640s; run: log: (pid 29781) 1640s
run: gitlab-monitor: (pid 29799) 1640s; run: log: (pid 29785) 1640s
run: gitlab-workhorse: (pid 29794) 1640s; run: log: (pid 29780) 1640s
run: logrotate: (pid 29798) 1640s; run: log: (pid 29783) 1640s
run: nginx: (pid 29800) 1640s; run: log: (pid 29786) 1640s
run: node-exporter: (pid 29802) 1640s; run: log: (pid 29788) 1640s
run: postgres-exporter: (pid 29805) 1640s; run: log: (pid 29790) 1640s
run: postgresql: (pid 29796) 1640s; run: log: (pid 29782) 1640s
run: prometheus: (pid 29797) 1640s; run: log: (pid 29784) 1640s
run: redis: (pid 29818) 1640s; run: log: (pid 29793) 1640s
run: redis-exporter: (pid 29817) 1640s; run: log: (pid 29792) 1640s
run: sidekiq: (pid 29801) 1640s; run: log: (pid 29787) 1640s
run: unicorn: (pid 29807) 1640s; run: log: (pid 29791) 1640s 查看日志也有新信息写入,一切正常了!
[root@gitlab ~]# /usr/bin/gitlab-ctl tail  

 5、Gitlab重新安装,在执行"gitlab-ctl reconfigure"配置环节出现了下面报错:

[root@gitlab ~]# gitlab-ctl reconfigure
.........
.........
STDERR: sysctl: cannot open "/etc/sysctl.d/90-omnibus-gitlab-kernel.sem.conf": No such file or directory
sysctl: cannot open "/etc/sysctl.d/90-omnibus-gitlab-net.core.somaxconn.conf": No such file or directory
---- End output of sysctl -e --system ----
Ran sysctl -e --system returned 255

问题原因分析:
丢失了报错中的这两个配置文件,进入/etc/sysctl.d目录发现,这两个文件都是通过链接到/opt/gitlab/embedded/etc/目录下。
然而/opt/gitlab/embedded/etc/确实没有这两个文件。 

[root@gitlab ~]# ll /etc/sysctl.d/
total 0
lrwxrwxrwx 1 root root 58 Nov 10 22:23 90-omnibus-gitlab-kernel.sem.conf -> /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.sem.conf
lrwxrwxrwx 1 root root 61 Nov 10 22:23 90-omnibus-gitlab-kernel.shmall.conf -> /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.shmall.conf
lrwxrwxrwx 1 root root 61 Nov 10 22:23 90-omnibus-gitlab-kernel.shmmax.conf -> /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.shmmax.conf
lrwxrwxrwx 1 root root 66 Nov 10 22:25 90-omnibus-gitlab-net.core.somaxconn.conf -> /opt/gitlab/embedded/etc/90-omnibus-gitlab-net.core.somaxconn.conf
lrwxrwxrwx. 1 root root 14 Oct 30 09:13 99-sysctl.conf -> ../sysctl.conf [root@gitlab ~]# ll /opt/gitlab/embedded/etc
total 12
-rw-r--r-- 1 root root 24 Apr 12 23:18 90-omnibus-gitlab-kernel.shmall.conf
-rw-r--r-- 1 root root 28 Apr 12 23:17 90-omnibus-gitlab-kernel.shmmax.conf
-rwxr-xr-x 1 root root 196 Apr 12 23:16 gitconfig [root@gitlab ~]# ll /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.sem.conf
ls: cannot access /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.sem.conf: No such file or directory
[root@gitlab ~]# ll /opt/gitlab/embedded/etc/90-omnibus-gitlab-net.core.somaxconn.conf
ls: cannot access /opt/gitlab/embedded/etc/90-omnibus-gitlab-net.core.somaxconn.conf: No such file or directory 解决方法一:
从别的备份机(或者在别的机器上重新安装一次,"gitlab-ctl reconfigure"之后生成这两个文件)将这两个文件拷贝回来! 解决方法二:
[root@gitlab ~]# vim /etc/gitlab/gitlab.rb
# unicorn['port'] = 8080
修改为:
unicorn['port'] = 8090 之后重新加载配置文件
[root@gitlab ~]# gitlab-ctl reconfigure 再次会报错,然后再修改/etc/gitlab/gitlab.rb,修改为原来的配置
[root@gitlab ~]# vim /etc/gitlab/gitlab.rb
# unicorn['port'] = 8080 再次重新加载配置文件就OK了!
[root@gitlab ~]# gitlab-ctl reconfigure 再次查看,发现上面配置中报错的两个文件已经存在了
[root@gitlab ~]# ll /opt/gitlab/embedded/etc/
total 20
-rw-r--r-- 1 root root 30 Apr 12 23:33 90-omnibus-gitlab-kernel.sem.conf
-rw-r--r-- 1 root root 24 Apr 12 23:18 90-omnibus-gitlab-kernel.shmall.conf
-rw-r--r-- 1 root root 28 Apr 12 23:17 90-omnibus-gitlab-kernel.shmmax.conf
-rw-r--r-- 1 root root 26 Apr 12 23:35 90-omnibus-gitlab-net.core.somaxconn.conf
-rwxr-xr-x 1 root root 196 Apr 12 23:16 gitconfig
[root@gitlab ~]# ll /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.sem.conf
-rw-r--r-- 1 root root 30 Apr 12 23:33 /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.sem.conf
[root@gitlab ~]# ll /opt/gitlab/embedded/etc/90-omnibus-gitlab-net.core.somaxconn.conf
-rw-r--r-- 1 root root 26 Apr 12 23:35 /opt/gitlab/embedded/etc/90-omnibus-gitlab-net.core.somaxconn.conf 最后再启动gitlab
[root@gitlab ~]# gitlab-ctl start

6、Gitlab更改默认Nginx  

更换gitlab自带Nginx,使用自行编译Nginx来管理gitlab服务。

自行编译的nginx服务和gitlab在同一台机器上
1)编辑gitlab配置文件禁用自带Nignx服务器
[root@gitlab ~]# vim /etc/gitlab/gitlab.rb
...
#设置nginx为false,关闭自带Nginx
nginx['enable'] = false
... 2)检查默认nginx配置文件,并迁移至新Nginx服务 (即将下面两个gitlab自带nginx的配置文件迁移到自行编译的新的nginx配置中)
/var/opt/gitlab/nginx/conf/nginx.conf #nginx配置文件,包含gitlab-http.conf文件
/var/opt/gitlab/nginx/conf/gitlab-http.conf #gitlab核心nginx配置文件 [root@gitlab ~]# cp /var/opt/gitlab/nginx/conf/nginx.conf /etc/nginx/conf.d/
[root@gitlab ~]# cp /var/opt/gitlab/nginx/conf/gitlab-http.conf /etc/nginx/conf.d/ 3)重启gitlab服务
[root@gitlab ~]# gitlab-ctl reconfigure
[root@gitlab ~]# gitlab-ctl restart 重启自行编译的nginx服务
[root@gitlab ~]# service nginx restart 如果访问报502。原因是nginx用户无法访问gitlab用户的socket文件。
重启gitlab需要重新授权
[root@gitlab ~]# chmod -R o+x /var/opt/gitlab/gitlab-rails  

-----------------------------------------------------------书山有路勤为径,学海无涯苦作舟-------------------------------------------------------------   

Gitlab 快速部署及日常维护 (二)的更多相关文章

  1. Gitlab 快速部署及日常维护 (一)

    一.GitLab简介GitLab 是一个用于仓库管理系统的开源项目,使用Git作为代码管理工具,并在此基础上搭建起来的web服务 二.GitLab系统架构git用户的主目录通常是/home/git(~ ...

  2. 【gitlab】gitlab快速部署教程

    gitlab快速部署教程 部署环境 Ubuntu 16.04(亲测可用) 开始部署 安装依赖 sudo apt-get install curl openssh-server ca-certifica ...

  3. Oracle 11.2.0.4.0 Dataguard部署和日常维护(7) - Dataguard Flashback篇

    1. 设置备库的闪回目录 show parameter db_recovery_file; NAME TYPE VALUE ------------------------------------ - ...

  4. Oracle 11.2.0.4.0 Dataguard部署和日常维护(6)-Dataguard Snapshot篇

    1. 检查当前主备库同步状态 on primary select ads.dest_id,max(sequence#) "Current Sequence", max(log_se ...

  5. Oracle 11.2.0.4.0 Dataguard部署和日常维护(6)-Active Dataguard篇

    1. 检查主备库的状态 on primary column DATABASE_ROLE format a20 column OPEN_MODE format a15 column PROTECTION ...

  6. Oracle 11.2.0.4.0 Dataguard部署和日常维护(5)-Datauard 主备切换和故障转移篇

    1. dataguard主备切换   1.1. 查看当前主备库是否具备切换条件 on slave select sequence#,first_time,next_time,archived,appl ...

  7. Oracle 11.2.0.4.0 Dataguard部署和日常维护(4)-Datauard Gap事件解决篇

    Oracle dataguard主库删除备库需要的归档时,会导致gap事情的产生,或者备库由于网络或物理故障原因,倒是备库远远落后于主库,都会产生gap事件,本例模拟gap事件的产生以及处理. 1. ...

  8. Oracle 11.2.0.4.0 Dataguard部署和日常维护(3)-Datauard监控篇

    1.  v$database    查看当前数据库的角色和保护模式 primary库查看 column NAME format a10 column PROTECTION_MODE format a2 ...

  9. Oracle 11.2.0.4.0 Dataguard部署和日常维护(2)-Datauard部署篇

    1. primary库设置dataguard相关参数   1.1. 强制primay库在任何状态下必须记录日志 SYS@userdata>select FORCE_LOGGING from v$ ...

随机推荐

  1. cursor pin s和cursor pin s wait on x

    1.cursor pin s是一个共享锁,一般情况下是因为发生在SQL短时间内大量执行 案例:在生产库中,突然出现大量的cursor pin s的等待,询问是否有动作后,同事说有编译存储过程(被误导了 ...

  2. qt for webassembly环境搭建图文教程

    一.前言 从Qt5.14开始,官方的在线安装提供了qt for webassembly构建套件,这对很多小白来说绝对是个好消息,也绝对是个好东西,好消息是不用再去交叉编译自己生成qt for weba ...

  3. (数据科学学习手札104)Python+Dash快速web应用开发——回调交互篇(上)

    本文示例代码已上传至我的Github仓库https://github.com/CNFeffery/DataScienceStudyNotes 1 简介 这是我的系列教程Python+Dash快速web ...

  4. 鸿蒙的多媒体及Menu组件及小程序的多媒体组件

    目录: js业务逻辑层 视图渲染层 css属性设置 效果图 微信小程序展示 内网穿透工具下载 我们在搭建一个小程序或者网站的时候,往往要加载很多的图片,音频和视频文件.如果都从服务器获取静态资源,这样 ...

  5. SQL Server和Oracle数据类型对应关系

    在工作中,有时会遇到跨库传输数据的情况,其中 SQL Server 和 Oracle 之间的数据传输是比较常见的情况. 因为 SQL Server 和 Oracle 的数据类型有些差异,这就要求我们在 ...

  6. 精通MySQL之架构篇

    老刘是即将找工作的研究生,自学大数据开发,一路走来,感慨颇深,网上大数据的资料良莠不齐,于是想写一份详细的大数据开发指南.这份指南把大数据的[基础知识][框架分析][源码理解]都用自己的话描述出来,让 ...

  7. Windows server 2008常用优化设置

    1. 如何取消开机按 CTRL+ALT+DEL登录? 控制面板→管理工具→本地安全策略→本地策略→安全选项→交互式登录:无须按CTRL+ALT+DEL→启用. 2. 如何取消关机时出现的关机理由选择项 ...

  8. 数据库内核——基于HLC的分布式事务实现深度剖析

    DTCC 2019 | 深度解码阿里数据库实现 数据库内核--基于HLC的分布式事务实现深度剖析-阿里云开发者社区 https://developer.aliyun.com/article/70355 ...

  9. ETL优化(转载)

    1.引言 数据仓库建设中的ETL(Extract, Transform, Load)是数据抽取.转换和装载到模型的过程,整个过程基本是通过控制用SQL语句编写的存储过程和函数的方式来实现对数据的直接操 ...

  10. (转载)微软数据挖掘算法:Microsoft 时序算法(5)

    前言 本篇文章同样是继续微软系列挖掘算法总结,前几篇主要是基于状态离散值或连续值进行推测和预测,所用的算法主要是三种:Microsoft决策树分析算法.Microsoft聚类分析算法.Microsof ...