私はFedora 20とzshellとMateデスクトップを使用しています。私はこれに遭遇しましたSysRq キーの使用に関する記事しかし、そこに表示されている結果は得られません。私は SysRq キーの組み合わせとして、Alt キーと「Home」とマークされたキーとその上の「Print Scr」を使用しています。
黄色の「FN」キーも押してみましたが、違いはありませんでした。
「システムが完全に壊れている場合でも再起動する」シーケンスは非常に便利そうなので、何が間違っているのか知りたいです。
答え1
おそらく SysRq の組み合わせが無効になっています。これが機能するには、いくつかの条件を満たす必要があります。
CONFIG_MAGIC_SYSRQカーネル構成で有効にする必要があります。kernel.sysrqSysRq の組み合わせを解釈できる値に sysctl を設定する必要があります。
kernel.sysrq機能を有効/無効にするビットマスクです:
- 0 - 完全に無効
- 1 - 完全に有効
- 2 - コンソールのログレベルを制御できるようにする
- 4 - キーボードの制御を許可する
- 8 - プロセスダンプの制御を許可する
- 16 -
sync()通話の制御を許可する - 32 - 読み取り専用での再マウントを許可する
- 64 - プロセスシグナリングを許可する
- 128 - システムの電源状態の変更を許可する (再起動/電源オフなど)
- 256 - リアルタイムで実行中のタスクの最適化を許可する
すべての SysRq 機能を有効にする場合は、次のツールを使用して値を一時的に設定できますsysctl。
sysctl -w kernel.sysrq=1
これを永続的に行うには、次の行を追加します/etc/sysctl.conf。
kernel.sysrq = 1
/etc/sysctl.confその後、を発行して、システムに の設定を再読み込みさせることができますsysctl -p。
答え2
通常、ボタンを押すと、キーボードは単一のキーコードを生成します。OS はキーコードを受け取り、いくつかのキー マッピングを適用し、基盤となるハードウェアとは独立してキーの組み合わせを処理しようとします。
SysRq のメカニズムは少し異なります。キーボードは組み合わせをキャッチし、単一のボタンが押されたかのように特別なキーコードを OS に送信します。Linux カーネルは特別なキーコードをキャッチし、X サーバーなどの高レベル アプリケーションに入力を転送せずに内部で処理します。これは次の 2 つの結果を意味します。
キーの組み合わせは、実際にはキーボードによって異なります。キーボードは、すべてのキーの押下を独自にキャッチする必要があり、実際の SysRq キーがどこにあるか、どの組み合わせが特別なキーコードの送信をトリガーするかを「知っている」のはキーボードだけです。つまり、
- SysRq は必ずしも「Home」や「Print Screen」と同じボタンにあるわけではありません。検索してみてください。通常は明示的に「SysRq」としてマークされています。
Ctrl+Alt+SysRq+bまたは など、さまざまな組み合わせを試してくださいCtrl+Alt+Fn+SysRq+b(警告: 成功するとシステムが再起動します)。 キーがあるキーボードでは、Fn実際のキーに到達するには通常そのキーを押す必要があるためSysRq、組み合わせには キーが含まれる可能性が高くなりますFn。
組み合わせが正しいかどうかは、実際にわかります。
xevターミナルから実行し、xevウィンドウにフォーカスを合わせてキーボードのいくつかのボタンを押すと、ターミナルにイベントが表示されます。組み合わせが正しい場合、イベントはカーネルによってキャッチされ、X サーバーに配信されないため、イベントは表示されません。
次のドキュメントも参照してください:https://www.kernel.org/doc/Documentation/sysrq.txt