1 场景复现

2 原因

harbor-db卷映射到本地的文件已存在（/data/database/pg13），并且本地存储文件的权限异常，
因为之前我在使用data存储数据时，将该路径的权限修改了，改变了pg13的读写权限，
异常的pg13权限如下图所示：

3 方案

（1）删除本地存储的pg13文件：开发环境，没有重要数据，我直接删除。
（2）修改文件权限为：0700或者0750。生产服务，禁止直接删除文件。
进入本地db挂载路径：/data/database

sudo chown -R 0700 pg13
sudo chown -R 0750 pg13

正常的pg13文件权限如下图所示：

（3）重启harbor：

# 停止容器
sudo docker-compose down
# 重启容器
sudo docker-compose -f /your-harbor-path/docker-compse.yml up -d

4 分析

4.1 启动Harbor

4.2 查看日志

harbor日志存储目录：/var/log/harbor
目录下日志文件：

4.2.1 查看core日志

为什么查看core日志，因为登录时提示核心服务异常。

tailf -200 core.log

核心服务日志内容如下图所示，由图可知，postgresql出现异常，当然，
这仅仅提示我们需要查看postgresql日志，没有给出具体的异常原因。

Nov 5 12:51:40 172.18.0.1 core[2240]: 2022-11-05T04:51:40Z [ERROR] [/common/utils/utils.go:106]: failed to connect to tcp://postgresql:5432, retry after 2 seconds :dial tcp: lookup postgresql on 127.0.0.11:53: no such host
Nov 5 12:51:42 172.18.0.1 core[2240]: 2022-11-05T04:51:42Z [ERROR] [/common/utils/utils.go:106]: failed to connect to tcp://postgresql:5432, retry after 2 seconds :dial tcp: lookup postgresql on 127.0.0.11:53: no such host
Nov 5 12:51:44 172.18.0.1 core[2240]: 2022-11-05T04:51:44Z [ERROR] [/common/utils/utils.go:106]: failed to connect to tcp://postgresql:5432, retry after 2 seconds :dial tcp 172.18.0.8:5432: connect: connection refused

4.2.2 查看db日志

tailf -200 postgresql.log

打开postgresql.log，日志信息如下图所示，由图可知，数据库存储的文件权限异常，无效的权限。
为什么？
因为，我在配置其他服务是，强行改变了该文件的权限配置，
导致，harbor再次启动harbor-db时，重新载入了pg13文件，出现权限异常。
postgresql的日志信息如下图所示，由图可知，pg13的权限是无效的，应该为：rwx（0700）或者rwxrx（0750）

进入本地db挂载路径：/data/database

sudo chown -R 0700 pg13
sudo chown -R 0750 pg13

FATAL: data directory “/var/lib/postgresql/data/pg13” has invalid permissions
Nov 5 12:48:40 172.18.0.1 postgresql[2240]: 2022-11-05 04:48:40.764 UTC [1] DETAIL: Permissions should be u=rwx (0700) or u=rwx,g=rx (0750).

正常的pg13权限如下图所示：

4.3 路径挂载

进入harbor路径，打开配置文件：/path/docker-compose.yml
查看postgresql配置，如下图所示，由图可知，db的路路径挂载：

5 小结

（1）Harbor核心服务不可用时，先查看日志：core.log，根据提示，再查看其他日志；
（2）Harbor默认日志路径：/var/log/harbor；
（3）harbor-db配置数据库文件挂载后，不可修改其读写权限，否则Harbor重启后，无法正常加载。

线上问题：Harbor核心服务不可用相关推荐

史上最全的高可用服务系统线上问题排查工具单（一）
来自:云时代架构上一篇文章保证高可用Java服务化系统高效运行的必备工具箱介绍了笔者在互联网公司里线上应急和技术攻关过程中积累的应用层脚本和Java虚拟机命令,这些脚本和命令在发现问题和定位问题的过 ...
Keepalived+Nginx实现高可用，反向代理---模拟实现线上环境
[前言] 在对Keepalived+Nginx进行了研究后,将这项技术推广上线,并配合运维进行网站搭建起来.经过一段时间的运行线上环境运行已经稳定,不过自己还需要进行更加深入的研究:那么如何模拟线上 ...
线上流量突增百万高可用保障方案
一:事前预防 1.预估系统瓶颈 1.1 梳理核心接口按调用量梳理Top100 PM按业务重要等级梳理下端可能起量的接口输出终版的接口文档 1.2 评估核心接口最高的TPS 测试环境模拟生产环境数据 ...
GTA5内置html菜单源码,【GTA5线上1.46版本免费内置菜单菜单】【5款目前最新可用的内置菜单可供选择】刷钱、套模型、无敌、传送...
功能上有线上刷钱,给其他玩家套模型 ,无敌传送等等首先先回答大家几个关于内置菜单的问题 1.内置菜单会封号嘛? 回答:外置菜单也会有几率封号,我只能说是挂都会有封号的几率,用内置就像抽烟的人对比不 ...
RPC的超时设置，一不小心就是线上事故
来自:IT人的职场进阶上面这张监控图,对于服务端的研发同学来说再熟悉不过了.在日常的系统维护中,『服务超时』应该属于监控报警最多的一类问题. 尤其在微服务架构下,一次请求可能要经过一条很长的链路,跨 ...
醉了，RPC 超时设置也能引起线上事故！
上面这张监控图,对于服务端的研发同学来说再熟悉不过了.在日常的系统维护中,『服务超时』应该属于监控报警最多的一类问题. 尤其在微服务架构下,一次请求可能要经过一条很长的链路,跨多个服务调用后才能返回结 ...
同时设置超时时间_刚入职的小菜鸡，设错了RPC超时，搞了个线上事故
上面这张监控图,对于服务端的研发同学来说再熟悉不过了.在日常的系统维护中,『服务超时』应该属于监控报警最多的一类问题. 尤其在微服务架构下,一次请求可能要经过一条很长的链路,跨多个服务调用后才能返回结 ...
RPC 的超时设置，一不小心就是线上事故！
作者 | 骆俊武来源 | IT人的职场进阶(ID:BestITer) 上面这张监控图,对于服务端的研发同学来说再熟悉不过了.在日常的系统维护中,『服务超时』应该属于监控报警最多的一类问题. 尤其在微 ...
SDCC 2016线上架构峰会顾问团、嘉宾、议题、日程大公开（免费报名）
始建于2007年的SDCC,已经成功举办七届,历届技术讲师超过550位,参会人数超过7500人,成为技术圈口碑卓越的技术会议品牌.今年开始,为创造更多的技术交流和分享机会,CSDN已将SDCC拓展为关 ...

线上问题：Harbor核心服务不可用