自动启动与后台任务：选择入口，避免重复进程

希望登录后文件管理器准备好，同步工具也在后台运行。把两个命令写进所有启动文件，可能导致重复窗口、第二个服务抢端口，或任务在注销后意外继续。先选择谁负责管理进程。

本文依据固定 4.0.0.alpha 的 Lua 辅助函数。确认个人主入口加载 ~/.config/hypr/autostart.lua。下面 Syncthing 是可选的上游例子，不是声称每个 Omarchy 都安装了它。实验前记录已有应用和服务状态。

1. 先选择进程生命周期

Hyprland 会话启动
  → Omarchy 默认启动项 + 个人 autostart.lua
  → o.launch_on_start → uwsm-app → 会话应用
systemd 用户管理器
  → 已启用的用户单元 → 被监督的后台服务
桌面自启动 / 应用偏好 / hooks
  → 其他可能的启动管理者

需求	首选	原因
进入桌面后打开普通图形应用	个人 autostart.lua	跟随图形会话
已安装守护进程提供服务单元	软件包的用户单元	停止、重启和日志入口清楚
定期执行任务	合适的调度器/计时器	登录不是周期调度
登录前运行全机器服务	职责合适的系统单元	用户与权限不同，不在本练习范围

o.launch_on_start 注册 hyprland.start 回调，再使用 uwsm-app。它不是每次配置重载都反复执行的普通 exec；也不会消除另一个独立启动入口，或自动重启崩溃的应用。辅助函数实现

用户服务不一定属于图形会话。生命周期取决于 target、依赖、同用户其他登录和 linger。启用到 default.target 的服务可能比桌面活得久。Omarchy 自己的睡眠锁屏服务明确有 PartOf=graphical-session.target，还等待会话环境；不能把这些性质套给所有用户单元。Omarchy 服务示例

2. 添加前盘点已有启动入口

文件管理器例子：

command -v nautilus
grep -n 'nautilus' ~/.config/hypr/autostart.lua
grep -R -n 'nautilus' ~/.config/autostart /etc/xdg/autostart 2>/dev/null
systemctl --user list-unit-files --type=service

查看匹配条目的含义，不只判断字符串有没有。注释不是启用项；desktop 自启动还有 Hidden、OnlyShowIn 等条件。应用自己可能有“登录时启动”，post-boot hook 也可能运行它。

Omarchy 默认已经启动 Shell、显示器监视器、自动挂载工具。再加一份不属于个人自启动定制。看起来是桌面组成部分的程序，先查默认项。默认启动源码

记录目标是否已运行、哪个入口管理它、练习后删除什么。守护进程先看提供的单元。同一个实例/配置只保留一个管理者。

3. 案例：进入桌面时打开 Files

先手动启动，确认文件管理器正常。用新名称备份现有个人文件：

cp -i ~/.config/hypr/autostart.lua ~/.config/hypr/autostart.lua.before-autostart

通过 Setup → Config → hypr/autostart.lua 只增加：

o.launch_on_start("nautilus")

保留其他内容。不要为了“后台运行”随手加 &，辅助函数已经使用会话启动器。应用需要参数时先独立测试准确命令，Shell 引号、应用参数和 Lua 引号仍是不同层。

保存退出。重载不是登录测试。 不能靠重载证明 start 事件动作执行。方便时先保存全部任务、正常注销并重新登录，检查 Files 可用、普通文件管理器按键仍正常，以及没有第二个独立启动入口。

Nautilus 可以复用运行中的实例，窗口数量不能直接表示启动命令次数。有效结果是登录时出现预期应用，没有重复动作、错误或第二条管理路径。工作区位置不合适时，单独验证窗口规则，不要靠启动顺序保证放置。

4. 终端能运行，登录却失败时

交互 Shell 别名、函数不自动变成独立程序。登录启动的工作目录、搜索路径与环境，可能不同于终端。

现象	检查什么
找不到命令	command -v、真实可执行路径，不是别名
相对路径文件缺失	使用确认过的绝对路径或明确工作目录
GUI 无法连接	是否在图形会话内，有正确显示环境
启动后立即退出	手动运行相同命令，读错误
只看到重载不生效	start 回调需要新的合成器会话
工作区不对	真实 class 与启动放置规则

使用观察到的 PID 检查相关进程：

ps -o pid,ppid,args -p 12345

替换 12345，它不是实际目标。用户服务查相关日志和配置环境，有限地查看管理器：

systemctl --user show-environment | grep -E '^(WAYLAND_DISPLAY|DISPLAY|PATH)='

不要公开完整环境，里面可能有敏感值。修改 Shell export 不会追溯改变已运行服务的环境。导入变量或重启桌面组件前，先确认真正的管理者。

5. 案例：可选同步守护进程使用自带服务

如果已经安装 Syncthing，想让它在后台被管理，先检查用户单元，不要同时在 Lua 里加 syncthing：

command -v syncthing
systemctl --user cat syncthing.service
systemctl --user is-enabled syncthing.service
systemctl --user is-active syncthing.service

记录原先启用与运行状态。单元缺失时停止这个分支，查所安装包的说明，不凭空猜一个类似名称，也不把系统单元当用户单元。包可能同时提供系统管理器的 syncthing@USER.service 与用户管理器的 syncthing.service，混用会产生两个管理者。

确认目标用户单元存在、没有其他入口运行相同配置后，先只启动本次运行：

systemctl --user start syncthing.service
systemctl --user status syncthing.service --no-pager
journalctl --user -u syncthing.service -n 50 --no-pager

然后看应用本地界面，用可丢弃文件夹测试同步。Active 表示进程被监督，不代表同步成功。本文不配置对端，也不要求改变真实文件夹。应用正常后，再启用以后自动启动：

systemctl --user enable syncthing.service

start 控制现在，enable 创建未来启动链接，两者都不同于让浏览器登录时打开。不带 --user 的系统单元命令面对另一个管理器。Syncthing 上游自启动说明

不要为了登录应用启用 linger，它会改变用户管理器及已启用服务何时运行，包括登录前。同用户还有其他登录时服务仍在，也不能说明桌面自己的应用清理失败。

6. 重复进程：查管理者，而不是只数个数

观察	下一步调查
每次登录出现两个窗口	应用偏好叠加 Lua/desktop 项
服务提示端口已占用	另一守护进程入口或独立配置
杀掉又回来	服务重启策略或监督启动器
同应用有多个进程	辅助、渲染、监督进程树可能正常
开终端后服务才工作	路径、环境或手动第二次启动

用状态和进程树找到父进程。广泛 pkill 不是持久修复：它不删除下一次启动入口，还会打断真实任务。移除/禁用重复管理者，再用应用支持的方法停止对应进程。受监督服务用已核实单元的 systemctl --user stop。

从 Lua 转到服务时，删旧行、正常停止旧实例、确认资源释放，再启动服务。保留配置和数据，更换启动管理者不需要重装应用。

7. 完整撤销实验

Files 只删本次新增的 o.launch_on_start。保存影响未来启动，当前测试窗口按需要正常关闭。恢复备份前比较后续改动。下次登录确认不再自动打开，而手动快捷键正常。

可选服务恢复记录状态。原先禁用且未运行时：

systemctl --user disable --now syncthing.service

原先已启用或运行，就不要盲目执行，恢复练习真正改变的部分。单独 disable 不停止当前进程，单独 stop 不取消未来启动，都不会删除同步数据或应用配置。

保留简短记录：程序、启动管理者、配置路径、预期生命周期、日志入口和撤销方法。以后登录异常会更容易查。继续看配置维护与长任务保持唤醒。本文核对了源码，未在真实 Omarchy 系统测试。