उबंटू सर्वर के पास डिफ़ॉल्ट सिस्टमड लक्ष्य के रूप में ग्राफिकल.टार्ग क्यों है?


20

मैं कुछ समय के लिए एक उबंटू उपयोगकर्ता रहा हूं, और काम पर हमारे पास कई उबंटू वीएम सर्वर हैं , जो सभी Ubuntu 14.04 LTSहमारे वेब एप्लिकेशन, डेटाबेस और अन्य टूल को तैनात करने के लिए चलते हैं ।

मैं वर्तमान में अध्ययन कर रहा हूं Ubuntu 16.04 LTS, डेस्कटॉप और सर्वर, हमारे उत्पादन सर्वर को निकट भविष्य में समस्याओं के बिना अपग्रेड करने में सक्षम होने के लिए।

Ubuntu 15.04 के बाद से, initऔर upstartइसके द्वारा प्रतिस्थापित किया गया है Systemd, इसलिए मैं Systemd का भी अध्ययन कर रहा हूं।

मैंने देखा कि मेरे विकास कंप्यूटर में Ubuntu 16.04 डेस्कटॉप संस्करण चल रहा है graphical.target, जो डिफ़ॉल्ट सिस्टमड लक्ष्य के रूप में है, जो तार्किक है।

लेकिन तब मैंने देखा कि उबंटू 16.04 सर्वर संस्करण का परीक्षण करने वाला सर्वर graphical.targetडिफ़ॉल्ट सिस्टमड लक्ष्य के रूप में भी उपयोग करता है ।

$ systemctl get-default
graphical.target

इसलिए मैं उलझन में हूं। सर्वर में कोई ग्राफ़िकल परत नहीं है, इसलिए यह कैसे है कि डिफ़ॉल्ट लक्ष्य है graphical.target?

# 0 संपादित करें

जैसे रिन्जविंड ने टिप्पणियों में सुझाव दिया, मैंने लक्ष्य को देखा कि यह सक्रिय है या नहीं ...

और प्रतिक्रिया हां है:

admin@server1604:~$ systemctl get-default
graphical.target

admin@server1604:~$ systemctl status graphical.target
● graphical.target - Graphical Interface
Loaded: loaded (/lib/systemd/system/graphical.target; static; vendor preset: enabled)
Active: active since jeu. 2016-10-13 16:03:18 CEST; 46min ago
Docs: man:systemd.special(7)

oct. 13 16:03:18 fdea systemd[1]: Reached target Graphical Interface.

इसलिए मैं थोड़ा और उलझन में हूं।

# 1 संपादित करें

मार्क स्टोसबर्ग का जवाब इस तथ्य को इंगित करता है जो अपने स्वयं के 16.04 सर्वर display-manager.serviceकी निर्भरता के पेड़ का हिस्सा है graphical.target, और वह कहते हैं कि कोई प्रदर्शन प्रबंधक स्थापित नहीं है या इसकी मशीन पर चल रहा है। मैंने उस पर भी गौर किया, और वास्तव में, मेरे सर्वर पर यह निर्भरता है:

admin@server1604:~$ systemctl list-dependencies graphical.target 
graphical.target
● ├─accounts-daemon.service
● ├─apache2.service
● ├─apport.service
● ├─display-manager.service

...

और इस लक्ष्य के बाईं ओर एक लाल घेरा है, जहां अधिकांश अन्य निर्भरताओं में एक हरे रंग की है।

और इस बार परिणाम सुसंगत है:

admin@server16.04:~$ systemctl status display-manager.service 
● display-manager.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

लेकिन यहाँ एक और अजीब बात है: मेरे डेस्कटॉप संस्करण पर, की display-manager.serviceनिर्भरता नहीं है graphical.target:

me@desktop16.04:~ $ systemctl list-dependencies graphical.target | grep display
me@desktop16.04:~ $ 

लेकिन मुझे एक विकल्प भी मिला क्योंकि मैं डिफ़ॉल्ट विंडो मैनेजर Ubuntu-Gnomeको lightdmबदलने के साथ चलता हूं :

