目录
[方法一：查看 /proc//cgroup 文件](#方法一：查看 /proc//cgroup 文件)
[方法二：使用 ps 命令结合 --cgroup 选项](#方法二：使用 ps 命令结合 --cgroup 选项)
[关于 system.slice 与 user.slice](#关于 system.slice 与 user.slice)
[步骤1 -判断是否是system服务进程](#步骤1 -判断是否是system服务进程)
[步骤2 -判断服务所在目录，查找启动脚本](#步骤2 -判断服务所在目录，查找启动脚本)
[步骤3 -判断是否将启动命令/脚本添加至开启启动，或者计划任务crond检测启动](#步骤3 -判断是否将启动命令/脚本添加至开启启动，或者计划任务crond检测启动)
[步骤4 - 获得帮助](#步骤4 - 获得帮助)
当一个老的服务出了问题或者是因为机房搬迁等等原因 需要重启时，没有对应的文档手册，怎么找到启动方式呢?
一般的方式是 ++ps、/proc/PID/、systemd-cgls、history ++ 和查看相关启动目录和文件 等等。
例如: 一个看起来很像命令行启动的，bin文件加指定后台的参数(-q、 -D、 --deamon等),但其实是个systemd管理的服务。
[root@nessus ~]# ps -ef|grep -v grep |grep nessus
root 5740 1 0 Jun13 ? 00:00:00 /opt/nessus/sbin/nessus-service -q
root 5741 5740 0 Jun13 ? 00:08:59 nessusd -q
如果是systemd管理的服务怎么快速找到对应的服务器呢
先来看看 systemctl status 命令
[root@tserver121 ~]# systemctl status docker.service
● docker.service - Docker Application Container Engine
Loaded: loaded (/usr/lib/systemd/system/docker.service; disabled; vendor preset: disabled)
Active: active (running) since Wed 2023-06-21 14:55:28 CST; 11 months 24 days ago
Docs: https://docs.docker.com
Main PID: 35647 (dockerd)
CGroup: /system.slice/docker.service
└─35647 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
Loaded:
- loaded 表示该服务已加载。
- /usr/lib/systemd/system/docker.service 是该服务的单元文件路径。
- disabled 表示该服务被设置为开机自启动。
- vendor preset: disabled 表示该服务的供应商预设值是禁用的，但已经被手动启用。
Active:
- active (running) 运行状态
Main PID: 35647 (dockerd)
- 主进程 与进程名
CGroup:
- /system.slice/docker.service 表示该服务属于 system.slice 控制组，服务名为docker.service
很明显的看到docker 进程 是由 docker.service 来管理启动的 启动文件在/usr/lib/systemd/system/docker.service。
有些服务是存在依赖服务的，所以需要找到提供正确的启动方式
通过查看
/usr/lib/systemd/system/docker.service还能看到还有些依赖服务After=network-online.target firewalld.service containerd.service
Wants=network-online.target
Requires=docker.socket containerd.service
什么是CGroup
控制组（cgroup）是一种用于限制、记录和隔离进程资源使用（如 CPU、内存、磁盘 I/O 等）的机制，每个进程都有 cgroup来管理。
查找进程对应的systemd服务
所以对于systemctl 来管理的进程，能很快的通过
cgroup找到对应的服务
[root@nessus ~]# ps -ef|grep -v grep |grep nessus
root 5740 1 0 Jun13 ? 00:00:00 /opt/nessus/sbin/nessus-service -q
root 5741 5740 0 Jun13 ? 00:08:59 nessusd -q
对于上面这个例子可以使用下面方法
方法一：查看 /proc/<PID>/cgroup 文件
[root@nessus nessus]# cat /proc/5740/cgroup
11:memory:/
10:devices:/system.slice
9:blkio:/
8:net_prio,net_cls:/
7:cpuset:/
6:hugetlb:/
5:pids:/
4:perf_event:/
3:cpuacct,cpu:/
2:freezer:/
1:name=systemd:/system.slice/nessusd.service
1:name=systemd:/system.slice/nessusd.service 表示进程 cgroup 控制下，归属于服务
nessusd.service。其他解释 ：
memory：控制和监控内存使用。
blkio：控制和监控块设备 I/O（如硬盘）。
cpuset：将进程分配到特定的 CPU 和内存节点。
devices：/system.slice 控制进程对设备的访问权限。 归属于system.slice服务
freezer：暂停和恢复进程。
net_cls 和 net_prio：控制和监控网络流量。
pids：限制和监控进程数目。
方法二：使用 ps 命令结合 --cgroup 选项
ps -o pid,cgroup -p <PID>
[root@nessus nessus]# ps -o pid,cgroup -p 5740
PID CGROUP
5740 10:devices:/system.slice,1:name=systemd:/system.slice/nessusd.service
方法三：systemd-cgls
用于显示当前系统中的控制组（cgroups）层次结构及其包含的进程 很快的区别是否是systemd服务
├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 22
├─user.slice
│ └─user-0.slice
│ └─session-57.scope
│ ├─7021 /export/devops/bin/python3 /export/devops/bin/gunicorn -c gunicorn.py tools.wsgi:application --reload -D
│ ├─7023 /export/devops/bin/python3 /export/devops/bin/gunicorn -c gunicorn.py tools.wsgi:application --reload -D
│ ├─7024 /export/devops/bin/python3 /export/devops/bin/gunicorn -c gunicorn.py tools.wsgi:application --reload -D
│ ├─7025 /export/devops/bin/python3 /export/devops/bin/gunicorn -c gunicorn.py tools.wsgi:application --reload -D
│ └─9329 /export/devops/bin/python3 /export/devops/bin/gunicorn -c gunicorn.py tools.wsgi:application --reload -D
└─system.slice
└─nessusd.service
├─5740 /opt/nessus/sbin/nessus-service -q
└─5741 nessusd -q
关于 system.slice 与 user.slice
slice是控制组的一种类型，用于组织和划分系统资源。常见的包括 system.slice 和 user.slice。
-
- system.slice：通常是由systemd 启动和管理。
- user.slice：通常是由用户会话启动和管理，俗称命令行启动。
方法四：查看文件
systemd 的文件主要在
/usr/lib/systemd/system和/etc/systemd/systemservice（centos 6）的文件主要在
/etc/init.d/通过grep命令 获取关键字所在文件
查找非system服务进程
不一定100% 能找到原服务所提供的命令或者脚本启动。需要靠用户的行为习惯,但需要验证与进程是否一致。
[root@tserver121 redis]# ps -ef |grep -v grep |grep redis
root 99667 1 0 19:27 ? 00:00:00 ./bin/redis-server 10.3.246.108:16379
步骤1 -判断是否是system服务进程
[root@tserver121 redis]# ps -o pid,cgroup -p 99667
PID CGROUP
99667 11:pids:/user.slice,8:blkio:/user.slice,6:cpuacct,cpu:/user.slice,5:memory:/user.slice,3:devices:/user.slice,1:name=systemd:/user.slice/user-0.slice/session-682120.scope
是由user.slice 管理的， 非system服务进程。
步骤2 -判断服务所在目录，查找启动脚本
[root@tserver121 redis]# cd /opt/app/redis/
[root@tserver121 redis]# ./bin/redis-server ./etc/redis.conf #启动命令
[root@tserver121 redis]# ll /proc/99667/
lrwxrwxrwx 1 root root 0 Jun 14 19:33 cwd -> /data/redis
lrwxrwxrwx 1 root root 0 Jun 14 19:33 exe -> /opt/app/redis/bin/redis-server
cwd 为程序的工作目录，exe为进程的可执行文件（同级目录），或者是exe 指向的程序的项目根目录
/opt/app/redis
一般而言执行启动操作是会先cd到以上的相关目录下，再执行相关的启动操作，会留下相关的启动文档 或者脚本,比方说service.sh/start.sh 等等
步骤3 -判断是否将启动命令/脚本添加至开启启动，或者计划任务crond检测启动
systemd 的文件主要在
/usr/lib/systemd/system和/etc/systemd/systemservice（centos 6）的文件主要在
/etc/init.d/通过grep命令 获取关键字所在文件
计划任务crond：对应启动用户的任务查看
一般比较重要的服务器都需要添加到开机自启动中, 良好的用户习惯能减少很多麻烦。
步骤4 - 获得帮助
history命令历史：一般线上的服务器，操作较少，对应的相关命令也可能会保留的时间较长，当然也可能有用户处理后清理命令历史的策略- 互联网：如果是比较正规的应用，网上一般都能查到，比如：
nessusd- 审计：如果是平台下发的命令，可以从审计中查找