सिस्टम SSH को मना कर देता है और systemd स्थापना के बाद 'बूटिंग अप' पर अटक जाता है


12

मुझे एक समस्या है जो Azure में निर्मित Linux Ubuntu VMs (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

क्या सिस्टम लटका हुआ है , या यह केवल सुरक्षित शेल डेमॉन शुरू नहीं कर रहा है? प्रश्न में कहा गया है; पोस्ट के शरीर का अर्थ है कि यह अन्य हो सकता है।
डोपघोटी

@DopeGhoti मेरे लिए यह जांचने का कोई तरीका नहीं है कि मैं क्या कर रहा हूं क्योंकि मैं मशीन से दूर से कनेक्ट नहीं कर सकता। मैं इसे स्पष्ट करने के लिए प्रश्न को अपडेट करूंगा।
एलेक्स

जवाबों:


15

मुझे संदेह है कि एक /etc/nologinफाइल है (जिसकी सामग्री "सिस्टम बूट हो रहा है।") जो कि सिस्टमड इंस्टालेशन के बाद हटाया नहीं जाता है।

[अद्यतन] क्या आपको प्रभावित करता है एक बग जो पिछले दिसंबर में उबंटू के बीटीएस पर सूचित किया गया था । यह एक /var/run/nologinफाइल के कारण है (= /run/nologinचूंकि /var/runसिम्बलिन है /run) जो सिस्टमड इंस्टालेशन के अंत में हटाया नहीं जाता है।

/etc/nologinमानक nologin फ़ाइल है। /var/run/nologinएक वैकल्पिक फ़ाइल है जिसे nologinPAM मॉड्यूल ( man pam_nologin) द्वारा उपयोग किया जा सकता है ।

ध्यान दें कि कोई भी nologinफ़ाइल उपयोगकर्ता रूट द्वारा कनेक्शन को प्रभावित नहीं करती है, केवल नियमित उपयोगकर्ताओं को लॉग इन करने से रोका जाता है।


मैंने समस्या को पुन: प्रस्तुत किया, कोई / etc / nologin फ़ाइल मौजूद नहीं है। सक्रिय SSH सत्र को बनाए रखा जाता है, हालांकि जब तक मैं मशीन को फिर से शुरू नहीं करता, नए लोगों को मना कर दिया जाता है।
एलेक्स

मैंने भी जाँच की /etc/shadowऔर खाता बंद नहीं है
एलेक्स

@Alex उत्तर अपडेट किया गया।
xhienne

10

@xhienne ने मुझे सही दिशा दी।

फ़ाइल सिस्टम के माध्यम से खोज करने के बाद मैंने पाया /run/nologin(@xhienne ने सुझाव दिया / etc / nologin) फ़ाइल, जिससे समस्या हल हो गई।

में स्थिति अस्तित्व में थी /usr/lib/tmpfiles.d/systemd.conf

मैं अपनी स्क्रिप्ट में इस कदम को शामिल करूंगा।

sudo rm /run/nologin

खुशी है कि यह काम करता है। मैंने अपना उत्तर अपडेट कर दिया है।
xhienne

2
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 - ssh लॉगइन रिबूट के बाद / रन / नॉलिन द्वारा निष्क्रिय

इस समस्या को काफी बार अनुभव करने के बाद, ट्रैकर को खोजने से एक वर्कअराउंड की पहचान करने में मदद मिली जो केवल / रन / लॉगिन फ़ाइल को हटाने से अधिक उपयुक्त हो सकता है ।

उस बग ट्रैकर में जानकारी के लिए प्रश्नों से संबंधित कुछ आंकड़े यहां दिए गए हैं:

$ 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=
Before=getty@tty1.service 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 user@983.service shutdown.target user@1000.service 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-session.service डेमन को शुरू करने में विफलता के कारण है ।

यह वास्तव में मेरे मामले में क्या होता है, इसलिए निम्न वर्कअराउंड अस्थायी रूप से प्रतिबंधित लॉगिन स्थिति को ठीक करता है:

$ sudo systemctl start systemd-user-sessions.service

ऐसा करने के बाद, / run / nologin फ़ाइल अब मौजूद नहीं है, और, कोई अन्य सिस्टम से SSH कर सकता है। ध्यान दें, हालांकि, यह विश्वसनीय नहीं है क्योंकि कभी-कभी उपयोगकर्ता को प्रभावित सिस्टम के कंसोल तक पहुंच नहीं होती है।


0

मुझे भी यही समस्या थी लेकिन मुझे लगता है कि कई परिदृश्य इसे बना सकते हैं।

मेरे मामले में, रिमोट एक्सेस को फिर से सक्षम करने के लिए मुझे हमारे रिमोट सर्वर तक सीधे पहुंच के लिए केवीएम का अनुरोध करना पड़ा: और

# 1. Start SSH service
/etc/init.d/ssh start

# 2. Remove the nologin file
rm /run/nologin

लेकिन KVM स्क्रीन पर मैं वास्तव में देख सकता था कि यह आपातकालीन मोड में बूट हुआ था!

पहले, मैं कुछ डिस्क / विभाजन परिवर्तन कर रहा था (इनोड्स को बढ़ा रहा था) जिसने एक नया UUID उत्पन्न किया और इसे / etc / fstab फ़ाइल में जोड़ना भूल गया।

आदेश जारी करने के बाद:

blkid

... और fstab फ़ाइल पर नए UUID को चिपकाते हुए, मैं सर्वर को फिर से बिना किसी समस्या के रीबूट करने में सक्षम था और उसके बाद रिमोट एसएसएच एक्सेस ठीक था।


0

/ Etc / ssh / sshd_config में UsePAM को सेट करें नहीं

UsePAM no

यह क्या करेगा और इसके परिणाम क्या होंगे?
Kusalananda

यह उत्तर इस स्थिति पर लागू नहीं होता है - यह व्याख्या नहीं करता है कि उपयोगकर्ता "सिस्टम को बूट कर रहा है" पाठ क्यों देखता है या यह बताता है कि सिस्टमड को स्थापित करने से टूटी हुई कॉन्फ़िगरेशन कैसे उत्पन्न होती है।
जेफ स्कालर
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.