me@desktop16.04:~ $ systemctl list-dependencies graphical.target | grep lightdm
● ├─lightdm.service

आपको 1 महत्वपूर्ण जानकारी याद आ रही है: graphical.targetसक्रिय है?
रिनजविंड

आपके कमेंट के लिए धन्यवाद। लेकिन वास्तव में, हाँ, यह सक्रिय है! इसका क्या मतलब है ?
रेमी बी।

हम्म कुछ प्रासंगिक पाया।
रिनविंड

वह हिस्सा जो समझ में आ सकता है: "... या अकाउंट्स-डेमन.स्वाइस" सर्वर को इसकी भी आवश्यकता होगी। भ्रामक हालांकि कम से कम कहने के लिए।
रिनविंड

जवाबों:


10

लक्ष्य के नाम के बावजूद, उबंटू सर्वर 16.04 पर ग्राफिकल रनिंग नहीं है। यदि आप चाहें, तो आप अपने डेस्कटॉप से ​​इसकी जांच और तुलना करने के लिए यह आदेश दे सकते हैं:

systemctl list-dependencies graphical.target 

मेरे Ubuntu 16.04 सर्वर पर, मैं देखता हूं कि लक्ष्य "डिस्प्ले-मैनेजर. सर्विस" पर निर्भर करता है, लेकिन कोई डिस्प्ले मैनेजर स्थापित या चालू नहीं होता है।

मुझे उम्मीद है कि उबंटू सर्वर इस तरह से किसी तरह की स्थिरता के लिए सेट हैं, हालांकि मैं मानता हूं कि यह भ्रामक है।


भ्रामक पेरी पर सहमत हुए। कोई शायद सोचता है कि एक डे को सेट करना पर्याप्त नहीं है
रिनविंड

@ रिनविंड, मुझे समझ नहीं आया कि आपका वाक्यांश "डी सेटिंग नहीं है पर्याप्त है" (अंग्रेजी मेरी प्राथमिक भाषा नहीं है)
रेमी बी।

आप शायद स्थिरता की आवश्यकता के बारे में सही हैं। क्या डेबियन से वैकल्पिक तरीके के बजाय डेस्कटॉप से ​​सर्वर संस्करण बनाया गया है?
रेमी बी।

