Linux 服务管理核心是让服务运行并按需自动启停，systemd 为统一入口；常用 systemctl 命令包括 status、start/stop/restart、enable/disable 及 daemon-reload；自定义。service 文件需注意 Type、Restart 等关键配置；日志用 journalctl 定位问题；进阶支持 Socket 激活、资源限制与依赖编排。
Linux 服务管理核心就两件事：让服务跑起来，让它按需自动启停。systemd 是现代 Linux 的统一入口，搞懂它，90% 的服务问题都不用慌。
systemctl 命令：服务控制的日常操作
这是你每天打交道最多的命令，记住几个高频组合就够了：
- 查看状态：
systemctl status nginx—— 看是否运行、最近日志、启动失败原因 - 启停重启：
systemctl start/stop/restart nginx—— 操作立即生效，但不持久 - 开机自启：
systemctl enable nginx—— 创建软链接到/etc/systemd/system/multi-user.target.wants/，下次开机自动拉起 - 禁用自启：
systemctl disable nginx—— 删除软链接，不影响当前运行 - 重载配置 ：
systemctl daemon-reload—— 修改了.service文件后必须执行，否则 systemd 不认新配置
服务单元文件（.service）：自己写服务的入门钥匙
很多程序没自带 systemd 服务，或者你想定制启动方式（比如加 环境变量 、改用户、设依赖），就得手写.service 文件。
位置一般在/etc/systemd/system/xxx.service（系统级）或/usr/lib/systemd/system/（软件包自带）。
一个最小可用模板长这样：
[Unit] Description=My Custom App After=network.target [Service] Type=simple User=appuser WorkingDirectory=/opt/myapp ExecStart=/opt/myapp/start.sh Restart=on-failure RestartSec=5 [Install] WantedBy=multi-user.target
关键点：
- Type选对很重要：simple（进程一启动就算成功）、forking（主进程 fork 子进程后退出）、notify（需程序主动发通知）
- Restart策略别乱设：生产环境慎用
always，on-failure更安全 - EnvironmentFile可加载环境变量文件，比硬写在
ExecStart里更清晰
日志与排错：出问题时怎么快速定位
别急着翻应用自己的 log，先看 systemd 托管层的日志：
-
journalctl -u nginx—— 查指定服务的所有日志 -
journalctl -u nginx -f—— 实时跟踪，类似tail -f -
journalctl -u nginx --since "2 hours ago"—— 按时间过滤，查历史异常 -
journalctl -u nginx -n 50—— 只看最近 50 行 - 如果服务启动失败，
systemctl status末尾通常会提示“Process exited with code……”或“Failed with result ‘exit-code’”，再配合journalctl就能锁定具体哪一行崩了
进阶技巧：按需激活、资源限制、依赖编排
systemd 不只是“开 / 关”，还能做轻量级服务治理：
- Socket 激活 ：用
.socket文件监听 端口，真正有连接进来才拉起服务（省资源，适合低频服务） - CPU/Memory 限制 ：在
[Service]里加MemoryLimit=512M或CPUQuota=50%，防止单个服务吃光资源 - 依赖关系：
After=redis.service+Requires=redis.service表示“先启redis，再启我；redis 挂了我也得停” - 定时触发 ：配合
.timer单元，替代 crontab 做更精确的周期任务（支持日历语法、随机延迟、运行完才计下一次）
基本上就这些。不用背所有参数，先掌握 status/start/enable/journalctl 四件套，再根据实际需求慢慢扩展。systemd 设计逻辑清晰，规则明确，不复杂但容易忽略细节。
