Management zh CN
This section covers subjects related to managing the ASF process in optimal way. While not strictly mandatory for usage, it includes bunch of tips, tricks and good practices that we'd like to share, especially for system administrators, people packaging the ASF for usage in third-party repositories, as well as advanced users and alike.
In generic and linux variants, ASF comes with [email protected] file, which is a configuration file of the service for systemd. If you'd like to run ASF as a service, for example in order to launch it automatically after startup of your machine, then a proper systemd service is arguably the best way to do it, therefore we highly recommend it instead of managing it on your own through nohup, screen or alike.
Firstly, create the account for the user you want to run ASF under, assuming it doesn't exist yet. We'll use asf user for this example, if you decided to use a different one, you'll need to substitute asf user in all of our examples below with your selected one. Our service does not allow you to run ASF as root, since it's considered a bad practice.
su # or sudo -i
adduser asfNext, unpack ASF to /home/asf/ArchiSteamFarm folder. The folder structure is important for our service unit, it should be ArchiSteamFarm folder in your $HOME, so /home/<user>. If you did everything correctly, there will be /home/asf/ArchiSteamFarm/[email protected] file existing.
We'll do all below actions as root, so get to its shell with su or sudo -i.
Firstly it's a good idea to ensure that our folder still belongs to our asf user, chown -hR asf:asf /home/asf/ArchiSteamFarm executed once will do it. The permissions could be wrong e.g. if you've downloaded and/or unpacked the zip file as root.
Next, cd /etc/systemd/system and execute ln -s /home/asf/ArchiSteamFarm/ArchiSteamFarm\@.service ., this will create a symbolic link to our service declaration and register it in systemd.
Afterwards, ensure that systemd recognizes our service:
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
Pay special attention to the user we declare after @, it's asf in our case. Our systemd service unit expects from you to declare the user, as it influences the exact place of the binary /home/<user>/ArchiSteamFarm, as well as the actual user systemd will spawn the process as.
If systemd returned output similar to above, everything is in order, and we're almost done. Now all that is left is actually starting our service as our chosen user: systemctl start ArchiSteamFarm@asf. Wait a second or two, and you can check the status again:
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: (...)
(...)
If systemd states active (running), it means everything went well, and you can verify that ASF process should be up and running, for example with tail -f -n 100 /var/log/syslog, as ASF by default also reports its console output to syslog. If you're satisfied with the setup you have right now, you can tell systemd to automatically start your service during boot, by executing systemctl enable ArchiSteamFarm@asf command. That's all.
If by any chance you'd like to stop the process, simply execute systemctl stop ArchiSteamFarm@asf. Likewise, if you want to disable ASF from being started automatically on boot, systemctl disable ArchiSteamFarm@asf will do that for you, it's very simple.
Please note that, as there is no standard input enabled for our systemd service, you won't be able to input your details through the console in usual way. Running through systemd is equivalent to specifying Headless: true setting and comes with all its implications. Fortunately for you, it's very easy to manage your ASF through ASF-ui, which we recommend in case you need to supply additional details during login or otherwise manage your ASF process further.
It's possible to supply additional environment variables to our systemd service, which you'll be interested in doing in case you want to for example use a custom --cryptkey command-line argument, therefore specifying ASF_CRYPTKEY environment variable.
In order to provide custom environment variables, create /etc/asf folder (in case it doesn't exist), mkdir -p /etc/asf, then write to a /etc/asf/<user> file, where <user> is the user you're running the service under (asf in our example above, so /etc/asf/asf).
The file should contain all environment variables that you'd like to provide to the process:
# Declare only those that you actually need
ASF_CRYPTKEY="my_super_important_secret_cryptkey"
ASF_NETWORK_GROUP="my_network_group"
# And any other ones you're interested inASF includes its own validation whether the process is being run as administrator (root) or not. Running as root is not required for any kind of operation done by the ASF process, assuming properly configured environment it's operating in, and therefore should be regarded as a bad practice. This means that on Windows, ASF should never be executed with "run as administrator" setting, and on Unix ASF should have a dedicated user account for itself, or re-use your own in case of a desktop system.
For further elaboration on why we discourage running ASF as root, refer to superuser and other resources. If you're still not convinced, ask yourself what would happen to your machine if ASF process executed rm -rf --no-preserve-root / command right after its launch.
This means that you have wrongly configured permissions of the files ASF is trying to access. You should login as root account (either with su or sudo -i) and then correct the permissions by issuing chown -hR asf:asf /path/to/ASF command, substituting asf:asf with the user that you'll run ASF under, and /path/to/ASF accordingly. If by any chance you're using custom --path telling ASF user to use the different directory, you should execute the same command again for that path as well.
After doing that, you should no longer get any kind of issue related to ASF not being able to write over its own files, as you've just changed the owner of everything ASF is interested in to the user the ASF process will actually run under.
su # or sudo -i
adduser asf
chown -hR asf:asf /path/to/ASF
su asf -c /path/to/ASF/ArchiSteamFarm # or sudo -u asf /path/to/ASF/ArchiSteamFarmThat would be doing it manually, it's much easier to use our systemd service explained above.
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 判断所需的组，因为此时由您自己管理分组。
