バックグラウンド再起動呼び出しに危険または否定的な結果がありますか？

私は信頼性の高いLinuxシステム（カーネル5.0.19）を監視し、修正措置を取るように設計されたいくつかのシェルスクリプトを書いています。これらのタスクの1つは、場合によってはシステムを再起動することです。

再起動コードを書く方法で、呼び出しをバックグラウンドに置くことで、コード/sbin/reboot now &から別の操作を開始できます。この文脈が私が完全に理解していないという意味を含んでいるのではないかと心配されます。インターネット検索はこれに関する実際の情報を提供していません。バックグラウンド再起動またはシャットダウンコマンドがLinux上で良い決定か悪い決定であるかについての知識や意見を提供できる人はいますか？

追加の詳細 上記の指示に従って、私が作成したこの再起動プロセスは次のことを行う必要があります。

1. 正常に安全に再起動してみてください。
2. 再起動が中断された場合は、システムをハードリセットしてください。
3. ハードリセットを実行するときは、メモリ内のできるだけ多くのデータがディスクに書き込まれていることを確認してください。

システムのハードリセットは、システムにはんだ付けされたハードウェア監視回路によってトリガされ、これによりすべての（〜99.9％）再起動がハードリセットとして機能します。ソフトウェアウォッチドッグデーモンプロセス。監視プロセスを終了すると、ハードリセットが発生する前に60秒のカウントダウンがトリガされます。

私がコードを書く方法は次のとおりです。

1. 監視プロセスを終了し、ハードリセットのカウントダウンを開始します。
2. 正常に再起動し、プロセスをバックグラウンドに配置します。/sbin/reboot now &
3. rebootコマンドが中断されたと仮定し、継続的に同期を開始します。

私の再起動機能に関連するスニペットは次のとおりです。

# Kill watchdog daemon process(es), this starts 60s countdown to hard reset
pkill -9 watchdog
if (( $? == 0 )); then
    logThis INFO "Watchdog processes killed successfully, creatinged \"$watchdogTriggeredFile\""
    touch $watchdogTriggeredFile
fi

# Attempt a normal reboot before the watchdog forces ember to reboot
/sbin/reboot now &
# In testing, anytime the watchdog forces a reboot we lose ~15-25  
# seconds of logs. This is due to log writes being stored in memory. 
# The watchdog process does not call sync before it kills power to the
# system, so anything stored in memory is lost, therefore:
# Constantly write memory to disk until watchdog triggers reboot (60s)
for (( n=0; n<=600; n+=2)); do
    # Watchdog forces reboot after 60s, we sleep every .2, 60 / .2 = 300 iterations
    # Can't do floating point arithmetic in bash so we use 600 / 2 = 300 instead 
    # 300 iterations is more than 60s due to context switching and execution time
    sync    
    sleep 0.2
done

reboot nowもしそうなら、あなたはまだ同期を試みるために上記のコードのバックグラウンドコールに大きな問題があるかもしれませんか？