導入
systemctl最近、Fedora 17 にアップグレードし、シェル init スクリプトではなく新しいデーモン マネージャーに慣れてきました。
私のデーモンに必要な機能は、コンソールを操作するプロセス自体によって開始されていない不正なシャットダウンは、データベースの破損を引き起こす可能性があるためです。そのため、systemctl stop service-name.serviceたとえばを実行すると、回復不可能なデータ損失が発生する可能性があります。
これらのコンソールはstdinまたは同様の方法でユーザー入力を読み取ります。そのため、古いOSで私が行っていたのは、これらのデーモンをセッションのフォアグラウンドに配置することですscreen。一時停止中その screen セッションを で実行します^A ^z。また、systemctlコンピューターが再起動すると自動的にこれを実行するようにしましたが、それでも、私が回避しようとしている潜在的なデータ破損の問題は解決されません。
私の質問
systemctl生成されたプロセスのコンソールと直接対話するために使用する方法はありますか? プロセスをフックしてsystemctlそのコンソールにアクセスできますか?
ありがとう
皆さんはいつも素晴らしい回答をしてくれるので、私も皆さんに頼っています!
答え1
tty にリダイレクトできる可能性があります。
StandardInput=
実行されたプロセスのファイル記述子 0 (STDIN) が接続される場所を制御します。null、tty、tty-force、tty-fail、または socket のいずれかを取ります。null を選択した場合、標準入力は /dev/null に接続されます。つまり、プロセスによるすべての読み取り試行は即時 EOF になります。tty を選択した場合、標準入力は TTY (TTYPath= で設定されているとおり、以下を参照) に接続され、実行されたプロセスは端末の制御プロセスになります。端末がすでに別のプロセスによって制御されている場合、実行されたプロセスは現在の制御プロセスが端末を解放するまで待機します。tty-force は tty に似ていますが、実行されたプロセスは強制的にすぐに端末の制御プロセスになり、端末から以前の制御プロセスが削除される可能性があります。tty-fail は tty に似ていますが、端末にすでに制御プロセスがある場合、実行されたプロセスの起動は失敗します。socket オプションは、ソケットによってアクティブ化されるサービスでのみ有効であり、ソケット設定ファイル (詳細は systemd.socket(5) を参照) が単一のソケットのみを指定している場合にのみ有効です。このオプションが設定されている場合、標準入力はサービスがアクティブ化されたソケットに接続されます。これは主に、従来の inetd(8) デーモンで使用するために設計されたデーモンとの互換性に役立ちます。この設定のデフォルトは null です。
ああ、もしそれがうまくいかなかったら、Unixソケットを使って本当に複雑なことをすることになるだろう。愛。
そんなナンセンスはやめてください。上記が受け入れられない場合は、次のようなことを試してください。
/proc pid ディレクトリに書き込んでみてください。デーモンの pid が 2000 だとすると、/proc/2000/fd/0 に書き込んでみてください。
その行を ExecStop= に追加すると、手動で操作する必要がなくなります。