私は、--unix-socketTCP ホスト/ポートではなく Unix ソケットにバインドするオプションを使用して、Ubuntu 18.04 のスーパーバイザーから Daphne を実行しています。
command=daphne --unix-socket /home/project/run/daphne.sock project.asgi:application
停電後、ファイルのインスタンスdaphne.sockが残され、再起動後、問題のあるファイルを手動で削除するまで Daphne は起動を拒否しました。
スーパーバイザーが実行される前に、システム起動時にファイルを安全に削除する方法はありますか?
これは Daphne に固有の問題ではなく、PostgreSQL などの他のコンポーネントにも影響する可能性があることを理解しています。そのため、supervisor または systemd によってサービスが開始される前にファイルをクリーンアップするための適切な提案があれば、ぜひ教えてください。
答え1
使用tmpfsたとえば、 内にファイルを作成します/dev/shm。
マウントされたファイルシステムとして表示されるが、揮発性メモリ永続的なストレージデバイスの代わりに。
[強調は筆者による]
私のDebianでも/run、tmpfsいくつかのツールがソケットを作成しているのがわかります。ＦＨＳ /runシステム全体のサービスによって作成されたソケットに適した場所です。
実行時変数データ: 前回の起動以降に実行中のシステムに関する情報 (現在ログインしているユーザーや実行中のデーモンなど)。このディレクトリの下のファイルは、起動プロセスの開始時に削除または切り捨てられる必要がありますが、このディレクトリを一時ファイルシステム (tmpfs) として提供するシステムでは、これは必要ありません。
私の Debian では、/runは root に属しており、そのモード ビット (権限) は ですrwxr-xr-x。通常のユーザーはその恩恵を受けることができません。
一方、/dev/shmはrwxrwxrwt誰でも使用できます。ただし、 のように「共有地」であるため/tmp、問題はほとんど発生しません。名前の競合の可能性はその 1 つです。2 人のユーザーが、意図はまったく無害であっても、お互いに迷惑をかける可能性があります。
それから/run/user/$uid、また、次のようにも呼ばれますtmpfs:
そのユーザーの実行中のプロセスで使用されるファイルを保存するために使用されます。[…]
このディレクトリはシステムに対してローカルであり、ターゲット ユーザーのみがアクセスできます。そのため、ファイルをローカルに保存するアプリケーションは、アクセス制御について心配する必要がなくなります。