ファイルシステムで読み書きする必要があるプログラムには、外部センサーと通信できる追加の機能があります。したがって、停電が差し迫ったかどうかを知るための独自の機能があります。私が受け取った警告はわずか数秒（約3〜5秒）に過ぎませんでした。フルシャットダウンを実行するのに十分ではありませんでした。数秒の貴重な時間を追加することができますが、ハードウェアコストが追加されます。
ファイルに書き込んでもオペレーティングシステムがそのタスクを実行できるという保証はないからです。今、私が知っている限り、ファイルを閉じるだけで、OSは後で誰もファイルにアクセスしようとしないとファイルを閉じると判断するので、どのように保証できますか？
- 今実行するすべての書き込みが保存されます。 （警告を受けた後、私のプログラムは数キロバイトをディスクに書き込みますが、警告を受ける前に多くのデータが記録されている可能性があり、OSがまだ完了していない可能性があります。）
- オペレーティングシステムの不適切なシャットダウンは他の損傷を引き起こすことはできません。
注：設計によっては、停電が頻繁に発生することがあります。さらに、設計上のシステムで実行される他の「ユーザーアプリケーション」はありません（したがって、音楽プレーヤー、開発環境、スプレッドシートエディタ、およびGIMPがすべて実行され、ファイルシステムにアクセスすることを心配する必要はありません）。
ベストアンサー1
あなたがしなければならない最も重要なことは問題を解決することですsyncシステムコール。syncこれを行うことができるユーティリティがあります。syncシステムコールが返されると、syncすべてのファイルシステム書き込み操作が完了する前に（マウントされたファイルシステムで）実行されることが保証されます。
一連の書き込み操作中にこれが発生しても、データを引き続き使用できるように設計することはアプリケーションによって異なります。ただし、ダウンタイム前のアラート期間が保証されている場合は、ダウンアラームに対する時期的に適切な応答を保証する限り、アプリケーションの設計が難しくなる可能性があります（困難）。
ext4などのジャーナリングファイルシステムの場合は、同期してから電源を切っても再起動時にfsckを受信しません。しかし、何らかの理由で同期後に書き込みが発生すると、fsckが必要になる可能性があると思いますが、そのような場合はまれです。確実に確認するには、電源を切る前にすべての読み取り/書き込みファイルシステムをマウント解除するか、少なくとも読み取り専用で再マウントしてください。通常、書き込み用に開いているファイルがある場合はこれを実行できません。システムがLinuxを実行している場合は、次のものを使用できます。魔法システム機能（有効になっていることを確認する必要があります）これは文字を書くことによってプログラム的に呼び出すことができます/proc/sysrq-trigger。echo u >/proc/sysrq-triggerすべてのファイルシステムが読み取り専用で再マウントされるようにします（ここには同期効果が含まれます）。設定が機能したら、このインターフェースを使用して再起動（b）または電源を切る（）することもできます。o
停電通知が抑制される可能性がある場合sync：を呼び出すことはパフォーマンスに悪影響を与えません。一方、読み取り専用インストールを強制することは通常回復できないため、再起動を実行している場合にのみこれを実行してください。
あなたの説明に一致するほとんどの設定では、これは停電通知に対する合理的な応答です。
- 影響を受けるプロセスにカスタム信号（SIGUSR1やSIGPWRなど）を送信して、次回の起動時に回復を容易にするのに役立つ場合は、進行中のトランザクションをすばやくコミットまたは中断するように指示します。
- 停電が予想される前に少し遅れを待ってください。残りの作業に十分なスペースを確保してください。
- ログメッセージを作成します。
echo u >/proc/sysrq-trigger