在Linux系统的日常运维中，许多用户都曾遇到过这样的困扰：一个重要的后台任务——比如文件同步、定时备份或网页监控脚本——只要用户注销或关闭终端，就会随之终止。传统解决方案如nohup、screen或tmux虽然能在一定程度上缓解问题，但它们终究是“权宜之计”，无法彻底解决用户级服务在系统启动后自动运行、持续提供服务的需求。而Systemd作为现代Linux系统的核心服务管理器，其提供的linger（持久驻留）功能，正是为了解决这一痛点而生。
何为Systemd Linger？
Systemd Linger（持久驻留）是systemd为用户级服务（user service）提供的一项特殊能力。默认情况下，用户通过systemctl --user管理的服务只能在该用户登录状态下运行——一旦用户退出登录，该用户的所有用户级systemd进程都将被终止。而启用linger后，无论用户是否登录，其用户级服务都会像系统级服务一样持续运行，甚至在系统启动后无需登录即可自动启动。
这项功能的名称“linger”意为“徘徊、逗留”，形象地描述了用户服务在用户注销后依然“赖着不走”的特性。它本质上是通过让systemd在系统初始化阶段就启动一个用户服务管理器（user@.service实例），从而脱离用户登录会话的束缚。
为何需要Linger？
在实际生产环境中，linger的应用场景极为广泛。以个人开发者和服务器管理员为例：
- 持续运行的开发工具：如Jupyter Notebook、代码质量监控、文件同步（Nextcloud客户端）等，需要长期稳定运行。
- 定时任务替代：许多用户习惯用
systemd --user timer替代crontab，但这些定时器在用户注销后会失效，linger解决了这一问题。 - 容器与虚拟机管理：使用Podman等无根容器时，用户级服务需要在后台长期运行容器实例。
- 代理与隧道服务：如SSH隧道、VPN客户端等网络服务，往往需要持续存活。
在高性能计算（HPC）集群、共享服务器或家用NAS场景中，启用linger可以让多个用户各自管理自己的后台服务而互不影响，同时无需保持SSH会话不断开。
如何启用Linger？
启用或禁用某个用户的linger状态非常简单，仅需一行命令，且需要root权限（或通过loginctl的polkit授权）：
# 启用linger（针对当前用户）
sudo loginctl enable-linger $(whoami)
# 或者指定用户
sudo loginctl enable-linger username
# 禁用linger
sudo loginctl disable-linger username
# 查看所有启用linger的用户
loginctl list-users
启用后，用户即可创建并启动自己的用户级服务。通常将服务单元文件放置在~/.config/systemd/user/目录下，然后执行：
systemctl --user daemon-reload
systemctl --user enable --now my-service.service
此后，即使该用户完全注销、关闭所有终端，my-service也会在后台持续运行。系统重启后，该服务也会随系统启动而自动启动（前提是linger已启用）。
注意事项与安全性
尽管linger功能强大，但使用时也需要关注几个方面：
- 资源消耗：每个启用linger的用户都会创建独立的systemd用户实例，占用一定内存和进程资源。在拥有大量用户的共享系统上需谨慎。
- 安全性：用户级服务以对应用户身份运行，具有该用户的所有权限。如果启用linger的用户服务存在漏洞，可能造成数据泄露或权限提升。建议仅对信任的用户启用。
- 日志管理：用户级服务的日志默认存储在
~/.local/state/xdg/journal/或通过journalctl --user查看，注意日志轮转和磁盘空间。 - 与桌面环境的交互：在登录桌面环境时，用户级服务可能会与图形会话产生冲突。例如某些需要环境变量的服务在无登录状态下可能无法正常工作，需通过
systemctl --user import-environment等方式传递环境变量。
未来展望
随着无根容器、用户级服务网格等技术的兴起，Systemd Linger正变得越来越重要。它不仅赋予了普通用户“系统管理员”般的服务管理能力，还推动了Linux系统从“单用户多任务”向“多用户长期服务”模式的演进。对于追求高效运维和自动化部署的开发者来说，掌握Linger已是必备技能。
对于已经习惯用screen或tmux维持后台任务的用户，不妨尝试将关键服务迁移到systemd用户单元并开启linger——你会发现，原来稳定可靠的后台服务，可以如此得心应手。