通常のユーザーとしてデーモンを実行するサーバーがあります。将来的には、私が信頼する人にこのユーザーへのアクセスを許可する予定です。しかし、予防措置として、suまたはsudoアクセスなしですべての構成と管理を実行したいと思います。これを行うために、単純なシステムユーザーユニットを作成し、それが機能するかどうかをテストしました。もちろん。
問題は、サーバーを再起動するときです。 systemdはmariadb（デーモンに必要）が準備される前にデーモンを起動しようとします。これにより、systemdのStartLimitが超過し、systemdがデーモンの起動試行をすべて停止するまで、デーモンは繰り返し失敗します。
この問題を解決するために私ができることはたくさんあります。 SQL Serverが接続されるまで繰り返しクエリを実行し、デーモンを起動しようとするスクリプトを実行するようにsystemdデバイスを再構築できます。または、システムデバイスで再起動の間にタイムアウトを追加できますか？たとえば... 30秒？しかし、両方とも...混乱して...単調な感じを与えます。むしろもう少しエレガントなソリューションが欲しいです。
systemdのマンページを見ましたが…そこにはたくさんあります。どんなアイデアがありますか？
問題のユニットファイル：
[Unit]
Description=Teamspeak 3
[Service]
Type=forking
#User=teamspeak
#Group=teamspeak
UMask=0027
Restart=always
WorkingDirectory=/home/teamspeak/ts
PIDFile=/home/teamspeak/ts/ts3server.pid
ExecStart=/home/teamspeak/ts/ts3server_startscript.sh start inifile=/home/teamspeak/ts/ts3server.ini
ExecStop=/home/teamspeak/ts/ts3server_startscript.sh stop
ExecReload=/home/teamspeak/ts/ts3server_startscript.sh restart
[Install]
WantedBy=default.target
ベストアンサー1
エレガントな解決策は、ソケットアクティベーションを使用してシステムサービスを開始することです。ソケット起動ポイントの1つは、依存関係を明示的に指定せずに相互依存サービスを開始できるようにすることです（したがって、起動はさらに並列化されます）。
例えばソケットアクティベーションに関するこのブログ投稿これはこれを非常に明確に示しています。
ソケットを有効にすると、注文なしでまったく同時に4つのサービスをすべて開始できます。リスニングソケットの作成がデーモンプロセスの外部に移動されたため、同時に起動でき、互いにソケットにすぐに接続できます。
特定のケースがユーザー単位とシステム単位の相互依存関係である場合でも、同じロジックが適用されます。
残念ながら、現在のMariaDBはシステムアクティベーション自体をサポートしていません。。ただし、次のプロキシを使用できます。systemd-ソケット-プロキシ(8)別のポートにMariaDB用のソケットアクティベーションサービスプロキシを作成します。バラよりこの問題詳細については。
別のオプションは、Teamspeakサービスを次のように使用することです。システムサービスの代わりにサービスを使用し、適切なUser=ディレクティブ（現在説明したように）を使用してサービスユーザーと一緒に実行し続けます。
あなたがそれを「デーモン」と記述しているので、システムサービスにすることは完全に適切でより正しいアプローチであるかもしれないと言いたいと思います。
「teamspeak」ユーザーでログインした人がサービスを管理（停止/再開）しにくくするなどの欠点がありますが、サービスアカウントへの切り替えに関連する配列にも欠点があると提案したいです（個人的には避けると思います） ）。この設定）、この設定をそのままにして、ユーザーが「sudo」などを使用してシステムサービスを管理できるようにすることができます。