自动启动中继

oar start 会让中继在后台运行，直到你停止它或机器重启。要让中继自行恢复，请安装自启动：oar service install 0.9.9 新增 会在 Linux 和 Windows 上进行设置。0.9.15 新增 oar autostart 可以选择 Windows 的任一模式：登录时或开机时；在 Windows 上，oar setup 也会询问这一项。之后你就不需要开着终端，在无头主机上也不需要登录。

该服务运行与 oar start 相同的中继：相同的配置、相同的数据文件夹和相同的日志文件夹。你的对话不会有任何变化。0.9.14 新增 在 Windows 上，两种自启动模式也都如此；0.9.14 之前，它们把数据保存在已安装的包内（参见 Windows 条目的数据文件夹）。

命令 #

oar service install
oar service status
oar service remove

当你没有给出子命令时，默认是 oar service status。这些命令用于全局安装；在 git 检出中，它们会说明这一点并什么都不做。单独输入 oar 会打开一个菜单，其中有对应此事的条目 Install or remove the service（安装或移除服务）。oar setup --start 和 macOS、Linux 安装器会在存在 systemd 用户会话的地方为你安装 Linux 服务。

oar service install 需要一份配置：请先运行 oar setup。

0.9.15 新增 oar autostart 直接指定模式，而不是服务：

oar autostart signin    # Windows: at sign-in
oar autostart boot      # Windows: at boot, before anyone signs in
oar autostart off
oar autostart status    # the default when you give no word

在 Windows 上，它是用于两种模式的命令，规则与 Settings（设置）中的 Autostart (Windows)（自启动，Windows）控件相同。在 Linux 上它等价于 oar service：signin 和 boot 都运行 oar service install，off 运行 oar service remove，status 运行 oar service status。在 macOS 上它会显示 Autostart is not supported on macOS yet. Start the relay with: oar start。在 git 检出中，它会说明它用于全局安装。signin 和 boot 需要配置；off 和 status 不需要。

Linux：systemd 用户服务 #

0.9.8 新增

该服务名为 oar。oar service install 会把它的单元文件写入 ~/.config/systemd/user/oar.service，启用它并启动它。它还会为你的用户运行 loginctl enable-linger。lingering 能在无人登录时保持你的用户服务运行，因此中继在重启后会恢复，并在你退出登录后继续运行。这里没有任何操作需要 sudo。如果无法启用 lingering，命令会说明这一点，并给出需要你自行运行的那一行，因为没有它，中继会在你退出登录时停止：

loginctl enable-linger "$USER"

该单元用运行该命令的 Node.js 启动中继，并在崩溃后重启它（Restart=on-failure，5 秒后）。0.9.14 新增 它不会重启以退出码 78 停止的中继（RestartPreventExitStatus=78）：当中继无法在其数据上运行时，例如另一个中继持有它的锁时，它会使用该退出码（参见无法正常工作时）。早期版本写入的单元缺少这一行，直到你再次运行 oar service install。它带有运行 oar service install 的 shell 的 PATH，再加上 ~/.local/bin 和那个 Node.js 的文件夹，因为否则 systemd 用户服务启动时只有一个最简的 PATH。中继的会话靠它找到提供商 CLI 和 node。你的 PATH 改变后，请再次运行 oar service install，然后运行 oar restart：install 会重写单元，但不会重启已经运行的服务。

如果你手动启动的中继正在运行，install 会先停止它，好让服务接管端口。如果那个中继正忙、无法立即停止，服务会被安装，并在下次登录时、或在中继停止后你运行 oar start 时接管。

start、stop 和 restart #

安装了服务后，oar start、oar stop 和 oar restart 都会经过 systemd。

状态与日志 #

systemctl --user status oar

会显示服务是否在运行。该单元不重定向中继的输出，因此 systemd 会把它保存在 journal 中：用 journalctl --user -u oar 读取。

该单元还会把中继的日志文件夹设为 OAR 状态文件夹中的 logs 文件夹（默认为 ~/.oar/logs）。中继会在那里把它控制台的一份副本保存在 relay-console.log，每个会话 worker 会写入一个 worker-<session>.log。oar doctor 会打印它们所在的状态文件夹。

Windows #

0.9.2 新增

Windows 有两种自启动模式。两者都用相同的配置运行相同的中继。

该控件位于 ⚙️ Settings → General（设置 → 常规）中，标签为 Autostart (Windows)。它只在 Windows 中继上显示，并有三个选项：

Off
At sign-in — visible terminal after you log on
At system startup — headless, no logon needed

0.9.15 新增 在 Windows 的终端中，oar setup 会把模式作为最后一个问题来询问，以当前生效的模式作为默认值：

Autostart: 1 = at sign-in, 2 = at boot, before anyone signs in (one administrator prompt), 3 = off [3]:

