タグ付けされた質問 「signals」

これは、この質問のフォローアップです。 さらにいくつかのテストを実行しました。これが物理コンソールで行われてもSSHで行われても、実際には問題ではないように見えますが、これはSCPだけでは起こりません。私もそれをテストしましたcat /dev/zero > /dev/null。動作はまったく同じです。 使用してバックグラウンドでプロセスを起動します&（または、それが使用し始めています後にバックグラウンドでそれを置くCTRL-Zとbg）。これはを使用せずにnohup行われます。 ログオフ。 再度ログオンします。 プロセスはまだそこにあり、楽しく実行されており、現在はの直接の子ですinit。 を送信すると、SCPとCATの両方がすぐに終了することを確認できSIGHUPます。これを使用してテストしましたkill -HUP。 そのため、少なくともバックグラウンドプロセスにはログオフ時にSIGHUPが送信されないように見えます（明らかな理由により、フォアグラウンドプロセスではテストできません）。 これは、当初VMware ESX 3.5（RedHatベース）のサービスコンソールで発生しましたが、CentOS 5.4で正確に複製することができました。 質問は、やはり次のとおりです。ログオフ時に、バックグラウンドで実行されている場合でも、SIGHUPをプロセスに送信するべきではありませんか？なぜこれが起こらないのですか？ 編集 straceカイルの答えに従って、私はで確認しました。 私は期待していたように、プロセスは取得していない任意のそれが開始されたシェルからログオフするときに信号を。これは、サーバーのコンソールを使用する場合とSSHを使用する場合の両方で発生します。

21 linux  bash  process  signals 

バックグラウンド systemd新しいサービスのスクリプトを作成するように依頼されました。これはfoo_daemon、「悪い状態」になることもあり、経由しないこともありますSIGTERM（カスタムシグナルハンドラのせいで）。これは、次の方法でサービスを開始/停止/再起動するように指示されているため、開発者にとって問題です。 systemctl start foo_daemon.service systemctl stop foo_daemon.service systemctl restart foo_daemon.service 問題 時には、foo_daemon悪い状態になるために、強制的に強制終了する必要があります： systemctl kill -s KILL foo_daemon.service 質問 どのようにすることができますが、私のセットアップ私のsystemdためのスクリプトをfoo_daemonするように、停止へのユーザーの試みは/サービスを再起動するたびに、systemd以下となります。 foo_daemonviaの正常なシャットダウンを試みSIGTERMます。 シャットダウン/終了がfoo_daemon完了するまで最大2秒かかります。 プロセスがまだ有効な場合は、foo_daemonviaの強制シャットダウンを試行しSIGKILLます（したがって、PIDがリサイクルされたり、間違ったPIDに対してsystemd問題が発生するリスクはありませんSIGKILL）。私たちがテストしているデバイスは、多数のプロセスを迅速に生成/分岐するため、PIDリサイクルが問題の原因となることはめったにありませんが、非常に現実的な懸念があります。 実際に、PIDのリサイクルについて単に妄想しているだけであれば、スクリプトはSIGKILL、リサイクルされたPIDを殺すことを心配せずに、プロセスのPIDに対して発行するだけで構いません。

20 linux  service  systemd  signals 

私はsvn + sshを使用していますが、いくつかのことがわかります： Killed by signal 15. 中svn up。 アイデアはありますか？

17 ssh  svn  signals 

私は最近、私のクライアントと契約を結び、彼の「ホーム」オフィスとセカンダリサイトの無線通信を容易にしました。 プライマリサイトは5階建てのオフィスビルの上位2階（高さ15m前後）で、セカンダリサイトは2つの「ロット」のうちの1つです（管理者は未定）。二次サイトからの地上距離は、より近い場所では2kmを超え、最も遠い場所では約2.9kmです。 このリンクを使用して、1台（または場合によっては2台）のIPカメラのビデオフィードと、イーサネット対応の環境センサーまたは気象センサーを送信します。カメラに必要なb / wを確認しましたが、900Mhzと5.8Ghzはどちらも4つでも十分であり、2つでも十分です。また、両方の設置場所に明確な見通し線があることも確認しました。 60％のフレネルゾーンのクリアランスがカバーされている以上です。これは私の最初の長距離リンク（引用符付きまたは引用なし）であり、無線物理学が私の強力なスーツとはほど遠いことを認めたくないことを覚えておいてください。 私の質問の究極のポイントは、ここ数日で周波数選択について多くのことを読みましたが、あいまいさを見つけ続けているということです。このようなほとんどのソースは、特定の距離で低い周波数の損失は少ないが（自由空間損失と呼ばれます）、同じ「強度」の伝送のために大きなアンテナが必要である（本当に「ゲイン」である）ことに同意します「強度」と同じ？）。 それで、2-3kmの距離と、すべての典型的な要件が満たされていることを考えると、これは望ましい（または「より良い」とあえて言う）周波数ですか？3kmは実際には「長距離」ではなく、減衰が少ないリンクを提供し、再送信が少なくなり、全体の速度が速くなることに基づいて、比較的「小さな」アンテナで900Mhzを選択する必要がありますか？または、この距離では本当の違いはないので、優れた白黒の5.8Ghzオプションを選択する必要があります（これについてはまだよくわかりません、間違って修正してください） 1？ 余談ですが、真のWiFiのbeat地にとどまるべきでしょうか、それともユビキティのような独自のブリッジソリューションを検討すべきでしょうか？私は彼らのアクセスポイントで多くの経験があり、本当に満足しているので、クライアントにもう1つの製品を統合してもかまいません。いずれにせよ、私は最適なソリューションを探していますが、現時点ではベンダーの選択はほとんど問題になりません。 私の無知と言語の誤った使用の可能性を許してください。 更新：数日間、スペクトルアナライザーを貸し出した。900Mhzバンドが合理的にクリアであることを確認し、そのように進めます。 更新2：前述の機器を1日半使用できました。ここで提案されているように、最終的な結論は、9Mhz帯域がエリア内でほとんど「空」であるため、周波数選択の問題に注意を払うことです。 現在の機器については、Ubiquiti AirMax YagiアンテナとマッチングRM900 2x2ラジオを使用しています。私とクライアントの従業員による予備テストでは、パフォーマンスが期待を上回ることが示されています。 ちなみに、選択された「ロット」は3km離れたものです。

13 wifi  wireless-bridge  signals 

Red Hat Enterprise Linux 5（SIGTERMなど）で送信されたシグナルの発信元を確認する方法はありますか？私は定期的にアプリケーションでTERMをトラップしていますが、どこから来たのかわかりません。

13 linux  signals 

信頼性の高い接続を確立するために必要なWifi信号の強度に関する業界標準はありますか？たとえば、Wifiエンドポイントは、-70db信号に確実に接続する仕様に設計されている可能性があります。 私たちはオフィス用のWifiネットワークを設計しています。dbに信号強度のマップがあります。ユーザーの実際のWifi接続にどのように対応するかを決定しようとしています。 また、プロトコルや頻度によって異なりますか？

9 networking  wifi  wlan  signals