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设计逻辑清晰，规则明确，不复杂但容易忽略细节。