按 Enter 保持模式不变。oar setup --autostart signin|boot|off 可以在不提问的情况下设置它。如果无法读取开机任务，setup 不会提问。当切换没有成功时，setup 仍会写入配置，显示 The config is written; the autostart step did not go through (see above). 并以退出码 1 退出。

每次切换都会移除另一种模式的条目，但只移除 OAR 生成的条目（参见 OAR 未创建的条目）。

登录时 #

选择 At sign-in，或运行 oar autostart signin 或 oar service install。它们都会写入相同的条目，即你 Startup 文件夹中的 oar-web-relay.cmd，因此命令和控件保持一致。oar autostart off、oar service remove 或 Off（关闭）会删除它。它们都不会立刻启动中继：中继会在你下次登录时启动，或现在用 oar start 启动。从开机模式切换到登录时需要移除开机任务的那次管理员确认。

开机时 #

选择 At system startup，或运行 oar autostart boot。注册开机任务需要管理员权限，而中继运行时不具备这些权限，因此 Windows 会请求一次管理员确认；提权部分只是 schtasks 调用。该提示只出现在这台电脑本机的桌面上。oar autostart 会打印 Confirm the administrator prompt to register the boot task … 并等待。从另一台设备的浏览器上，Settings 会显示 Confirm the admin prompt on the PC…（请在电脑上确认管理员提示…）。两者都会等待最多两分钟；到那时无人应答的提示算作失败。该任务以你的用户身份运行，不存储密码。本地文件和隧道照常工作；该任务没有访问网络共享的凭据。

切换回 Off 或 At sign-in（oar autostart off、oar autostart signin）需要同样的确认来移除任务。0.9.15 新增 只有在提示确认且任务消失后，控件才会开启登录条目。

0.9.15 新增 拒绝提示不会做任何改动：Nothing changed: the administrator prompt was declined. 先前的模式保持不变，也不会留下任何文件。如果提示后切换本身失败，它会从副本（OAR 文件夹 %APPDATA%\oar 中的 <task>.task.xml.bak）恢复它删除的任务，保留副本并报告失败。如果提示已确认但之后无法读回任务，OAR 会说明这一点，指出副本，并且不撤销任何操作。在网页界面中，失败时会显示问题所在，以及一条可改为在提权的 PowerShell 中运行的命令。

0.9.15 新增 当你的用户配置文件夹路径包含空格、撇号或非 ASCII 字符时（例如 C:\Users\Jürgen），开机模式也能正常开启和关闭。早期版本在这些情况下会失败，或把 OAR 自己的任务当作手动创建的任务。

开机任务会启动一个 OAR 生成的启动脚本，即 OAR 文件夹中的 oar-web-relay-launcher.cmd。0.9.11 新增 该启动脚本会把 Node.js 的文件夹加到 PATH 的末尾。中继通过完整路径在自己的 Node.js 上启动它的 worker，因此即使任务的 PATH 中没有 node，它们也能启动（智能体进程）。

当生成的启动脚本缺失或来自早期版本时，Settings 会指出差异而不是报告失败，再次选择 At system startup（或 oar autostart boot）会重新生成它。当某项设置的更改失败时，Settings 会显示中继给出的原因。如果开机任务旁边还存在一个登录条目，该设置会警告它可能让中继启动两次；再次选择 At system startup 可以清理掉它。

oar service 只会报告这种模式。当开机任务就位时，oar service install 和 oar service remove 会拒绝并指引你使用 oar autostart signin|off 或 Settings；oar service status 会打印 on, at boot (scheduled task)。

状态 0.9.15 新增 #

oar autostart status 会打印模式，然后打印每个存在的条目，以及它是否为 OAR 生成：

[oar] Autostart: at boot, before anyone signs in (scheduled task)
[oar]   scheduled task \oar-relay (generated by OAR)
[oar]   C:\Users\dev\AppData\Roaming\oar\oar-web-relay-launcher.cmd (generated by OAR)

模式是 at sign-in (Startup folder)、at boot, before anyone signs in (scheduled task)、off，或 unknown, the boot task could not be read (<reason>)。手动创建的条目显示为 <path> (hand-made)，另一个 OAR 安装留下的条目显示为 <path> (hand-made: it starts the OAR install in <folder>)。当存在这样一个条目时，最后一行会说明如何替换它。

OAR 未创建的条目 0.9.15 新增 #

无论在网页界面还是在 oar autostart 中，OAR 只改动与某个 OAR 版本为本安装生成时完全一致的自启动条目。其他任何条目都是 hand-made，即手动创建的条目，绝不会被删除或覆写：

• 你编辑过的 Startup 条目，或属于另一个 OAR 安装或配置的条目；
• 在账户、运行级别、唯一的操作、唯一的开机触发器或其设置上与 OAR 注册的任务不同的开机任务；
• 你编辑过的启动脚本；
• 别人创建的名叫 oar-relay 的任务，以及更名前的开机任务。

当一个手动创建的条目会留在新模式旁边、或被新模式替换时，切换不会做任何改动，并指出该条目：