'डी' का मतलब है डेस्कटॉप वातावरण। मुझे कुछ साल पहले की एक सूचना याद है जहाँ उसने कहा था कि उबंटू ने 1 आधार प्रणाली का उपयोग शुरू किया था; लेकिन मुझे नहीं पता कि वे डेस्कटॉप बनाने के लिए सर्वर का उपयोग करते हैं या यदि वे सर्वर बनाने के लिए डेस्कटॉप का उपयोग करते हैं। "graphical.target" डेस्कटॉप सेवा सेट करता है; इसका मान "" हो सकता है और फिर DE शुरू नहीं होता है, लेकिन इसे भ्रमित करना है (मुझे उम्मीद है कि "मल्टी-user.target" का उपयोग करने के लिए एक मान और सर्वर रखने के लिए
Rinzwind

8

से redhat मैनुअल :

उदाहरण के लिए, graphical.target इकाई, जिसका उपयोग एक ग्राफिकल सत्र शुरू करने के लिए किया जाता है, सिस्टम सेवाओं जैसे GNOME डिस्प्ले मैनेजर (gdm.service) या लेखा सेवा (अकाउंट्स-डेमन. सर्विस) को शुरू करता है और बहु-उपयोगकर्ता को भी सक्रिय करता है। लक्ष्य इकाई। इसी तरह, मल्टी-user.target यूनिट अन्य आवश्यक सिस्टम सेवाएँ जैसे NetworkManager (NetworkManager.service) या D-Bus (dbus.service) शुरू करती है और एक अन्य लक्ष्य इकाई को सक्रिय करती है जिसका नाम है basic.target।

इसलिए इसे सेट करना गलत नहीं है क्योंकि यह डिस्प्ले मैनेजर को तब सक्रिय नहीं करता है जब डिस्प्ले सेवा को हैंडल करने वाली सर्विस सेट नहीं होती है।

एक सर्वर के लिए आप इसे सेट कर सकते हैं, multi-user.targetलेकिन इसकी आवश्यकता नहीं है। ऐसा लगता है कि आप रनवे 4 पर समाप्त होते हैं यदि आप करते हैं और जब आप नहीं करते हैं तो रनवे 5।

Runlevel    Target Units    Description
0   runlevel0.target, poweroff.target   Shut down and power off the system.
1   runlevel1.target, rescue.target     Set up a rescue shell.
2   runlevel2.target, multi-user.target     Set up a non-graphical multi-user system.
3   runlevel3.target, multi-user.target     Set up a non-graphical multi-user system.
4   runlevel4.target, multi-user.target     Set up a non-graphical multi-user system.
5   runlevel5.target, graphical.target  Set up a graphical multi-user system.
6   runlevel6.target, reboot.target     Shut down and reboot the system. 

मैं डाउनवोट पर प्रतिक्रिया की सराहना करूंगा।
रिनविंड

1

लक्ष्य की वृक्ष निर्भरता के पहले स्तर का विवरण में अधिक निरीक्षण graphical.target:

admin@server1604:~$ systemctl list-dependencies graphical.target 
graphical.target
● ├─accounts-daemon.service
● ├─apache2.service
● ├─apport.service
● ├─display-manager.service              (disabled)
● ├─grub-common.service
● ├─irqbalance.service
● ├─mdadm.service
● ├─ondemand.service
● ├─sysstat.service
● ├─systemd-update-utmp-runlevel.service (disabled)
● ├─ureadahead.service                   (disabled)
● └─multi-user.target

पहले स्तर के साथ इसकी तुलना multi-user.target:

admin@server16.04:~$ systemctl list-dependencies multi-user.target
multi-user.target
● ├─apache2.service
● ├─apport.service
● ├─atd.service
● ├─cron.service
● ├─dbus.service
● ├─grub-common.service
● ├─irqbalance.service
● ├─lxcfs.service
● ├─lxd-containers.service
● ├─mdadm.service
● ├─networking.service
● ├─ondemand.service
● ├─open-vm-tools.service

...

मुझे लगता है कि यदि हम graphical.targetपेड़ में अक्षम लक्ष्यों ( , ) को हटा दें display-manager.service, तो शेष लगभग सभी:systemd-update-utmp-runlevel.serviceureadahead.service

  • apache2.service
  • apport.service
  • grub-common.service
  • grub-common.service
  • irqbalance.service
  • mdadm.service
  • ondemand.service
  • तथा sysstat.service

पहले से ही निर्भरता के पेड़ के पहले स्तर में शामिल हैं multi-user.target

हालांकि, हमें इस तथ्य के बारे में फिर से पूछना चाहिए, क्योंकि graphical.targetनिर्भर करता है multi-user.target, इस सभी सामान की कोई आवश्यकता नहीं है। यह काफी अजीब लगता है।

लेकिन इस कमी के बाद, यह एक सेवा बनी हुई है accounts-daemon.service, जैसे रिन्जविंड ने अपनी टिप्पणी में बताया है

तो हम मान सकते हैं कि graphical.targetलोड करने के लिए आवश्यक है accounts-daemon.service

हालांकि, उस मामले में यह फिर से अजीब है, क्योंकि मैं पतला हूं, इस उद्देश्य के लिए एक समर्पित लक्ष्य बनाने के लिए यह अधिक समझ में आता है, शायद accounts.targetयह वर्णन करने के लिए कुछ सही या ऐसा कुछ । वैसे भी, शायद Canonical डेवलपर्स के पास ऐसा सोचने के लिए अपने कारण थे।

लेकिन मैं इसके कारणों को जानने के लिए उत्सुक हूं।

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