在Linux系统里，想知道到底有哪些服务在跑，或者哪些服务准备开机启动，这其实是个很基础但又很关键的问题。简单来说，最直接的办法就是用
systemctl
命令，它是现代Linux发行版（比如Ubuntu、CentOS、Debian等，只要是基于systemd的）管理服务的主力。敲一个
systemctl list-units --type=service --all
，基本上就能把所有加载的服务单元，无论是运行的、停止的、失败的，都给你列出来。如果想看哪些服务文件是存在的，以及它们的默认状态（启用或禁用），
systemctl list-unit-files --type=service
会更合适。
解决方案
要查看Linux系统中所有已安装的服务列表，主要取决于你的Linux发行版使用的是哪种初始化系统。目前主流的是systemd，但也有一些老系统或特定场景还在用SysVinit或Upstart。
对于基于systemd的系统（绝大多数现代Linux发行版）：
-
查看所有已加载的服务单元及其状态：
systemctl list-units --type=service --all
这个命令会列出所有当前systemd知道的服务单元，包括那些正在运行、已经停止、加载失败的，以及那些只是静态存在但未被激活的服务。输出会显示服务名称、加载状态、活动状态、子状态和简短描述。
-
查看所有已安装的服务文件及其启用/禁用状态：
systemctl list-unit-files --type=service
这个命令列出所有可用的服务单元文件，以及它们是否被配置为开机启动（
enabled
）或禁用（
disabled
）。这对于了解系统上“潜在”的服务列表非常有用，即使它们当前没有运行。
-
查看正在运行的进程，间接推断服务：
ps aux | grep -i 'daemon|service'
虽然不是直接的服务列表，但很多服务都以守护进程（daemon）的形式运行。这个命令可以帮助你发现一些不一定通过systemd直接管理，但确实在后台运行的程序。当然，结果需要人工筛选。
-
查看监听端口，推断网络服务：
ss -tulnp # 或者对于老系统 netstat -tulnp
这个命令会列出所有正在监听TCP和UDP端口的进程。每个监听端口通常都对应着一个网络服务（如SSH、Web服务器、数据库等）。通过查看
PID/Program name
列，你可以大致判断是哪个服务在提供网络功能。
对于基于SysVinit或Upstart的系统（较旧的发行版或特定场景）：
-
查看所有已知的服务及其状态：
service --status-all
这个命令会遍历
/etc/init.d/
目录下的所有脚本，并尝试获取它们的状态。输出通常会显示
[ + ]
表示运行，
[ - ]
表示停止，
[ ? ]
表示状态未知。这能给你一个大致的服务概览。
-
查看开机自启的服务（SysVinit）：
chkconfig --list # 或者手动检查 /etc/rcX.d/ 目录 ls /etc/rc?.d/S*
chkconfig --list
会列出所有通过chkconfig管理的服务在不同运行级别下的启动状态。对于SysVinit，开机自启的服务通常是通过在
/etc/rcX.d/
目录下创建指向
/etc/init.d/
脚本的符号链接来实现的，
S
开头的表示启动，
K
开头的表示停止。
为什么不同的Linux发行版查看服务命令不尽相同？
这事儿说起来，其实是Linux初始化系统演进的结果。早期，几乎所有的Linux发行版都依赖于SysVinit。它的服务管理方式比较简单粗暴，主要就是一堆shell脚本放在
/etc/init.d/
目录下，然后通过在
/etc/rcX.d/
（X代表运行级别）里创建符号链接来控制服务在不同运行级别下的启动和停止。
service
命令和
chkconfig
就是用来与这些脚本交互的。它的缺点也挺明显：启动慢（服务串行启动）、依赖管理弱、不够灵活。
后来，为了解决SysVinit的这些痛点，一些新的初始化系统应运而生，其中比较有代表性的是Ubuntu引入的Upstart。Upstart尝试用事件驱动的方式来管理服务，理论上可以实现并行启动，并且更好地处理服务间的依赖关系。它有自己的配置文件格式，但通常也能兼容SysVinit的脚本，所以
service
命令在Upstart系统上很多时候也依然有效。
再后来，systemd横空出世，并且迅速成为了主流。它被设计成一个高度并行、功能强大、且对服务依赖关系有精细控制的初始化系统。systemd不仅仅是初始化系统，它还集成了日志管理（journald）、设备管理、网络配置等诸多功能，形成了一个庞大的生态系统。它的服务单元文件（
.service
文件）通常位于
/etc/systemd/system/
或
/usr/lib/systemd/system/
，配置起来更加结构化。
systemctl
就是systemd提供给用户和服务管理员的统一接口，几乎可以管理所有与systemd相关的组件。
所以，当你从一个老旧的CentOS 6（SysVinit）跳到CentOS 7/8/9或任何现代Ubuntu（systemd）时，会发现以前用的
service httpd status
可能还能跑（因为systemd通常会提供兼容层），但更推荐、更强大的命令已经是
systemctl status httpd
了。这种命令上的差异，本质上就是底层初始化系统哲学和实现方式的差异。理解这一点，能帮助我们更好地适应不同环境。
如何判断一个服务是否正在运行并设置其开机自启？
判断服务状态和设置开机自启是日常系统管理中非常频繁的操作。
判断服务是否正在运行：
对于systemd系统，使用
systemctl status <服务名称>
是首选。例如，要检查Nginx是否在运行：
systemctl status nginx
输出会非常详细，包括服务的加载状态（Loaded）、活动状态（Active: active (running)表示正在运行，active (exited)表示运行后退出，inactive (dead)表示未运行）、进程ID、内存占用、最近的日志片段等等。重点看
Active
那一行，如果显示
active (running)
，那就说明服务正在正常运行。
对于SysVinit/Upstart系统，使用
service <服务名称> status
。例如：
service apache2 status
它通常会返回一个简单的状态信息，比如”Apache2 is running”或者”Apache2 is not running”。有时候，它也可能显示一个PID文件路径或进程ID。
设置服务开机自启：
对于systemd系统，设置开机自启非常直观：
-
启用服务（开机自启）：
systemctl enable <服务名称>
这个命令会在
systemd
的配置目录中创建必要的符号链接，确保服务在系统启动时被激活。
-
禁用服务（取消开机自启）：
systemctl disable <服务名称>
这个命令会移除
enable
命令创建的符号链接，阻止服务在系统启动时自动运行。
-
立即启动服务：
systemctl start <服务名称>
-
立即停止服务：
systemctl stop <服务名称>
-
立即重启服务：
systemctl restart <服务名称>
对于SysVinit系统，设置开机自启稍微复杂一些，因为它涉及到运行级别：
-
使用
chkconfig
（如果已安装并配置）：
chkconfig <服务名称> on # 在所有默认运行级别下启用 chkconfig <服务名称> off # 在所有默认运行级别下禁用 chkconfig --level 35 <服务名称> on # 在运行级别3和5下启用
chkconfig
工具会帮你管理
/etc/rcX.d/
目录下的符号链接。
-
手动管理（不推荐，但了解原理有用）： 你可以手动在
/etc/rcX.d/
目录下创建或删除指向
/etc/init.d/<服务名称>
脚本的符号链接。以
S
开头的链接表示启动，
K
开头的表示停止。例如，
S99myservice
表示在启动时以99的优先级启动
myservice
。
如何排查服务启动失败或运行异常的问题？
当服务启动失败或者运行异常时，这可真是让人头疼。但别慌，大部分问题都有迹可循，关键在于知道去哪里找线索。我的经验是，遵循一套系统性的排查流程，能大大提高解决问题的效率。
-
查看服务状态及日志（Systemd是王道）： 这是第一步，也是最关键的一步。
systemctl status <服务名称>
这条命令会给你一个服务的即时快照，包括它是否正在运行、失败的原因（如果失败了）、以及最近的日志片段。如果这里显示
Active: failed
，通常会有
Main PID
和
CGroup
等信息，以及一个错误描述。
更深入地，利用
journalctl
查看服务的完整日志：
journalctl -u <服务名称> --since "1 hour ago" -e
-u
指定服务单元，
--since
限制时间范围（比如过去一小时），
-e
跳转到日志末尾。仔细阅读日志，通常错误信息会非常清晰地告诉你问题所在，比如配置错误、权限问题、端口冲突、依赖服务未启动等。
-
检查服务单元文件（Systemd）： 服务单元文件（通常是
/etc/systemd/system/<服务名称>.service
或
/usr/lib/systemd/system/<服务名称>.service
）定义了服务的行为。
systemctl cat <服务名称>
这个命令会显示服务单元文件的内容。你需要检查：
-
ExecStart
：确保启动命令和参数是正确的。
-
WorkingDirectory
：工作目录是否正确且存在。
-
User
/
Group
：服务运行的用户和组是否有足够的权限。
-
Environment
：环境变量是否正确设置。
-
Requires
/
After
：依赖服务是否已启动。比如，一个Web服务可能需要数据库服务先启动。
-
-
检查配置文件： 绝大多数服务都有自己的配置文件，比如Nginx的
/etc/nginx/nginx.conf
，MySQL的
/etc/my.cnf
。
- 语法错误： 很多服务在启动时会检查配置文件的语法。如果日志中提示
Configuration error
，很可能就是配置文件写错了。可以使用服务自带的工具进行检查，例如
nginx -t
、
apachectl configtest
。
- 权限问题： 配置文件本身或其包含的目录，服务运行的用户是否有读取权限？
- 路径错误： 配置文件中引用的文件或目录路径是否存在且正确？
- 语法错误： 很多服务在启动时会检查配置文件的语法。如果日志中提示
-
权限问题： 这是新手常犯的错误，也是老手偶尔疏忽的地方。服务需要读取文件、写入日志、创建PID文件等，这些操作都需要相应的权限。
- 检查服务运行的用户（通常在服务单元文件中定义）对相关目录和文件是否有读写执行权限。
- 特别注意
/var/log/
、
/var/run/
、
/var/lib/
以及服务自己的数据目录。
-
端口冲突： 如果服务是一个网络服务，它需要监听一个端口。如果这个端口已经被其他进程占用，服务就无法启动。
ss -tulnp | grep <端口号> # 或者 netstat -tulnp | grep <端口号>
这会显示哪个进程正在监听该端口。如果发现冲突，你需要停止占用端口的进程，或者修改服务的配置让它监听另一个端口。
-
资源限制： 虽然不常见，但有时候服务启动失败是因为系统资源不足，比如内存耗尽、文件描述符达到上限等。
- 检查
dmesg
输出，看看是否有OOM（Out Of Memory）杀手的信息。
- 检查
ulimit -a
（针对当前shell）或服务单元文件中的
LimitNOFILE
等参数。
- 检查
-
依赖服务未启动： 如果服务A依赖于服务B，而服务B没有启动，那么服务A自然也无法启动。日志中通常会明确指出依赖失败。
- 确认所有前置依赖服务都已成功启动。
排查问题就像侦探破案，你需要从各种线索中找出真相。多看日志、多思考、多尝试，通常都能找到症结所在。
linux mysql centos go apache nginx ubuntu 工具 ai 环境变量 mysql nginx Error 接口 堆 var 事件 数据库 udp linux ubuntu centos ssh debian