如何查看Linux启动服务 systemctl列出所有服务

systemctl是现代linux系统管理服务的首选工具，因其统一接口、并行启动、依赖管理和丰富状态信息等优势。1. 使用systemctl list-unit-files –type=service可查看所有服务及其开机自启动状态；2. 通过grep enabled可过滤已启用的服务；3. 使用systemctl enable/disable可管理服务的开机自启动；4. 启动、停止、重启服务分别用systemctl start/stop/restart；5. 排查服务失败时，先用systemctl status和journalctl查看日志，再检查依赖、配置文件、权限、端口冲突、资源限制、selinux/apparmor及环境变量等问题，并逐一解决。掌握这些方法能实现对服务的全面控制。

查看Linux启动服务，尤其是那些配置为开机自启动的服务，systemctl无疑是现代Linux系统（基于systemd）里最核心、最直接的工具。它能让你清晰地看到哪些服务单元文件被加载了，它们当前的状态如何，以及更重要的是，它们是否被设定为系统启动时自动运行。

解决方案

要列出所有服务单元文件及其开机自启动状态，最直接的命令是：

systemctl list-unit-files --type=service

这条命令会显示一个包含服务名称、加载状态（LOAD）、活动状态（ACTIVE）、子状态（SUB）以及关键的“UNIT FILE STATE”列的列表。UNIT FILE STATE 这一列，会明确告诉你一个服务是 enabled（已启用，开机自启动）、disabled（已禁用，不开机自启动）、Static（静态，通常是依赖项，不能直接启用/禁用）还是 indirect（间接启用）。

如果你只想看那些已明确配置为开机自启动的服务，可以这样过滤：

systemctl list-unit-files --type=service | grep enabled

当然，这只是查看配置。如果你想知道当前哪些服务正在运行，那是另一个维度的问题，通常用 systemctl list-units –type=service –state=running。理解这两者的区别很重要：list-unit-files 看的是“配置”，而 list-units 看的是“当前运行状态”。

为什么systemctl是现代Linux管理服务的首选工具？

在我看来，systemctl之所以成为现代Linux系统（尤其是那些采用systemd作为初始化系统的发行版，比如centos 7/8、ubuntu 16.04+、debian 8+）管理服务的首选，甚至可以说是唯一真正全面且高效的工具，原因有很多。这不像以前，我们可能还在 chkconfig 和 service 之间纠结。

systemd的设计哲学就是统一和简化。它取代了传统的SysVinit和Upstart，带来了更快的启动速度、更好的依赖管理、更强大的日志系统（journald），以及一个统一的服务管理接口——systemctl。

chkconfig 主要是针对SysVinit脚本的，它通过在/etc/rcX.d/目录下创建软链接来管理服务在不同运行级别下的启动。而 service 命令，它本质上只是一个兼容层，用来执行SysVinit脚本或Upstart作业。在systemd系统上，service 命令很多时候会被重定向到 systemctl。

相比之下，systemctl 直接操作的是systemd的单元文件（.service、.target、.mount等），这些文件定义了服务的启动方式、依赖关系、资源限制等等。它的优势在于：

• 统一性： 不管是服务、挂载点、定时任务，甚至是套接字，都可以通过 systemctl 来管理，这大大降低了学习成本。
• 并行启动： systemd能够并行启动服务，这让系统启动速度飞快，而 systemctl 就是控制这种并行化的关键。
• 依赖管理： 单元文件内部清晰定义了服务之间的依赖关系，systemctl 能确保这些依赖被正确满足。
• 丰富的状态信息： systemctl status 提供的服务状态信息远比传统工具详细，包括CGroup信息、进程ID、日志片段等，这对于排查问题非常有用。

所以，如果你的Linux发行版是基于systemd的，那么花时间深入理解 systemctl 的用法，绝对是物超所值的一笔投资。

如何判断一个服务是否开机自启动并管理它？

判断一个服务是否开机自启动，最准确的方法就是看它在 systemctl list-unit-files –type=service 命令输出中的 UNIT FILE STATE。

• enabled: 这就意味着服务被配置为在系统启动时自动运行。它通常会在 /etc/systemd/system/multi-user.target.wants/ 或其他 .wants 目录下创建一个指向实际服务单元文件的软链接。
• disabled: 服务不会在系统启动时自动运行。相应的软链接通常是不存在的。
• static: 这类服务通常是其他服务的依赖项，或者它们本身并不直接启动，而是由其他单元文件触发。你不能直接用 systemctl enable/disable 来改变它们的状态。
• indirect: 这种状态表示服务是通过另一个单元文件间接启用的。

