Azureで作成されたLinux Ubuntu VM(14.04 LTS)で再現可能な問題があります。
スクリプトを使用してsystemd
パッケージをインストールした後、システムは新しいssh接続を無限に拒否します。
システムが起動しています。
Xxx.xxx.xxx.xxxによって接続が閉じられました
ただし、アクティブなSSH接続は維持されます。システムに/etc/nologin
ファイルがありません。
私が目にする唯一のオプションは、問題を解決するハードリセットです。しかし、どうすればそれを回避できますか?
これが私が使用しているスクリプトです:
#!/bin/bash
# Script input arguments
user=$1
server=$2
# Tell the Shell to quote your variables to be eval-safe!
printf -v user_q '%q' "$user"
printf -v server_q '%q' "$server"
#
SECONDS=0
address="$user_q"@"$server_q"
function run {
ssh "$address" /bin/bash "$@"
}
run << SSHCONNECTION
# Enable autostartup
# systemd is required for the autostartup
Sudo dpkg-query -W -f='${Status}' systemd 2>/dev/null | grep -c "ok installed" > /home/$user_q/systemd-check.txt
systemdInstalled=\$(cat /home/$user_q/systemd-check.txt)
if [[ \$systemdInstalled -eq 0 ]]; then
echo "Systemd is not currently installed. Installing..."
# install systemd
Sudo apt-get update
Sudo apt-get -y install systemd
else
echo "systemd is already installed. Skipping this step."
fi
SSHCONNECTION
Systemdのインストール後に削除されない/etc/nologin
ファイル(その内容は「システムが起動中です。」)があると思います。
[更新]影響を受けるのは buntuのBTSで報告されたバグ 昨年12月です。これは、systemdインストールの最後に削除されない/var/run/nologin
ファイル(= /run/nologin
は/var/run
へのシンボリックリンクであるため、/run
)が原因です。
/etc/nologin
は標準のnologinファイルです。 /var/run/nologin
は、nologin
PAMモジュール( man pam_nologin
)で使用できる代替ファイルです。
nologin
ファイルは、ユーザーrootによる接続には影響せず、通常のユーザーのみがログインできないことに注意してください。
@xhienneは正しい方向を教えてくれました。
ファイルシステムを検索した後、/run/nologin
(@xhienneは/ etc/nologinを推奨)ファイルを見つけ、削除して問題を解決しました。
状態は/usr/lib/tmpfiles.d/systemd.conf
に存在しました
このステップをスクリプトに含めます。
Sudo rm /run/nologin
Note: This answer is applicable whether or not systemd was recently installed or not.
The issue was observed even after systemd had been installed a long time.
Mageiaディストリビューションのバグトラッカーでは、関連する問題が開いているようです: バグ21080-再起動後に/ run/nologinによってsshログインが無効化される 。
この問題が頻繁に発生した後、トラッカーを見つけることで、単に/ run/loginファイルを削除するよりも適切な回避策を特定できました。
そのバグトラッカーの情報に対するクエリに関連するいくつかのデータを次に示します。
$ ls -l /run/nologin
-rw-r--r-- 1 root root 42 Mar 6 10:11 /run/nologin
$ cat /run/nologin
"System is booting up. See pam_nologin(8)"
$ date
Tue Mar 6 11:10:38 CST 2018
$ uptime
11:15:10 up 1:04, 0 users, load average: 0.07, 0.07, 0.08
$ systemctl status systemd-user-sessions.service
● systemd-user-sessions.service - Permit User Sessions
Loaded: loaded (/usr/lib/systemd/system/systemd-user-sessions.service; static
Active: inactive (dead)
Docs: man:systemd-user-sessions.service(8)
$ systemctl show -p Requires,Wants,Requisite,BindsTo,PartOf,Before,After systemd-user-sessions.service --no-pager
Requires=system.slice sysinit.target
Requisite=
Wants=
BindsTo=
PartOf=
[email protected] prefdm.service crond.service multi-user.target plymouth-quit-wait.service session-c2.scope display-manager-failure.service systemd-ask-password-wall.service session-c1.scope [email protected] shutdown.target [email protected] user-983.slice user-1000.slice plymouth-quit.service
After=system.slice systemd-journald.socket remote-fs.target network.target systemd-journal-flush.service sysinit.target nss-user-lookup.target basic.target
バグトラッカーと上記の情報は、問題が実際にはsystemd-user-sessions.serviceデーモンの起動の失敗が原因であることを示しているようです。
これが実際に私の場合に起こることなので、次の回避策は一時的に禁止されたログイン状態を修正します。
$ Sudo systemctl start systemd-user-sessions.service
これを実行すると、/ run/nologinファイルが存在しなくなり、別のシステムからSSHで接続できるようになります。ただし、影響を受けるシステムのコンソールにユーザーがアクセスできない場合があるため、これは信頼性がないことに注意してください。
私はこれとまったく同じ問題を抱えていましたが、いくつかのシナリオで問題が発生すると思います。
私の場合、リモートアクセスを再度有効にするには、リモートサーバーに直接アクセスするためにKVMを要求し、次に:
# 1. Start SSH service
/etc/init.d/ssh start
# 2. Remove the nologin file
rm /run/nologin
しかし、KVM画面では、実際に緊急モードで起動したことがわかりました!
以前は、新しいUUIDを生成するディスク/パーティションの変更(inodeの増加)を行っていましたが、/ etc/fstabファイルに追加するのを忘れていました。
コマンドを発行した後:
blkid
...そしてfstabファイルに新しいUUIDをコピーして貼り付けると、問題なくサーバーを再起動でき、その後、リモートSSHアクセスは問題ありませんでした。
/ etc/ssh/sshd_configでUsePAMをnoに設定します
UsePAM no