मुझे रूट के बिना "स्क्रीन समाप्त हो रही है" क्यों मिलता है?

23

मैंने फेडोरा 19 पर स्क्रीन लगाई है। जब मैं एसएसएच के माध्यम से रिमोट के रूप में कमांड का परीक्षण करता हूं, तो यह पूरी तरह से काम करता है। उदाहरण के लिए, यदि मैं screenएक नया टर्मिनल एमुलेटर दर्ज करता हूं, तो शुरू होता है और कमांड का इंतजार करता है। मैं इसे अलग कर सकता हूं, आदि। जब मैं एक मानक उपयोगकर्ता के रूप में एसएसएच के माध्यम से दूरस्थ रूप से लॉग इन करने के बाद एक ही करने की कोशिश करता हूं, तो कमांड तुरंत समाप्त हो जाती है। एकमात्र संदेश जो मैं देख रहा हूं [screen is terminating]।

क्या किसी को पहले से ही यह समस्या थी? क्या यह खराब अनुमतियों से संबंधित है?

अद्यतन करें:

$ strace -e trace=file screen
execve("/usr/bin/screen", ["screen"], [/* 23 vars */]) = 0
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libutempter.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libcrypt.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libpam.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libfreebl3.so", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libaudit.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
access("/home/steam/.nethackrc", F_OK)  = -1 ENOENT (No such file or directory)
readlink("/proc/self/fd/0", "/dev/pts/0", 4095) = 10
stat("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
lstat("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
open("/var/run/utmp", O_RDONLY)         = 3
open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
open("/etc/shadow", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)
readlink("/proc/self/fd/0", "/dev/pts/0", 4095) = 10
stat("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
stat("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
lstat("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
stat("/var/run/screen", {st_mode=S_IFDIR|0775, st_size=60, ...}) = 0
Directory '/var/run/screen' must have mode 777.
+++ exited with 1 +++

मैंने 777 में अनुमतियां बदलने की कोशिश की है, लेकिन जब मैं निष्पादित करता screenहूं, मुझे मिलता है:

निर्देशिका '/ var / run / स्क्रीन' में मोड 775 होना चाहिए।

इसलिए, मैंने अपने परिवर्तनों को वापस ले लिया है।

permissions  gnu-screen 
— लॉरेंट
स्रोत
आज्ञा क्या है?
— ewwhite
सबसे सरल एक: "स्क्रीन"। मैं कम से एक उदाहरण दर्ज की shelr.tv/records/525179c7966080791000005f
क्या आप संयोग से VPS या होस्टेड सर्वर पर हैं?
— ewwhite
यह एक होस्टेड सर्वर है
strace -e trace=file screenयह देखने के लिए कि क्या यह फ़ाइल एक्सेस पर विफल है। या tmuxकाम के इर्द-गिर्द उपयोग करता है , इसका उपयोग इसके अलावा भी करता है, इसके अलावा ^ ए के बजाय ^ बी का उपयोग करता है।
— इमैनुएल

जवाबों:

5

"777 मोड होना चाहिए" और "मोड 775 होना चाहिए" के बीच फ्लिप-फ्लॉपिंग के कारण होता है strace।

screenआमतौर पर एक सेट्यूड या सेटगिड प्रोग्राम होता है। यह निष्पादित होने पर अतिरिक्त विशेषाधिकार प्राप्त करता है, जो सॉकेट फ़ाइलों को बनाने और / या संशोधित करने के लिए उपयोग होता है।

जब एक प्रक्रिया का पता लगाया जा रहा है, तो setuid और setgid अक्षम हैं। ट्रेसिंग प्रक्रिया, कम-विशेषाधिकार प्राप्त उपयोगकर्ता द्वारा नियंत्रित, ट्रेस की गई प्रक्रिया को संभाल सकती है, इसलिए इसे मूल उपयोगकर्ता को बहुत अधिक शक्ति देने से बचने के लिए इसके अतिरिक्त विशेषाधिकारों के बिना चलना चाहिए।

screen यह पता लगाता है कि यह सेट्यूड विशेषाधिकारों, सेटगेड विशेषाधिकारों, या न तो के साथ चलाया जा रहा है, और इसके अनुसार निर्देशिका अनुमतियों की अपेक्षा को समायोजित करता है।

इसलिए यह उन समस्याओं का एक वर्ग बनाता है जिनके साथ आसानी से बहस नहीं की जा सकती है strace।

लेकिन अगर आप जड़ हैं, तो एक समाधान है! यदि अनुरेखण प्रक्रिया रूट के रूप में चल रही है, तो ट्रेस की गई प्रक्रिया सामान्य रूप से विशेषाधिकार प्राप्त कर सकती है। तो यहाँ आप क्या करते हैं:

  1. 2 नए टर्मिनल खोलें
  2. पहले टर्मिनल में, रूट के रूप में रिमोट मशीन में लॉग इन करें
  3. दूसरे टर्मिनल में, सामान्य उपयोगकर्ता के रूप में रिमोट मशीन में लॉग इन करें
  4. psदूसरे टर्मिनल में सामान्य उपयोगकर्ता के शेल प्रक्रिया के पीआईडी ​​प्राप्त करने के लिए उपयोग करें
  5. पहले टर्मिनल में, भागो strace -f -p SHELLPID
  6. दूसरे टर्मिनल में, स्क्रीन चलाएं और इसे विफल देखें
  7. पहले टर्मिनल में, अब आपके पास स्ट्रेस लॉग है जो आपको पता लगाना है कि वास्तव में क्या गलत है।

straceकमांड के अतिरिक्त महत्वपूर्ण -fविकल्प है, जो इसे बाल प्रक्रियाओं का पता लगाने के लिए कहता है। आपको स्क्रीन को ट्रेस करने की आवश्यकता है जो आपके द्वारा निर्दिष्ट शेल प्रक्रिया का एक बच्चा होगा -p।

मुझे -ffआउटपुट फ़ाइल का उपयोग करना और उसके साथ निर्दिष्ट करना भी पसंद -oहै

strace -ff -o /tmp/screentrace -p SHELLPID

जो प्रत्येक बच्चे की प्रक्रिया के लिए एक अलग आउटपुट फ़ाइल बनाएगा। बाद में आप उन्हें पढ़ते हैं less /tmp/screentrace*और इसका परिणाम आम तौर पर क्लीनर से होता है जो आपको एकल का उपयोग करके मिलता है -f।

अद्यतन करें

अब जब मैंने स्ट्रेस आउटपुट देखा है, मुझे नहीं पता कि वास्तव में क्या गलत हुआ, लेकिन यह रेखा ट्रेस में सबसे आश्चर्यजनक बात है:

chown("/dev/pts/2", 1002, 5)            = -1 EPERM (Operation not permitted)

कुछ पंक्तियों से पहले, इसने एक पीटीई बनाई, जो TIOCGPTNकि नंबर 2 से पता चला था ।

open("/dev/ptmx", O_RDWR)               = 5
...
ioctl(5, TIOCGPTN, [2])                 = 0
stat("/dev/pts/2", {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 2), ...}) = 0

लेकिन यह इसे चोक करने में असमर्थ था। मुझे नहीं पता कि वह चांस फेल क्यों होगा, लेकिन चांस फेल होने का एक बड़ा कारण यह है कि स्क्रीन ने हार क्यों मानी। आप -vस्ट्रेस विकल्पों में जोड़कर थोड़ी और जानकारी प्राप्त कर सकते हैं , और statबाद में TIOCGPTNयह देखने के लिए देख सकते हैं कि /dev/pts/एंट्री का मालिक कौन है ।

विस्तृत प्रक्रिया के लिए धन्यवाद। मैंने स्ट्रेस से उत्पन्न आउटपुट को देखने की कोशिश की है लेकिन मैं यह नहीं जान सकता कि क्या गलत है। इसके बाद स्ट्रेस से उत्पन्न तीन फ़ाइलों की सामग्री के साथ लिंक है: pastebin.com/raw.php?i=aeqDwTBX किसी भी विचार का स्वागत किया जाता है :)
— लॉरेंट
2

उस बग के संभावित कारणों पर - गलत सेलिनक्स नीतियां, लेकिन रेडहैट बगट्रैकर के अनुसार फेडोरा 17-18 में ऐसी त्रुटियां तय की गई थीं।

वर्कअराउंड के रूप SCREENDIRमें आप चर को बदल सकते हैं ~/.bashrcजैसे कुछ $HOME/.screen।

— अलेक्जेंडर कुद्रेवत्याख
स्रोत
मैंने कोशिश की है लेकिन यह मुद्दे को हल नहीं करता है।
— लॉरेंट
1

जब मुझे इस त्रुटि संदेश का सामना करना पड़ा। मुझे निम्नलिखित के साथ अपनी अनुमतियां समायोजित करनी थीं:

chmod 2775 /usr/bin/screen

और इससे मेरे लिए समस्या हल हो गई। सही पहुंच की अनुमति के लिए 2 बहुत महत्वपूर्ण है।

आपको SUID, SGID, स्टिकी बिट, ACL's पर अधिक पढ़ना चाहिए और वे किस तरह से पहुंच को प्रभावित करते हैं।

— Roric
स्रोत
u + s काम करता है। यह अच्छा नहीं है, लेकिन मैं इस समय अन्य समाधान नहीं देख सकता।
— एंटिटी रयोटेल्ला
0

स्क्रीन कमांड पहले से चल रही थी। इसलिए मैंने इसे समाप्त कर दिया और कमान वापस ले ली। हां यह दूसरों की तरह एक बहुत अच्छा संकल्प नहीं है, लेकिन ऐसा करने में कम समय लगता है।

बस पीएस और पीआईडी ​​ढूंढें, पीआईडी ​​को मारें और फिर से स्क्रीन कमांड को फिर से लिखने के साथ आगे बढ़ें।

यदि आप कई स्क्रीन कमांड चला रहे हैं, तो सुनिश्चित करें कि आप अपने टर्मिनल से जुड़ी सही प्रक्रिया को समाप्त कर दें।

— श्री हर्ष
स्रोत
0

मैंने इस समस्या को निम्न पंक्ति / fstab और रीबूटिंग में टिप्पणी करने के बाद हल किया:

devpts         /dev/pts        devpts  defaults        0       0
— उतो देव
स्रोत
0

सुनिश्चित करें screenकि कोई अन्य उस उपकरण का उपयोग नहीं कर रहा है

इसे /superuser/97844/how-can-i-determine-what-process-has-a-file-open-in-linux के साथ हासिल किया जा सकता है :

sudo lsof /dev/ttyS0

और फिर उस प्रक्रिया को मार डालो अगर ऐसा है तो।

किसी कारण के लिए, इस शर्त के तहत, sudo screenअभी भी डिवाइस का उपयोग कर सकते हैं, लेकिन फिर वह कनेक्शन पात्रों को याद करेगा, जो दूसरे द्वारा खपत होते हैं screen।

सुनिश्चित करें कि उपयोगकर्ता ने फ़ाइल को पढ़ने और लिखने की अनुमति दी है

जैसे कि उबंटू पर आप उपयोगकर्ता को dialoutसमूह में जोड़ना चाहते हैं : /ubuntu//a/133244/52975

— सिरो संतिल्ली 新疆 新疆 新疆 新疆 新疆 新疆
स्रोत
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.