私は、組織内の複数のプラットフォーム上の複数のクライアント アプリケーションに RPC 機能を提供するミドルウェアを開発しました。ミドルウェアは C# で記述され、Windows NT サービスとして実行されます。ネットワーク共有へのファイル アクセス、データベース アクセスなどを処理します。ミドルウェアは、Windows Server 2008 を実行する 2 つのハイエンド システムでホストされています。
サーバー管理者の 1 人が、主に Windows Update を実行するためにマシンを再起動しようとすると、NT サービスに関してシステムの動作に深刻な問題が発生します。私のサービスは、新しい接続のリッスンをすぐに停止し、既存の接続での新しい要求の拒否をすぐに開始し、そうでなければ、SCM からの OnStop または OnShutdown 要求の場合にできるだけ早くシャットダウンするように設計されています。それでも、システムの整合性を維持するために、現在進行中の操作は妥当な時間継続できます。通常、サーバーは 30 秒以内にシャットダウンします (たとえば、サービスが手動で停止された場合)。ただし、システムが再起動するように指示されると、サービスはすぐにネットワーク ドライブと UNC パスへのアクセスを失います。開いているファイルのデータ整合性の問題と、それらの場所への部分的な書き込みが発生します。私のサービスはワークステーション (および SMB リダイレクター) を依存関係としてリストしているため、Windows がそれらの依存関係を尊重している場合、ワークステーション/リダイレクターを停止する前にサービスを停止する必要があると思います。
基本的に、私のアプリケーションは強制的にクラッシュして焼き付き、リモート プロシージャ コールに失敗し、タイムアウト期間 (20 ～ 30 秒程度) が経過した後、最終的にオペレーティング システムによって強制終了されます。
Windows アプリケーションとは異なり、私の Windows NT サービスには、進行中のシステム シャットダウンを停止したり、システム シャットダウンを遅らせたり、または強制的に切断してシャットダウンする前に保留中のネットワーク共有ディスク書き込みを保存する機会さえもないようです。 . NT サービスの開発者は、この環境でアプリケーションの整合性をどのように確保する必要があるのでしょうか? サービスがそのようなメリットを享受していないように見えるのに、フォーム アプリケーションがシャットダウン前にビジネスを完了する機会をすべて得ているのはなぜですか?
私が試してみました：
p/invoke 経由で SetProcessShutdownParameters を呼び出して、アプリケーションにシャットダウンを通知し、リダイレクターがシャットダウンする前にシャットダウンしないようにします。
2 分の制限以下の値で ServiceBase.RequestAdditionalTime を呼び出す。
WaitToKillServiceTimeout の微調整
サービスのシャットダウンを高速化するために考えられるすべて。
しかし、最終的には、サービスがまだ OnShutdown イベントの通知を受けていないように見える問題が 30 秒ほど発生しますが、リダイレクタがネットワーク共有要求にサービスを提供しなくなったため、要求は失敗します。
この問題はどのように解決されることを意図していますか? シャットダウンを遅らせたり停止したりするにはどうすればよいですか? または、少なくともリダイレクター サービスが自分の下から消えることなく、アクティブなタスクをシャットダウンできるようにするにはどうすればよいですか? サービスが足を引きずってシャットダウンを表示するのを防ぐためにMicrosoftが何をしようとしているのかは理解できますが、それはサーバーではなくWindowsクライアントオペレーティングシステムにとって大きな目標のようです. サーバーを高速でシャットダウンするのではなく、運用の整合性と適切なシャットダウンが必要です。
ご協力いただきありがとうございます。
更新: 正確なタイミングを確認しました。テスト シャットダウンでは、23:55:58 にシャットダウン通知を受け取り、23:56:02 にネットワーク共有接続が失われていることに気付きました。つまり、4 秒以内に、アクティブな状態を保存できなくなりました。