-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Management zh CN
本章节涵盖的主题是以最佳方式管理 ASF 进程。 尽管不是强制性的,这里还是包括了我们想要分享的提示、技巧和最佳实践,本章节主要面向系统管理员、第三方源的 ASF 打包者以及高级用户等。
在 generic
和 linux
两种包中,ASF 自带 [email protected]
文件,这是一份 systemd
的服务配置文件。 如果您要以服务形式运行 ASF,例如为了在系统启动时自动运行,那么正确的 systemd
服务就是最合适的实现方式,因此我们强烈推荐使用服务而不是通过 nohup
、screen
等方式手动管理。
首先,创建用来运行 ASF 的用户,假设它还不存在。 我们在此以 asf
用户为例,如果您决定用另一个用户,就需要在下面所有示例中把 asf
替换为您选择的用户名。 我们的服务不允许 ASF 以 root
用户运行,因为这被认为是错误实践。
su # 或者 sudo -i
useradd -m asf
接下来,解压 ASF 到 /home/asf/ArchiSteamFarm
目录。 目录结构对于我们的服务单元非常重要,它应该是您 $HOME
目录,也就是 /home/<user>
下的 ArchiSteamFarm
目录。 如果您的操作完全正确,则现在应该存在 /home/asf/ArchiSteamFarm/[email protected]
文件。 如果您正在使用 linux
版本,但文件不是在 Linux 环境中解压的,而是传输自 Windows 系统等情况,则您也需要执行 chmod +x /home/asf/ArchiSteamFarm/ArchiSteamFarm
设置权限。
我们接下来会用 root
用户操作,所以首先要通过 su
或 sudo -i
命令获取 Shell。
我们最好先确认一下我们的目录仍然属于 asf
用户,也就是执行一次 chown -hR asf:asf /home/asf/ArchiSteamFarm
命令。 因为如果您是以 root
用户下载或解压 zip 文件,权限可能是错误的。
Secondly, if you're using generic variant of ASF, you need to ensure dotnet
command is recognized and within one of the standard locations: /usr/local/bin
, /usr/bin
or /bin
. This is required for our systemd service which executes dotnet /path/to/ArchiSteamFarm.dll
command. Check if dotnet --info
works for you, if yes, type command -v dotnet
to find out where it's located. If you've used official installer, it should be in /usr/bin/dotnet
or one of the two other locations, which is alright. If it's in custom location such as /usr/share/dotnet/dotnet
, create a symlink for it using ln -s "$(command -v dotnet)" /usr/bin/dotnet
. Now command -v dotnet
should report /usr/bin/dotnet
, which will also make our systemd unit work. If you're using OS-specific variant, you don't need to do anything in this regard.
接下来,cd /etc/systemd/system
并执行 ln -s /home/asf/ArchiSteamFarm/ArchiSteamFarm\@.service .
,这会为服务定义文件创建一个符号链接,并将它注册给 systemd
。 使用符号链接是为了让 ASF 能在更新时自动更新您的 systemd
单元——取决于您的情况,您可能希望这样做,如果不希望,也可以直接使用 cp
命令复制文件并自行管理。
然后,确保 systemd
能够识别我们的服务:
systemctl status ArchiSteamFarm@asf
○ [email protected] - ArchiSteamFarm Service (on asf)
Loaded: loaded (/etc/systemd/system/[email protected]; disabled; vendor preset: enabled)
Active: inactive (dead)
Docs: https://github.com/JustArchiNET/ArchiSteamFarm/wiki
请特别注意我们在 @
后面声明的用户,在我们的示例中是 asf
。 我们的 systemd 服务单元期望您声明用户,因为这会影响 /home/<user>/ArchiSteamFarm
二进制文件的实际位置,以及 systemd 用于生成进程的实际用户。
如果 systemd 返回的输出与上面的情况类似,那么一切正常,我们马上就完成了。 现在剩下的操作就是以我们选择的用户实际启动服务:systemctl start ArchiSteamFarm@asf
。 等待一两秒钟,您就可以再次检查状态:
systemctl status ArchiSteamFarm@asf
● [email protected] - ArchiSteamFarm Service (on asf)
Loaded: loaded (/etc/systemd/system/[email protected]; disabled; vendor preset: enabled)
Active: active (running) since (...)
Docs: https://github.com/JustArchiNET/ArchiSteamFarm/wiki
Main PID: (...)
(...)
如果 systemd
的状态是 active (running)
,意味着一切正常,并且您可以通过执行命令 journalctl -r
等方式来验证 ASF 已经启动并运行,因为 ASF 默认会输出到控制台,并被 systemd
记录下来。 如果您满意现在的设置,就可以执行 systemctl enable ArchiSteamFarm@asf
命令,告诉 systemd
在系统启动时自动启动服务。 一切完成。
如果您想停止进程,只需要执行 systemctl stop ArchiSteamFarm@asf
。 类似地,如果您想要禁止 ASF 在系统启动时运行,就执行 systemctl disable ArchiSteamFarm@asf
,非常简单。
请注意,由于我们的 systemd
服务没有启用标准输入,您无法以常规方式通过控制台输入信息。 通过 systemd
运行与指定 Headless: true
设置运行是等效的。 如果您需要在登录时输入详细信息,或者需要更好地管理 ASF 进程,我们推荐您使用 ASF-ui,可以方便地管理您的 ASF。
systemd
服务允许提供额外的环境变量,例如您希望使用自定义的 --cryptkey
命令行参数,就需要指定 ASF_CRYPTKEY
环境变量。
若要提供自定义环境变量,则运行命令 mkdir -p /etc/asf
创建 /etc/asf
目录(如果不存在)。 我们建议运行 chmod 700 /etc/asf
,确保只有 root
用户有权限读取这些文件,因为其中可能包含 ASF_CRYPTKEY
等敏感属性。 然后,您可以编辑 /etc/asf/<user>
文件,其中 <user>
表示您运行服务的用户(在本例中是 asf
,即编辑 /etc/asf/asf
)。
此文件应该包含所有您要提供给进程的环境变量:
# 仅声明您实际需要的变量
ASF_CRYPTKEY="my_super_important_secret_cryptkey"
ASF_NETWORK_GROUP="my_network_group"
# 以及任何其他您要使用的变量
ASF 有自己的逻辑,验证自身是否以管理员用户(root
)运行。 只要环境配置正确,ASF 进程的任何操作都不需要 root 权限,因此以 root 用户运行算是一种错误实践。 这意味着在 Windows 上,ASF 永远不应该“以管理员身份运行”,而在 Unix 上,ASF 应该以专门的用户帐户运行,或者在桌面环境下使用您自己的帐户。
若要进一步了解我们为什么不鼓励以 root 权限运行 ASF,请阅读 SuperUser 或其他资料。 如果您仍然不相信,请想象一下,如果 ASF 在启动后自动执行 rm -rf /*
命令会发生什么。
这意味着您为 ASF 需要访问的文件配置了错误的权限。 您应该以 root
帐户登录(通过 su
或 sudo -i
命令),然后执行 chown -hR asf:asf /path/to/ASF
命令来修正权限,您需要将命令中的 asf:asf
替换为实际运行 ASF 的用户,并且将 /path/to/ASF
替换为 ASF 的实际路径。 如果您正在使用自定义的 --path
参数让 ASF 用户使用不同的目录,您还应该为这个路径再执行一次上述命令。
这样做之后,您应该不会再遇到任何类似“ASF 无法写入自己的文件”的问题,因为您刚刚将 ASF 所需文件的所有者修改为实际运行 ASF 的用户。
su # 或者 sudo -i
useradd -m asf
chown -hR asf:asf /path/to/ASF
su asf -c /path/to/ASF/ArchiSteamFarm # 或者 sudo -u asf /path/to/ASF/ArchiSteamFarm
这些步骤会手动启动 ASF,但使用我们上述的 systemd
服务会更容易。
自 V5.2.0.10 版本开始,ASF 不再阻止您这样做,而是仅仅显示一条简短的警告。 但是,如果有一天本程序的漏洞导致您的整个操作系统崩溃掉,并且丢失所有数据——不要说我们没有警告过您。
ASF 兼容在同一台机器上运行多个进程实例。 实例可以是完全独立的,或是派生于同一个二进制文件(如果您需要它们在不同路径下运行,可以使用 --path
命令行参数)。
请注意,在通常情况下,当使用同一份二进制文件运行不同实例时应该在所有实例的配置文件内禁用自动更新,因为它们之间不会同步与自动更新有关的信息。 如果您仍希望启用自动更新,我们建议您使用独立的实例,但只要您能确保所有其他 ASF 实例已关闭,自动更新就仍然可以正常工作。
ASF 会尽全力减少操作系统层面的与其他 ASF 实例的跨进程通信。 这包括 ASF 会读取其他实例的配置文件目录,并且共享由 *LimiterDelay
全局配置属性配置的进程级限制,确保运行多个 ASF 实例不会导致频率限制问题。 在技术方面,所有平台都使用我们专门的 ASF 自定义机制,在临时目录内创建基于文件的锁,Windows 上的临时目录为 C:\Users\<您的用户名>\AppData\Local\Temp\ASF
,在 Unix 上则是 /tmp/ASF
。
运行多个 ASF 实例不需要它们共享相同的 *LimiterDelay
属性,它们可以设置不同的值,因为每个 ASF 都会在获得锁之后将自己配置的延迟添加到释放时间。 如果配置的 *LimiterDelay
设置为 0
,ASF 实例将完全跳过等待其他实例释放资源的锁(它们之间可能仍然会维护一个共享锁)。 当设置为其他任何值时,ASF 将会与其他实例同步此值,并等待自己获得锁,然后会在预先配置的延迟时间之后释放锁,使其他实例继续工作。
ASF 在决定共享范围时会考虑到 WebProxy
设置,即使用不同 WebProxy
的 ASF 实例之间不会采用同一个限制。 实现此功能是为了让 WebProxy
设置不会导致过大的操作延迟,符合使用不同网络接口的预期。 对于大多数情况,这应该足够了,然而,如果您的方案使用自定义的机制,例如使用其他方式手动路由请求,您可以通过 --network-group
命令行参数指定网络组,使您指定 ASF 需要与同一个组内的实例同步。 请注意,设置自定义网络组选项后,ASF 就不再根据 WebProxy
判断所需的组,因为此时由您自己管理分组。
如果您希望利用上文所述的 systemd 服务
实现 ASF 多实例,也非常简单,只需要在我们声明 ArchiSteamFarm@
服务时使用另一个用户,随后的步骤都完全相同。 这与分别运行多个不同 ASF 二进制文件是等价的,所以它们也可以正常自动更新,而操作互不干扰。