systemdの積極的な緊急シェルの動作を無効にする方法は?


10

デフォルトでは、systemdはわずかなエラーで緊急シェルにドロップします。たとえば、何らかの理由でfstabのマウントの1つが失敗した場合、システムはすぐに起動できなくなります。私は何十もの多様な本番システムを管理していますが、この動作は非常に有害であることがわかりました。(実際には、これは重大な設計の失敗だと思いますが、それは個人的な意見です)。

システムのブート回復力を増やしたいのですが。与えられたエラーによってコンソールへのログインが完全に不可能にならない限り、システムは常に起動し、欠落しているドライバーやマウントなどが緊急シェルを落とさない(代わりに警告を表示する)のが最適です。何を実行できるか、実行する必要があります。

systemdが/ etc / fstabから* .mountファイルを自動的に生成し、小さなx-systemd.deviceタイムアウトでnofailオプションを使用できることを知っています(または関連する.mountファイルを自分で定義します)。しかし、それは私の問題を解決しません。システムをより回復力のあるものにしたいので、毎回fstabを「パッチ」するのはあまり便利ではありません。一部の開発者は、それが十分に重要であると考えました。

ソートでは、マシンの制御を取り戻したいので、systemdに、ブートプロセスをクラッシュさせるほど深刻な問題を決定させないようにします。出来ますか?


ところで実際の問題は何ですか?私は2つ知っています-sshを介してログインできないこと、およびsuloginプロンプトでは、sudoユーザーではなくrootのみが緊急モードでアクセスできるようにします。それらはあなたが受けた損害をカバーしますか?
sourcejedi

実際、これらの2つのサービスが開始されると、システムははるかにアクセスしやすくなります。最適には、システムは古いSysV時(緊急シェルによる痛みを伴う死の代わりにエラーログ)のように開始できるすべてのものを開始し、致命的なエラーの場合にのみシェルを開始する必要があります。
goteguru、2018年

回答:


7

文字通りマウントの失敗のみであり、変更する必要があるのはそれだけです。

だからあなたのリクエストの手紙は答えるのは簡単です。ドロップインファイルを作成します。

# /etc/systemd/system/local-fs.target.d/nofail.conf

# Clear OnFailure= (set it to nothing)
[Unit]
OnFailure=

これにより、linux sysvinitがこの部分的な障害のシナリオを許可することですでに苦しんでいる問題を除いて、新しい問題は追加されないと思います。


しかし、あなたはまた、どのように問題を指摘長く利用可能になるように、指定されたブロックデバイスを待つ必要があるにsystemdを。全体としてfstabジェネレーターの代わりを提供しない限り、これを構成する方法はありません。https://www.freedesktop.org/software/systemd/man/systemd.generator.html

ここであまり広く使用されていないコードを大量にダンプしても、システムの回復力が向上する可能性は低いと思われます。最も近い解決策は、既存のfstabジェネレーターにパッチを適用することだと思います。それはそれほど複雑ではありません、あなたはそれを回避することができます/重要な変更に追いつくことができると思います。

お使いのディストリビューションは、自己完結型の持っていた場合は技術的には、mountallはsysvinitスクリプトを、あなたがでていることフック試みることができるしかし、それは非常にブートプロセスを変更します- 。それは実際だよりフォークの。そのアプローチはお勧めしません。


https://unix.stackexchange.com/a/393711/29483

ユニットファイルを検索する場合、ブートがにフォールバックする方法はほとんどありませんemergency.target。通常 .mount、ローカルファイルシステムのユニットに障害が発生local-fs.target し、障害が発生した場合です。または、initramfsがsystemdを使用している場合、initramfsがルートファイルシステムのマウントに失敗した場合。

local-fs.target持っていOnFailure=emergency.targetます。また、ローカルファイルシステムのユニットがlocal-fs.targetのRequiredリストに自動的に追加されるため、失敗します(それらがなければ DefaultDependencies=no)。

$ systemctl show --property Requires local-fs.target
Requires=-.mount home.mount boot.mount boot-efi.mount

2
私は[Unit]\nOnFailure= 私のnofail.confに入れるべきだと思います。/etc/systemd/system.confで(一般的なDefaultTimeoutStartSecオプションを使用して)待機時間を構成できるようです。私のシステムは通常十分に高速ですが、90年代はとにかくやり過ぎです。この解決策は有望であるようです。
goteguru

私の場合、(AWSのUbuntu 16.04)の代わりに設定しOnFailure=ました/lib/systemd/system/local-fs.target/etc/systemd
ThiagoAlves

@ThiagoAlvesを実行しないでください。システムのアップグレード時に上書きされます。回答の指示に従うか、説明を求めてください:-)。
sourcejedi

@sourcejedi答えを試しましたが、うまく
いき

1
@ThiagoAlvesフィードバックありがとうございます。私は答えを曖昧にしないようにしたので、それが問題であったかどうかを明確にすることができます。つまり、[Unit]前に含めるようにしたかどうかですOnFailure=
sourcejedi

0

エントリにnoautoマウントオプションを追加して、ブート操作に不要なファイルシステムの自動マウントをオフにします/etc/fstab

/dev/sdxy /u01 nfs defaults 0 0

に:

/dev/sdyx /u01 nfs noauto 0 0

次に、ブート後にファイルシステムを次の行を使用してマウントします/etc/rc.local

mount /u01

この例ではNFSを使用していますが、ファイルサーバーからインポートされたLUNにも適用できます。


1
はい、私はnoautoを知っていますが、fstabを毎回変更する場合、nofailの方がはるかに良い選択です。とにかくTHX。
goteguru、2018年

0

これを試してみませんか?

systemctl mask emergency.service
systemctl mask emergency.target

4
これを試しましたか?緊急ターゲットをマスクした状態でsystemdが起動中にエラーを検出するとどうなりますか?
スティーブンキット
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.