Asteriskが起動/再起動したときにPowerShellファイルを実行したいと思います。
私.ps1/var/spool/アスタリスクディレクトリから新しいファイルをコピーしてAzure Storageコンテナに転送する必要があるファイル。このファイルは、最後に記録されたすべてのファイルをインポートしてAzureコンテナに転送する必要があります。ルートから手動でコマンドを実行すると機能します。これは、Azureコンテナに正常にアップロードされたログファイルの出力です。
Name BlobType Length ContentType L
a
s
t
M
o
d
i
f
i
e
d
---- -------- ------ ----------- -
out-067…9249.0.wav BlockBlob 44 application/octet-stream 2
uploaded!
すべての新しい録音を取得するには無限に実行する必要があります（毎分新しいファイルを確認してください）。これには、sleep 60コマンドを含むループdo / while（$ true）を使用しました。システムが再起動したり電源が切れたりした場合は、OS起動後にこのファイル（ps1）を再実行したいと思います。
pwsh /var/spool/transferrecordings.ps1そのためにコマンドを追加してみました。/etc/rc.localシステムの再起動時に動作するようにしてください。ディレクトリをvi /etc/rc.local次のように編集しました。
これは私がディレクトリで使用しているスクリプトです/etc/rc.local。
# THIS FILE IS ADDED FOR COMPATIBILITY PURPOSES
#
# It is highly advisable to create own systemd services or udev rules
# to run scripts during boot instead of using this file.
#
# In contrast to previous versions due to parallel execution during boot
# this script will NOT be run after all other services.
#
# Please note that you must run 'chmod +x /etc/rc.d/rc.local' to ensure
# that this script will be executed during boot.
pwsh /var/spool/transferrecordings.ps1
exit 0
しかし、サーバーが起動しても何も起こらないようです。
crontab -e次のコマンドを追加してcrontabを編集してみました@reboot pwsh /var/spool/transferrecordings.ps1。もう何もありません。
私はSangoma Linux（CentOS 3.10.0）を使用しています。
どんな提案がありますか？
ベストアンサー1
（OPだけでなく、この回答に触れた他のユーザーも活用したいという気持ちで文を書きます。）
この種の問題を解決するにはいくつかの方法があり、各アプローチの問題と長所と短所もあります。一般に、すべてのCPU / RAMを使用するプロセスが継続的に実行されることは望ましくありません。そうでなければ、システムは利用できません！
コードを「永久に」繰り返すデーモンとして書くことができますが、ループ反復の間に他のプロセス/プログラムもサービスされるようにアイドル/非アクティブ/スリープ状態に切り替わります。同時実行、競合状態、デッドロック、予期しない終了時の再起動処理、意図的に実行しない限り、同じデーモンを複数回実行しないようにするなど、デーモンモードで知っておくべきことがたくさんあります。安全に行う方法を理解してください。ここではこれについて詳しく説明しません。 Webで「デーモンを書く」を検索してみてください。
別のアプローチは、システムイベント（新しいファイルの作成、変更、アクセスなど）によって引き起こされるさまざまなシステム監視ツールを使用することです。この方法にはいくつかの問題があり、安全に使用する方法を理解していないとシステムがハングする可能性があります。ここでも彼のアプローチについてこれ以上詳しく説明しません。この方法が最も適していると思われる場合は、「ファイルシステムイベント通知」を検索してください。
もう1つの方法（そしてより多くの方法）は、cronコマンドを実行するほとんどのun * xシステムに共通のデーモンを使用するか、1分に1回ずつシェルスクリプトを定期的に使用することです。このアプローチには罠がありますが、一般的にこれを防ぐための措置を講じる方が簡単です。調整する必要がある最大の問題は、通常、シェルスクリプト（またはpowershellまたはperl / pythen /その他のコマンド/スクリプト）が処理するように設計する必要があることです。一度だけ無限ループではなく毎回実行されます。cron何度も繰り返してみましょう。 （cronそれ自体はデーモンとして実行され、デーモンになるすべての詳細と多くの問題を処理するように慎重に設計されているため、必要はありません。）処理が完了するとすぐに終了します。できるだけシステムやユーザーが好きなゲームプレイなど、他の操作を再実行できるようにします。 ;-)
一般的に知っておくべき「クローン作業」に関連する最大の問題は次のとおりです。
1：重複を防ぎ、コマンド/スクリプト内でループの繰り返し（特に無限ループ！）を防ぐのに十分な間隔を置いてください。そうでなければ、古いプロセスがまだ反復していても、cronは新しいプロセスを開始します。すぐに、何百または何千もの同じスクリプトが実行され、繰り返され、互いにクラッシュし、CPU、RAMなどを消費します。
2：前の項目に関してスクリプトで次のことをしたいと思います。そして完了cron- 上記のように、チケットが再度実行される前にできるだけ早く実行する必要があるタスク。もし2つの反復が重複する可能性があり（たとえば、ネットワークを介して大容量ファイルをコピーするときにこれが発生する可能性があります）、潜在的な並行性の問題、デッドロックなどを計画する必要があります。 （多くのスクリプトは最新バージョンを追跡してそれを処理します。）* .pidファイルのPID（プロセスID）は、以前の反復がまだ進行中であることを検出し、以前の反復がまだ実装を実行している場合は「新しい」を中止します。 )
3：この状況でスクリプトの複数のプロセスがトリガーされた場合は、そのうちの1つだけがコピー操作を実行していることを確認してください。それ以外の場合は、まったく同じファイル/データをコピーしようとすると競合が発生します。 （これが以前の実行が完了していないことを検出したときに* .pidメソッドを使用して中断する理由です。これを行う方法の詳細は、読者が検索と研究を練習できるようにするためです。技術..)
4：考慮すべき最後の問題は、ユーザーアクセスと権限です。このcronツールはさまざまなモードで実行されます。 1つは、コマンド/スクリプトを実行するユーザーアカウントを「crontab」設定に知らせる必要があるシステムモードです。それユーザーアカウントに対する権限。別のモードはユーザー固有のモードです。ここでcronコマンド/スクリプトを実行するユーザーアカウントは既に暗黙的であるため、既に知られています。 （cron実際に参考にしてください。いいえ user~/.bashrcなどを実行するので、必要に応じてコマンド/スクリプトに含める必要があります。 )
場合によっては知っておくべき他の問題もあるため、これらの問題を理解し、問題が発生した場合の対処方法を理解することが重要です。すでにインターネットには多くの情報があるので、cronここでは繰り返しません。オンラインで検索してみてください。
rsyncOPの最後の注意事項として、可能であれば、このコマンドの使用方法を学ぶことをお勧めします。これには、コピー方法/コンテンツを制御し、ファイルがすでに存在するかどうかを検出し、あるファイルが他のファイルより古いか最新であるかを検出するなど、便利な機能がいくつかあります。