service命令用于管理Linux服务，核心操作包括start、stop、restart和status，需root权限执行；它基于SysVinit脚本，而systemctl是更现代的systemd工具，支持并行启动和依赖管理；尽管service在新系统中常被systemctl兼容接管，查看所有服务可用sudo service --status-all，但更推荐使用systemctl list-units --type=service --all获取完整信息；若service命令失效，应检查服务名称、脚本存在性、权限、日志及配置错误或端口冲突。
在Linux系统中，
service命令是一个相对传统的工具，用于管理系统后台运行的服务。它简化了与
/etc/init.d目录下脚本的交互，让我们能够方便地启动、停止、重启或查看特定服务的运行状态。尽管现代Linux发行版更多地转向了
systemctl，但在许多旧系统或一些特定场景下，
service命令依然是管理服务的重要方式，其背后通常也是在调用相应的初始化脚本。
解决方案
使用
service命令管理服务，核心操作围绕着几个关键词：
start、
stop、
restart和
status。你需要以root权限执行这些命令，通常这意味着在命令前加上
sudo。
要启动一个服务，比如Apache（通常服务名为
apache2或
httpd）：
sudo service apache2 start
这会尝试执行
/etc/init.d/apache2 start脚本，让Apache服务运行起来。
如果你需要停止一个正在运行的服务：
sudo service apache2 stop
这会发送停止信号给服务，使其终止运行。
当服务配置发生变化，或者你只是想刷新服务状态而不完全关闭再启动，
restart命令就派上用场了：
sudo service apache2 restart
它通常会先尝试停止服务，然后再启动。
而要查看一个服务的当前运行状态，这对于排查问题或确认服务是否正常启动至关重要：
sudo service apache2 status
这个命令会告诉你服务是否正在运行、进程ID（PID）等信息，有时还会输出最近的日志片段，这真的很有用。
service命令与systemctl命令有何异同？
这是一个非常好的问题，因为很多初学者都会在这两个命令之间感到困惑。我个人觉得，理解它们的异同，就像理解Linux系统演进的一个缩影。
service命令是SysVinit（System V init）体系下的产物，它本质上是一个包装器，用于执行
/etc/init.d/目录下那些符合特定规范的shell脚本。这些脚本负责定义服务的启动、停止、重启等逻辑。它的优点是简单直观，在很长一段时间内都是Linux服务管理的主流。
然而，随着系统变得越来越复杂，SysVinit的串行启动、依赖管理不便等问题逐渐显现。于是，
systemd应运而生，并带来了
systemctl命令。
systemctl是
systemd服务管理器的核心工具，它直接与
systemd守护进程通信，管理着所有的“单元”（unit），包括服务（service）、挂载点（mount）、设备（device）等等。
systemd的优势在于：
JTBC CMS(5.0) 是一款基于PHP和MySQL的内容管理系统原生全栈开发框架，开源协议为AGPLv3，没有任何附加条款。系统可以通过命令行一键安装，源码方面不基于任何第三方框架，不使用任何脚手架，仅依赖一些常见的第三方类库如图表组件等，您只需要了解最基本的前端知识就能很敏捷的进行二次开发，同时我们对于常见的前端功能做了Web Component方式的封装，即便是您仅了解HTML/CSS也
- 并行启动： 大幅缩短了系统启动时间。
- 依赖管理： 可以清晰地定义服务间的依赖关系。
-
统一管理： 不仅仅是服务，系统中的各种资源都可以通过
systemctl
来管理。 -
更强大的日志：
journalctl
与systemd
紧密集成，提供了更强大的日志查询功能。
所以，它们的主要区别在于：
service是基于传统SysVinit脚本的，而
systemctl是基于
systemd单元配置文件的。
相同点在于，在很多现代Linux发行版中，
service命令实际上已经被
systemd“接管”了。当你执行
sudo service apache2 start时，
service命令很可能只是将这个请求转发给了
systemctl，最终还是由
systemd来处理。这意味着，即使你习惯使用
service，在底层它也可能在与
systemd打交道。
我的建议是，如果你在较新的系统上工作，学习并习惯使用
systemctl是更明智的选择，因为它更强大、更符合现代Linux的设计哲学。但如果你维护的是老旧系统，或者只是需要快速执行一些基本操作，
service依然是一个可靠且直观的选择。
如何查看所有可用服务及其状态？
有时候，我们不确定某个服务的确切名称，或者想一览系统上到底有哪些服务在运行或可以运行。这在排查问题或进行系统审计时非常有用。
使用
service命令，你可以通过
--status-all选项来列出所有已知的服务及其大致状态：
sudo service --status-all
执行这个命令后，你会看到一长串服务列表，每个服务前面会有一个符号：
[ + ]表示服务正在运行，
[ - ]表示服务已停止，
[ ? ]表示服务状态未知或无法确定。这个输出虽然有些粗糙，但能让你快速对系统服务有一个概览。
需要注意的是，
service --status-all只列出
/etc/init.d/目录下有相应脚本的服务。如果某个服务完全由
systemd管理，且在
/etc/init.d/中没有对应的兼容脚本，那么它可能不会出现在
service --status-all的列表中。
如果想获得更全面、更精确的服务列表和状态，尤其是在使用
systemd的系统上，我更倾向于使用
systemctl：
systemctl list-units --type=service --all
这个命令会列出所有类型的服务单元，包括那些已加载、已激活、已停止或处于其他状态的服务。输出会非常详细，包括服务的完整名称（通常以
.service结尾）、加载状态、激活状态和描述。通过
grep配合使用，你可以很方便地筛选出你关心的服务，例如：
systemctl list-units --type=service --all | grep apache
这会显示所有与"apache"相关的服务单元。这种方式在现代Linux环境中，无疑提供了更清晰、更全面的服务视图。
遇到service命令无效或服务启动失败怎么办？
当
service命令不按预期工作，或者你尝试启动服务却失败了，这确实让人头疼。我遇到过不少次这样的情况，通常有几个方向可以去排查：
服务名称是否正确？ 这是最常见的问题。你可能认为服务叫
nginx
，但实际上它的脚本在/etc/init.d/
下是nginx
或者nginx-service
，甚至更奇特的名称。使用ls /etc/init.d/
查看一下，确认服务脚本的实际名称。服务脚本是否存在？ 如果服务名称确认无误，但
service
命令仍然报错“Unrecognized service”或类似信息，很可能是因为/etc/init.d/
目录下根本就没有这个服务的脚本。这可能意味着服务没有安装，或者它完全由systemd
管理，没有提供SysVinit兼容脚本。在这种情况下，你就应该尝试使用systemctl
来管理它。权限问题？ 确保你正在使用
sudo
。service
命令通常需要root权限才能执行启动、停止、重启等操作。如果你忘记了sudo
，很可能会收到权限拒绝的错误。-
查看服务状态和日志 即使启动失败，
sudo service
也可能会提供一些有用的线索。它通常会显示服务最近的错误信息。更深入地，你需要查看系统的日志文件：status -
传统日志： 检查
/var/log/syslog
、/var/log/messages
或服务特定的日志文件（例如，Apache的日志通常在/var/log/apache2/
或/var/log/httpd/
）。 -
systemd日志： 如果你的系统使用
systemd
，那么journalctl -xe
是一个非常强大的工具，它能显示最新的系统日志，包括服务的详细错误信息。你可以通过journalctl -u
来过滤特定服务的日志。
-
传统日志： 检查
服务配置错误？ 有时候服务本身启动失败，并不是
service
命令的问题，而是服务的配置文件有误。例如，Apache的httpd.conf
或Nginx的nginx.conf
中可能存在语法错误或路径配置不当。这时，你需要仔细检查服务的配置文件，并可能需要运行服务自带的配置检查工具（如apachectl configtest
）。端口冲突？ 另一个服务可能已经占用了你想要启动的服务所需的端口。例如，如果你想启动Apache，但另一个Web服务器（如Nginx）已经占用了80端口，Apache就无法启动。你可以使用
sudo netstat -tulnp | grep :80
（或相应的端口号）来检查端口占用情况。
排查故障就像侦探工作，从最明显的线索开始，逐步深入到系统底层。耐心和对日志的仔细分析是解决问题的关键。