管理开机自启动：

一旦你确定了服务的状态，管理起来也相当直接：

• 启用服务（开机自启动）:

  sudo systemctl enable <service_name>

  这会在适当的 .wants 目录中创建软链接。

• 禁用服务（取消开机自启动）:

  sudo systemctl disable <service_name>

  这会移除相应的软链接。

实时操作服务：

除了管理开机自启动，你还需要知道如何即时控制服务：

• 启动服务: sudo systemctl start
• 停止服务: sudo systemctl stop
• 重启服务: sudo systemctl restart
• 查看服务状态: systemctl status <service_name>

掌握这些命令，你就能对系统上的服务有完全的控制权了。但记住，修改服务状态，尤其是禁用重要的系统服务，需要非常谨慎，否则可能会导致系统不稳定甚至无法启动。

排查Linux服务启动失败的常见原因和方法？

服务启动失败，这简直是家常便饭，尤其是在部署新应用或者系统升级之后。当我遇到这种情况时，通常会按照一套相对固定的思路去排查，这能大大提高效率。

第一步：查看服务状态和日志

这是最关键的第一步，也是大多数问题的突破口。

systemctl status <service_name>

这条命令会告诉你服务当前的活动状态（Active: active (running) 或 Active: failed）、加载状态，以及最近的几行日志输出。很多时候，错误信息就直接显示在这里。

如果 status 命令的日志不够详细，那就深入 journalctl：

journalctl -u <service_name>

这条命令会显示该服务的所有日志条目。你可以加上一些参数来更好地过滤：

• journalctl -u <service_name> -f: 实时跟踪日志，方便观察服务启动过程中的动态输出。
• journalctl -u <service_name> -b: 只看当前启动会话的日志。
• journalctl -u <service_name> –since “1 hour ago”: 查看过去一小时的日志。

常见原因和排查点：

1. 依赖问题： 服务可能依赖于另一个未启动或已失败的服务。

   • 检查：systemctl list-dependencies ，然后逐一检查依赖服务的状态。
   • 解决方案：确保所有前置依赖服务都已正常运行。

2. 配置文件错误： 这是最常见的错误之一。服务本身的配置文件（例如nginx的nginx.conf，mysql的my.cnf）有语法错误或配置不当。

   • 检查：服务通常会有自带的配置检查工具（如Nginx的 nginx -t）。另外，手动检查配置文件中的拼写、路径、权限等。
   • 解决方案：修正配置文件，然后 sudo systemctl daemon-reload (如果修改了systemd单元文件本身) 或 sudo systemctl restart 。

3. 权限问题： 服务进程没有足够的权限去读写它需要的文件或目录。

   • 检查：查看日志中是否有 Permission denied 字样。确认服务运行用户（通常在单元文件里定义）对相关文件和目录有读写执行权限。
   • 解决方案：使用 chmod 或 chown 调整权限。

4. 端口冲突： 如果是网络服务，它可能想监听的端口已经被其他进程占用。

   • 检查：sudo netstat -tulnp | grep 或 sudo lsof -i :。
   • 解决方案：停止占用端口的进程，或者修改服务监听的端口。

5. 资源限制： 服务可能超出了系统或cgroup设定的资源限制（如内存、文件句柄数）。

   • 检查：journalctl 日志中可能会有OOM (Out Of Memory) 或其他资源限制的报错。
   • 解决方案：调整服务单元文件中的资源限制参数（如 LimitNOFILE），或增加系统资源。

6. SELinux/AppArmor： 这些安全增强模块可能会阻止服务执行某些操作。

   • 检查：sudo audit2allow -a -M mymodule (SELinux) 或查看 /var/log/audit/audit.log。AppArmor日志通常在 dmesg 或 syslog 中。
   • 解决方案：根据日志信息创建SELinux策略，或者禁用/调整AppArmor配置文件（如果确定是它们导致的问题）。

7. 环境问题： 服务启动时，可能缺少某些必要的环境变量。

   • 检查：在服务单元文件中，查看 Environment= 或 EnvironmentFile= 配置。
   • 解决方案：在单元文件中添加或修正环境变量。

排查问题就像侦探工作，一步步抽丝剥茧，最终总能找到症结所在。耐心和细致，是解决这些问题的关键。