Management ja JP
このセクションでは、ASFプロセスの最適な管理に関連する科目について説明します。 使用には厳密に必須ではありませんが、私たちが共有したいヒント、トリック、グッドプラクティスがたくさん含まれています。 特にシステム管理者の場合は、サードパーティのリポジトリや上級ユーザーなどで使用するためにASFをパッケージ化しています。
generic および linux バリアントでは、ASF に ArchiSteamFarm@.service ファイルが付属しています。これは systemd 用サービスの設定ファイルです。 マシンの起動後に ASF を自動起動したい場合など、ASF をサービスとして実行したいのであれば、適切な systemd サービスを使うのが最善の方法と言えます。そのため、nohup、screen などを使って自分で管理するよりも、この方法を強くおすすめします。
まず、ASFを実行したいユーザーのアカウントを作成します。 この例では asf ユーザーを使用します。別のユーザーを使用する場合は、以下のすべての例にある asf ユーザーを、選択したユーザーに置き換える必要があります。 当社のサービスでは、 `` 悪い練習 と見なされるため、ASFをルート
として実行することはできません。
su # または sudo -i, root shell
useradd -m asf # ASFを実行するアカウントを作成する次に、ASFを /home/asf/ArchiSteamFarm フォルダに解凍します。 フォルダー構造はサービスユニットにとって重要です。$HOME 内の ArchiSteamFarm フォルダー、つまり /home/<user> である必要があります。 すべてを正しく行った場合、 /home/asf/ArchiSteamFarm/ArchiSteamFarm@.service ファイルが存在します。 linux バリアントを使用していて、Linux 上でファイルを展開せず、たとえば Windows からファイル転送を行った場合は、chmod +x /home/asf/ArchiSteamFarm/ArchiSteamFarm も実行する必要があります。
ルートとして以下のすべてのアクションを行いますので、 su または sudo -i を使用してシェルに移動します。
まず、このフォルダーが引き続き asf ユーザーの所有であることを確認しておくとよいでしょう。chown -hR asf:asf /home/asf/ArchiSteamFarm を一度実行すれば十分です。 パーミッションが間違っている可能性があります。例えば、zipファイルを ルートとしてダウンロードおよび/または解凍している場合。
次に、ASF の generic バリアントを使用している場合は、dotnet コマンドが認識され、標準的な場所のいずれかである /usr/local/bin、/usr/bin、または /bin にあることを確認する必要があります。 これは、 dotnet /path/to/ArchiSteamFarm.dll コマンドを実行する systemd サービスに必要です。 dotnet --info があなたのために動作するかどうかを確認します。はいの場合は、 コマンド -v dotnet と入力して、その場所を確認します。 公式インストーラを使用している場合は、 /usr/bin/dotnet か、他の2つの場所のいずれかにある必要があります。 /usr/share/dotnet/dotnet のようなカスタムの場所にある場合は、その シンボリックリンク を作成してください。作成には ln -s "$(command -v dotnet)" /usr/bin/dotnet を使用します。 コマンド -v dotnet は /usr/bin/dotnetを報告する必要があります。これにより、systemd ユニットも動作します。 OS 固有のバリアントを使用している場合は、この点に関して何もしる必要はありません。
次に、ln -s /home/asf/ArchiSteamFarm/ArchiSteamFarm\@.service /etc/systemd/system/ArchiSteamFarm\@.service を実行します。これにより、サービス宣言へのシンボリックリンクが作成され、systemd に登録されます。 シンボリックリンクを使うと、ASF の更新の一部として systemd ユニットも自動的に更新できるようになります。状況に応じて、この方法を使ってもよいですし、単にファイルを cp して好きなように自分で管理しても構いません。
その後、 systemd が当社のサービスを認識していることを確認します。
systemctl status ArchiSteamFarm@asf
○ ArchiSteamFarm@asf.service - ArchiSteamFarm Service (on asf)
Loaded: loaded (/etc/systemd/system/ArchiSteamFarm@.service; disabled; vendor preset: enabled)
Active: inactive (dead)
Docs: https://github.com/JustArchiNET/ArchiSteamFarm/wiki
@の後に宣言するユーザーには特別な注意を払ってください。この場合は asf です。 当社の systemd サービスユニットは、ユーザーがユーザーを宣言することを期待しています。 バイナリ /home/<user>/ArchiSteamFarmの正確な場所に影響を与えます。 実際のユーザシステムと同様にプロセスが生成されます。
systemd が上記のように出力を返した場合、すべてが順番になっており、ほぼ完了しています。 今、残っているすべては、実際に私たちの選択したユーザーとして私たちのサービスを開始しています: systemctl start ArchiSteamFarm@asf. 2、3秒待ってから、もう一度ステータスを確認できます。
systemctl status ArchiSteamFarm@asf
● ArchiSteamFarm@asf.service - ArchiSteamFarmサービス(現時点で)
Loaded: loaded (/etc/system/system/ArchiSteamFarm@.service; disabled; ベンダープリセット: enabled)
Active: active (running) since (...)
Docs: https://github.com/JustArchiNET/ArchiSteamFarm/wiki
Main PID: (...)
(...)
systemd が active (running) と表示している場合は、すべて正常に完了したという意味です。ASF プロセスが起動して実行中であることは、たとえば journalctl -r で確認できます。ASF はデフォルトでコンソール出力にも書き込み、それが systemd によって記録されるためです。 現在の設定に満足している場合は、systemctl enable ArchiSteamFarm@asf コマンドを実行して、起動時にサービスを自動開始するよう systemd に指示できます。 それだけです
プロセスを停止したい場合は、 systemctl stop ArchiSteamFarm@asf を実行してください。 同様に、起動時にASFが自動的に起動されることを無効にしたい場合も同様です。 systemctl disable ArchiSteamFarm@asf はあなたのためにそれを行います, それは非常に簡単です.
systemd サービスの標準入力が有効になっていないため、ご注意ください。 通常の方法でコンソールから詳細を入力することはできません systemd を実行することは、 ヘッドレス: true の設定を指定することと同等であり、そのすべての意味が含まれます。 幸いなことに、 **ASF-ui**を介してASFを管理することは非常に簡単です。 ログイン中に追加の情報を提供する必要がある場合や、ASFプロセスをさらに管理する必要がある場合には、お勧めします。
追加の環境変数を systemd サービスに渡すこともできます。たとえば、カスタムの --cryptkey コマンドライン引数 を使用したい場合、つまり ASF_CRYPTKEY 環境変数を指定したい場合に便利です。
カスタム環境変数を提供するには、 /etc/asf フォルダを作成します (存在しない場合)、 mkdir -p /etc/asf。 これらのファイルには ASF_CRYPTKEY などの機密プロパティが含まれている可能性があるため、chown -hR root:root /etc/asf && chmod 700 /etc/asf を実行し、root ユーザーだけが読み取りアクセスできるようにすることをおすすめします。 その後、/etc/asf/<user> ファイルに書き込みます。ここで <user> は、サービスを実行するユーザーです（上記の例では asf なので、/etc/asf/asf になります）。
ファイルには、プロセスに提供したいすべての環境変数を含める必要があります。 専用の環境変数を持たないものは、 ASF_ARGS で宣言できます:
# 実際に
ASF_ARGS="--no-config-migrate --no-config-watch"
ASF_CRYPTKEY="my_super_important_secret_cryptkey"
ASF_NETWORK_GROUP="my_network_group"
# そしてあなたが興味を持っている他のどんなものsystemdの柔軟性により、 元のユニットファイルを保持しながら、ASFユニットの一部を上書きし、自動更新の一部としてASFを更新することができます。
この例では、デフォルトの ASF systemd ユニットの動作を成功時のみ再起動しないように修正し、致命的なクラッシュ時にも再起動したいと考えています。 そのために `` プロパティの [Service] を、既定の `on-success` から `常に` に上書きします。 `systemctl edit ArchiSteamFarm@asf`を実行するだけで、 `asf` をサービスの対象ユーザーに置き換えることができます。 次に、適切なセクションで `systemd` によって示されるように変更を追加します。
### /etc/systemd/system/ArchiSteamFarm@asf.service.d/override.conf を編集中
### ここから下のコメントまでの内容が、ファイルの新しい内容になります
[Service]
Restart=always
### このコメントより下の行は破棄されます
### /etc/systemd/system/ArchiSteamFarm@asf.service
# [Install]
# WantedBy=multi-user.target
#
# [Service]
# EnvironmentFile=-/etc/asf/%i
# ExecStart=dotnet /home/%i/ArchiSteamFarm/ArchiSteamFarm.dll --no-restart --service --system-required
# Restart=on-success
# RestartSec=1s
# SyslogIdentifier=asf-%i
# User=%i
# (...)`` [Service] の下で、Aformat@@5 Restart=always [Service] を持っているかのように、ユニットは同じ動作をします。
もちろん、代わりにファイルを cp して自分で管理することもできますが、この方法なら、たとえば シンボリックリンク で元の ASF ユニットを保持することにした場合でも、柔軟に変更できます。
ASFには、プロセスが管理者 (ルート) として実行されているかどうか独自の検証が含まれています。 ASF プロセスが動作する環境が適切に設定されている限り、ASF プロセスが行うどの操作にも root として実行する必要はありません。そのため、これは悪い慣行と見なすべきです。 つまり Windows では、ASF を「管理者として実行」設定で決して実行するべきではありません。また Unix では、ASF 専用の専用ユーザーアカウントを用意するか、デスクトップシステムの場合は自分のユーザーアカウントを再利用するべきです。
ASF の実行を推奨しない理由、特に root としての実行について詳しく知りたい場合は、superuser やその他のリソースを参照してください。 まだ納得していないなら ASFプロセスが起動直後に rm -rf /* コマンドを実行した場合、マシンに何が起こるかを自問してください。
これは、ASFがアクセスしようとしているファイルの権限が誤って設定されていることを意味します。 root アカウントでログインし（su または sudo -i を使用）、権限を修正してください。そのためには chown -hR asf:asf /path/to/ASF コマンドを実行し、asf:asf は ASF を実行するユーザーに、/path/to/ASF は適切なパスに置き換えます。 カスタム --path を使用している場合は、ASF ユーザーに別のディレクトリを使用するように指示します。 同じコマンドをもう一度実行するべきです
その後、独自のファイルを書き込むことができないASFに関連するいかなる問題も発生しないはずです。 ASFがユーザーに興味を持っているすべての所有者を変更したばかりの場合、ASFプロセスは実際に実行されます。
su # or sudo -i root シェルに入るには
useradd -m asf #
chown -hR asf:asf /path/to/ASF # 新しいユーザーがASFディレクトリにアクセスできることを確認する
su asf -c /path/to/ASF/ArchiSteamファーム # sudo -u asf /path/to/ASF/ArchiSteamFarm, 実際にあなたのユーザーの下でプログラムを始めることができますそれは手動で行うことになりますが、上記で説明した systemd サービス を使用する方がはるかに簡単です。
ASFは強制的にあなたがそうすることを止めるわけではありません、短い通知で警告が表示されるだけです。 プログラムのバグが原因である場合にショックを受けないでください。完全なデータ損失でOS全体が爆発します。あなたは警告されました。
ASFは、同じマシン上で複数のプロセスインスタンスを実行することと互換性があります。 インスタンスは完全にスタンドアロンであるか、同じバイナリの場所から派生することができます (その場合は、この場合)。 異なる --path コマンドライン引数 で実行します。
同じバイナリから複数のインスタンスを実行する場合、通常はすべての設定で自動更新を無効にする必要があることに注意してください。 自動更新に関しては同期が行われていないからです 自動更新を有効にしたい場合は、スタンドアロンインスタンスをお勧めします。 しかし、他のすべてのASFインスタンスが閉じられていることを確認できる限り、更新は機能します。
ASFは、OS全体で他のASFインスタンスとのクロスプロセス通信を最小限に抑えるために最善を尽くします。 これには、ASFの設定ディレクトリを他のインスタンスに対してチェックすることが含まれます。 *LimiterDelay **グローバル設定プロパティ**で設定されたコアプロセス全体のリミッターを共有する 複数のASFインスタンスを実行してもレート制限の問題が発生しないことを保証します。 技術的側面に関しては、すべてのプラットフォームが一時ディレクトリに作成されたカスタムASFファイルベースのロックの専用メカニズムを使用します。 は、Windowsでは C:\Users\<YourUser>\AppData\Local\Temp\ASF 、Unix では /tmp/ASF です。
同じ *LimiterDelay プロパティを共有するために ASF インスタンスを実行する必要はありません。 各ASFはロックを取得した後にリリース時間に独自に設定された遅延を追加するため、異なる値を使用できます。 設定された *LimiterDelay が 0に設定されている場合 ASFインスタンスは、他のインスタンスと共有される特定のリソースのロックを完全にスキップします(つまり、お互いに共有されたロックを維持する可能性があります)。 他の値に設定すると、ASFは他のASFインスタンスと正しく同期し、順番を待機します 次に、他のインスタンスを継続できるように、遅延設定後にロックを解除します。
ASF は共有スコープを判断する際に WebProxy 設定を考慮します。つまり、異なる WebProxy 設定を使用している 2 つの ASF インスタンスは、互いにリミッターを共有しません。 これは、異なるネットワークインターフェイスから期待されるように、 WebProxy の過度の遅延なしに動作するようにするために実装されています。 これは、大部分のユースケースで十分に良いはずですが、例えば、特定のカスタムセットアップがある場合など。 ルーティングは自分自身を別の方法で要求します --network-group **コマンドライン引数**を使用してネットワークグループを指定できます。 このインスタンスと同期するASFグループを宣言することができます。 カスタムネットワークグループは排他的に使用されていることに注意してください。 つまり、ASFは WebProxy を使用して正しいグループを決定することはできなくなります。 この場合のグループ化を担当しています
複数の ASF インスタンスで上記の systemd サービス を利用したい場合は、とても簡単です。ArchiSteamFarm@ サービス宣言で別のユーザーを使用し、残りの手順を続けてください。 これは、複数の ASF インスタンスを別々のバイナリで実行するのと同等なので、自動的に更新して動作させることもできます。