[oar] Nothing changed: OAR does not delete or overwrite an autostart entry it did not make. Remove it yourself, or replace it keeping a copy: oar autostart boot --replace.
[oar] Left as it is: C:\Users\dev\AppData\Roaming\oar\oar-web-relay-launcher.cmd (hand-made).

网页界面会显示相同的消息。属于你所选模式的手动创建条目会继续为该模式服务并保留（Left as it is: …）。要用 OAR 自己的条目替换手动创建的条目，请带 --replace 运行切换：

oar autostart boot --replace

它会先为每个条目保留一份副本，作为 OAR 文件夹（%APPDATA%\oar）中的 <name>.bak：启动脚本的副本就在它旁边，任务的导出 XML 作为 <task>.task.xml.bak（schtasks /create /xml 可以取回它），Startup 条目的副本也在那里，因为 Windows 会在登录时打开留在 Startup 文件夹中的副本。早期的副本绝不会被覆写：下一个是 .bak-2。除了 --replace，没有任何东西会替换手动创建的条目。

OAR 无法读取的开机任务，例如存储了另一个账户密码并回答 Access is denied（拒绝访问）的任务，绝不会被当作缺失。状态会显示 unknown, the boot task could not be read (<reason>)，而每次切换（包括 --replace）都会以 Nothing changed: the boot task could not be read (<reason>). 停止。

等待 TEMP 和数据驱动器 0.9.14 新增 #

两种模式在启动中继前都会等待：总共最多 5 分钟，等待 %TEMP% 文件夹和数据文件夹所在的驱动器，例如 RAM 盘或启动脚本稍后才挂载的驱动器。0.9.14 之前，开机启动脚本只为 %TEMP% 等待 2 分钟，登录条目则完全不等待。网络共享上的数据文件夹不会被等待。用引号设置的 TEMP 或 TMP（"D:\My Temp"），或指向不存在的文件夹的变量，会为中继修正：去掉引号，或使用你自己的临时文件夹。

当等待超时时，会有一行指出仍缺少什么，而中继仍会启动：

[<date> <time>] Still missing after 300 s: data drive "R:\"; starting the relay anyway.

该行会写入开机启动脚本旁边的 oar-web-relay-launcher.log，或 OAR 文件夹（%APPDATA%\oar）中登录条目使用的 oar-web-relay.log。如果数据文件夹仍无法创建，中继随后会停止，输出一行指出该文件夹的信息并以退出码 78 退出，而不是输出错误堆栈。

Windows 条目的数据文件夹 0.9.14 新增 #

两种条目都在 oar start 使用的配置、数据文件夹和日志文件夹上启动中继：全局安装上是 %APPDATA%\oar\config.json、%APPDATA%\oar\data 和 %APPDATA%\oar\logs。0.9.14 之前，它们只设置配置文件，因此它们启动的中继把数据库、上传文件和日志保存在已安装包内的 server\data、server\uploads 和 server\logs 中：对话与 oar start 启动的中继不是同一批，而且下一次更新时就会丢失。从这些版本更新时，请按升级说明操作。

中继会在更新后的第一次启动时，自行把 OAR 生成的条目或启动脚本（0.9.0 起，包括更名前的 copilot-remote-web-relay.cmd）更新到最新，无需管理员确认。你编辑过的条目、指向另一个配置文件的条目，以及使用自有数据文件夹启动的中继的条目，都不会被改动。0.9.15 新增 它们算作手动创建：oar autostart <mode> --replace 会替换它们并保留副本（参见 OAR 未创建的条目）。在它启动的中继仍在运行时重写启动脚本是安全的。这些启动脚本会把控制台切换到 UTF-8，因此名称中含有非 ASCII 字符的用户文件夹可以保持其路径完好。

macOS #

该服务在 macOS 上尚不可用。oar service 会说明这一点，并指出 oar start。重启后，运行 oar start 再次启动中继。安装器会在后台启动它。

WSL #

Linux 服务需要一个 systemd 用户会话。WSL 发行版只有在开启了 systemd 时才有。如果没有开启，oar service install 会带着提示停止：在 /etc/wsl.conf 的 [boot] 下设置 systemd=true，然后用 wsl --terminate <distro> 从 Windows 重启发行版。在那之前请使用 oar start。对于容器或任何没有 systemd 用户会话的 Linux，情况相同。

更新 #

oar update 会请求正在运行的中继自我重启，它会在队列空闲后这样做。有了 Linux 服务也是如此：更新不经过 systemd，因此不会打断轮次。参见重启与恢复。服务和自启动条目启动的是已安装的包，因此在那次重启后它们会运行新版本。更新包绝不会触及配置或数据。0.9.14 新增 唯一的例外是由 Windows 自启动的中继更新到 0.9.14，因为它的数据在包内：参见升级说明。

按平台 #

无法正常工作时 #

更多启动问题见首次运行。如果还没有安装 OAR，参见安装。