আমি যেমন বুঝতে পেরেছি, লিনাক্স কার্নেল /proc/kmsgফাইল (বেশিরভাগ হার্ডওয়্যার-সম্পর্কিত বার্তা) এবং /dev/logসকেটে লগ করে? যে কোন জায়গায় অন্য? অন্যান্য অ্যাপ্লিকেশনগুলিও /proc/kmsgবা /dev/logকী বার্তাগুলি প্রেরণ করতে সক্ষম ? কিন্তু শেষ না অন্তত, আমি সংশোধন এটি syslog- র ডেমন হয় কোথায় ( নিম্নলিখিত rsyslog , syslog- র-NG ) যা ঐ দুটি স্থান থেকে বার্তা পরীক্ষা এবং তারপর মতো বিভিন্ন ফাইলগুলিতে ঐ বিতরণ /var/log/messagesবা /var/log/kern.logবা এমনকি কেন্দ্রীয় syslog সার্ভারের?
উত্তর:
সরলীকৃত, এটি এর মতো কমবেশি যায়:
printk()কার্নেল স্পেসে একটি রিং বাফারে বার্তা ( ফাংশন ব্যবহার করে ) লগ করে । এই বার্তাগুলি ব্যবহারকারী-স্পেস অ্যাপ্লিকেশনগুলিকে দুটি উপায়ে উপলব্ধ করা হয়েছে: /proc/kmsgফাইলের মাধ্যমে ( /procমাউন্ট করা থাকে এমন) এবং sys_syslogসিস্কেলের মাধ্যমে ।
দুটি প্রধান অ্যাপ্লিকেশন রয়েছে যা কার্নেলের রিং বাফারটি পড়ে (এবং কিছুটা হলেও নিয়ন্ত্রণ করতে পারে): dmesg(1)এবং klogd(8)। রিং বাফারের সামগ্রীগুলি মুদ্রণের জন্য ব্যবহারকারীদের চাহিদা অনুযায়ী চালানো হবে পরেরটি হ'ল একটি ডিমন যা মেসেজগুলি /proc/kmsg(বা কল করে sys_syslog, যদি /procমাউন্ট করা না থাকে) পড়ে এবং সেগুলিতে syslogd(8)বা কনসোলে প্রেরণ করে । এটি কার্নেল দিকটি coversেকে দেয়।
ব্যবহারকারীর জায়গায়, আছে syslogd(8)। এটি একটি ডেমন যা ইউনিক্স ডোমেন সকেটের কয়েকটি সংখ্যা (প্রধানত /dev/log, তবে অন্যরাও কনফিগার করা যেতে পারে), এবং ইউএসডি পোর্ট ৫১৪-তে বার্তাগুলির জন্য শুনে থাকে । এটি klogd(8)( syslogd(8)কোনও যত্ন করে না /proc/kmsg) থেকে বার্তাও গ্রহণ করে । এরপরে এটি বার্তাগুলি কিছু ফাইলগুলিতে /logবা নামযুক্ত পাইপগুলিতে লিখে বা কিছু রিমোট হোস্টকে ( syslogপ্রোটোকলের মাধ্যমে , ইউডিপি পোর্ট 514-তে) কনফিগার করা হিসাবে প্রেরণ করে /etc/syslog.conf।
ব্যবহারকারী-স্পেস অ্যাপ্লিকেশনগুলি বার্তা লগ করতে সাধারণত libcফাংশনটি ব্যবহার করে syslog(3)। libcইউনিক্স ডোমেইন সকেট এইসব বার্তা পাঠায় /dev/log(যেখানে তারা দ্বারা পড়া হয় syslogd(8)), কিন্তু যদি কোনো অ্যাপ্লিকেশন chroot(2)-ed বার্তা অন্যান্য সকেট, এর Fi এর লেখা হচ্ছে শেষ পর্যন্ত হতে পারে /var/named/dev/log। অ্যাপ্লিকেশনগুলির জন্য এই লগগুলি প্রেরণ করার জন্য এবং syslogd(8)এই সকেটের অবস্থানের সাথে একমত হওয়ার জন্য এটি অবশ্যই প্রয়োজনীয় । এই কারণে syslogd(8)স্ট্যান্ডার্ড বাদে অতিরিক্ত সকেট শুনতে কনফিগার করা যেতে পারে /dev/log।
শেষ syslogঅবধি, প্রোটোকলটি কেবলমাত্র একটি ডেটাগ্রাম প্রোটোকল। কোনও কাজই ইউনিক্স ডোমেন সকেটে (কোনও শংসাপত্রগুলি সকেটটি খোলার অনুমতি দেয়) সিসলগ ডেটাগ্রাম পাঠানো থেকে কোনও অ্যাপ্লিকেশনকে থামায় syslog(3)না, libcপুরোপুরি ফাংশনটি বাইপাস করে । যদি ডেটাগ্রামগুলি সঠিকভাবে ফর্ম্যাট syslogd(8)হয় তবে সেগুলি মেসেজের মাধ্যমে প্রেরণ করা হয়েছে এমনভাবে ব্যবহার করতে পারে syslog(3)।
অবশ্যই, উপরেরটি কেবল "ক্লাসিক" লগিং তত্ত্বকে অন্তর্ভুক্ত করে। অন্যান্য ডিমনগুলি (যেমন rsyslogএবং syslog-ngআপনি যেমন উল্লেখ করেছেন) সমতলটি প্রতিস্থাপন করতে পারে syslogd(8)এবং এনক্রিপ্ট করা টিসিপি সংযোগের মাধ্যমে দূরবর্তী হোস্টগুলিতে বার্তা প্রেরণ, উচ্চ রেজোলিউশনের টাইমস্ট্যাম্প ইত্যাদি সরবরাহ করতে পারে এবং যেমন নিফটি কাজ করতে পারে। এবং এছাড়াও আছে systemd, এটি ধীরে ধীরে লিনাক্সের ইউনিক্স অংশ ফাগোসাইটোসিং করছে। systemdনিজস্ব লগিং মেকানিজম রয়েছে, তবে সেই গল্পটি অন্য কোনও ব্যক্তিকে জানাতে হবে। :)
* বিএসডি বিশ্বের সাথে পার্থক্য:
* বিএসডি তে নেই klogd(8), এবং /procহয় না (ওপেনবিএসডি তে) বা বেশিরভাগই অপ্রচলিত (ফ্রিবিএসডি এবং নেটবিএসডি তে)) syslogd(8)অক্ষর ডিভাইস থেকে কার্নেল বার্তা পড়ে /dev/klogএবং কার্নেল নামগুলি ডিকোড করতে dmesg(1)ব্যবহার /dev/kmemকরে। কেবল ওপেনবিএসডি-তে রয়েছে একটি /dev/log। ফ্রিবিএসডি দুটি ইউনিক্স ডোমেন সকেট /var/run/logএবং var/rub/logprivপরিবর্তে ব্যবহার করে এবং নেটবিএসডি এর একটি /var/run/log।
rsyslogব্যবহার করছে না klogd(8)কারণ এর শিকড়গুলি আগের দিকে ফিরে গেছে, কারণ এটি সম্প্রতি এটি সরিয়ে দেওয়ার বিষয়ে একটি সুস্পষ্ট সিদ্ধান্ত নিয়েছে। আমার স্মৃতি যদিও ব্যর্থ হতে পারে। যাইহোক, যেমন আমি বলেছিলাম, আমি কেবল "ক্লাসিক" লগিং কভার করার চেষ্টা করছিলাম।
rsyslogdচলমান এবং এক উবুন্টু 12.04 সঙ্গে syslog-ngচলমান এবং তারা উভয় দায়ের ছিল /proc/kmsgঅনুযায়ী খোলা lsof, অর্থাত্ klogdব্যবহার করা হয়। আরেকটি আকর্ষণীয় বিষয় আমি লক্ষ্য করেছিলাম যে /proc/kmsgসিসলোগ ডেমন চলমান না থাকলে লগ বার্তাগুলি ফাইলে সংরক্ষণ করা হয় এবং উদাহরণস্বরূপ catবা পাঠ্য সম্পাদক হিসাবে কেউ সেগুলি দেখতে পারে । তবে এই বার্তাগুলি একবারে দেখা সম্ভব কারণ তারা দেখার পরে অদৃশ্য হয়ে যায়। শেষ কিন্তু অন্তত না, কার্যকর করা ফাইলের dmesgবিষয়বস্তু সাফ করে না /proc/kmsg।
/proc/kmsgকোনও নিয়মিত ফাইল নয়, সেখানে "সঞ্চিত" কিছুই নেই, বরং এটি কেবল কার্নেলের রিং বাফারের একটি দৃশ্য। আপনার সাথে এটা পড়তে পারেন catঅবিকল কারণ আপনি কোন আছে klogd(8)চলমান (আপনি চালানো উচিত klogd(8), cat /proc/kmsgব্লক হবে)। পরিবর্তে dmesg(1)থেকে বার্তা পড়ে ; এবং আপনি যদি এটি বলেন তবে এটি বাফারটিও সাফ করতে পারে। /dev/kmsg/proc/kmsg
systemd has its own logging mechanisms, but that story would have to be told by somebody else. :)- দয়া করে আপনি বলুন, আপনি প্রতিভা পেয়েছেন :-)
অন্য উত্তরটি ব্যাখ্যা করে, যেমন এর লেখক বলেছেন, লিনাক্সে "ক্লাসিক লগিং"। আজকাল প্রচুর সিস্টেমে জিনিসগুলি এমনভাবে কাজ করে না।
কার্নেল প্রক্রিয়া পরিবর্তিত হয়েছে।
কার্নেল একটি ইন-মেমরি বাফারে আউটপুট উত্পন্ন করে। অ্যাপ্লিকেশন সফ্টওয়্যার দুটি উপায়ে এটি অ্যাক্সেস করতে পারে। লগিং সাবসিস্টেম সাধারণত সিউডো-ফিফোর নাম হিসাবে এটি অ্যাক্সেস করে /proc/kmsg। লগ তথ্যের এই উত্সটি কার্যকরভাবে লগ পাঠকদের মধ্যে ভাগ করা যায় না, কারণ এটি একবারে পঠিত। যদি একাধিক প্রক্রিয়া এটি ভাগ করে নেয় তবে সেগুলি প্রতিটি কার্নেল লগ ডেটা স্ট্রিমের কেবল একটি অংশ পায়। এটি কেবল পঠনযোগ্য।
এটি অ্যাক্সেসের অন্য উপায়টি হ'ল নতুন /dev/kmsgঅক্ষরের ডিভাইস। এটি একটি পঠন-লিখন ইন্টারফেস যা একাধিক ক্লায়েন্ট প্রক্রিয়াগুলির মধ্যে ভাগ করে নেওয়া যায়। যদি একাধিক প্রক্রিয়া এটিকে ভাগ করে দেয় তবে তারা সকলেই একে অপরের দ্বারা প্রভাবিত না হয়ে একই সম্পূর্ণ ডেটা স্ট্রিমটি পড়ে। যদি তারা এটি লেখার অ্যাক্সেসের জন্য খোলেন, তারা কার্নেলের লগ স্ট্রিমে বার্তাগুলিও ইনজেক্ট করতে পারে, যেমন সেগুলি কার্নেল দ্বারা উত্পাদিত হয়েছিল।
/proc/kmsgএবং /dev/kmsgএকটি অ আরএফসি-5424 ফর্মে লগ ডেটা সরবরাহ করুন।
অ্যাপ্লিকেশন পরিবর্তন হয়েছে।
জিএনইউ সি লাইব্রেরির syslog()ফাংশন AF_LOCALনামের একটি ডেটাগ্রাম সকেটের সাথে সংযোগ স্থাপন /dev/logএবং এতে লগ এন্ট্রি লেখার মূল প্রয়াসে attempts (বিএসডি সি লাইব্রেরির syslog()ক্রিয়াকলাপটি আজকাল /var/run/logসকেটের নাম হিসাবে ব্যবহার করে এবং /var/run/logprivপ্রথমে চেষ্টা করে )) অ্যাপ্লিকেশনগুলির অবশ্যই এটি সরাসরি করার জন্য তাদের নিজস্ব কোড থাকতে পারে। লাইব্রেরির ফাংশনটি কেবল কোড (খোলার জন্য, সংযোগ করতে, লিখতে এবং একটি সকেট বন্ধ করার জন্য) অ্যাপ্লিকেশনটির নিজস্ব প্রক্রিয়া প্রসঙ্গে নির্ধারিত হয়।
মেশিনে কোনও AF_INET/ AF_INET6ডাটাগ্রাম সকেটে যদি কেউ শুনছেন তবে অ্যাপ্লিকেশনগুলি কোনও স্থানীয় আরএফসি 5426 সার্ভারে ইউডিপির মাধ্যমে আরএফসি 5424 বার্তা পাঠাতে পারে ।
গত দুই দশক ধরে ডেমোনটোলস বিশ্বের চাপের জন্য ধন্যবাদ, প্রচুর ডেমন এমন একটি মোডে চলমান সমর্থন করে যেখানে তারা জিএনইউ syslog()সি লাইব্রেরি ফাংশন বা ইউডিপি সকেট ব্যবহার করে না , তবে কেবলমাত্র তাদের লগের ডেটাগুলিকে স্ট্যান্ডার্ড ত্রুটির বাইরে থুতু দেয় the সাধারণ ইউনিক্স ফ্যাশন।
টুলসেটের ডেমন্টোলস পরিবারের সাথে লগ ইন করার ক্ষেত্রে অনেক নমনীয়তা রয়েছে। তবে সাধারণভাবে পুরো পরিবার জুড়েই ধারণাটি হ'ল প্রতিটি "প্রধান" ড্যামনের একটি "লগিং" ডমন থাকে। "মুখ্য" ডেমোনগুলি নন-ড্যামন প্রক্রিয়াগুলির মতোই কাজ করে এবং তাদের লগ বার্তাগুলিকে স্ট্যান্ডার্ড ত্রুটি (বা স্ট্যান্ডার্ড আউটপুট) এ লেখেন, যা সার্ভিস ম্যানেজমেন্ট সাবসিস্টেম একটি পাইপের মাধ্যমে সংযোগ স্থাপনের ব্যবস্থা করে (যা এটি উন্মুক্ত রাখে যাতে লগ ডেটা হারিয়ে না যায়) "লগিং" ড্যামনের স্ট্যান্ডার্ড ইনপুটটিতে একটি পরিষেবা পুনঃসূচনা করুন)।
সমস্ত "লগিং" ডমন একটি প্রোগ্রাম চালায় যা কোথাও লগ ইন করে । সাধারণত এই প্রোগ্রাম মত কিছু multilogবা cyclogযে তার মান ইনপুট থেকে পড়ে এবং লিখেছেন (ন্যানোসেকেন্ড timestamped) লগ ইন করুন একটি কঠোরভাবে আকার-টুপিওয়ালা, স্বয়ংক্রিয়ভাবে আবর্তিত, একচেটিয়া-রাইট, ডিরেক্টরির মধ্যে ফাইল। সাধারণত, এই ডায়মোনগুলি সমস্ত স্বতন্ত্র নিবেদিত অনিবদ্ধ ব্যবহারকারী অ্যাকাউন্টগুলির অধীনে চলে।
সুতরাং এক একটি সম্পূর্ণরূপে বিতরণ লগিং সিস্টেমের সাথে শেষ হয়, প্রতিটি পরিষেবার লগ ডেটা পৃথকভাবে প্রক্রিয়া করা হয়।
এক করতে ভালো কিছু চালানো klogdবা syslogdবা rsyslogdএকটি daemontools পরিবার পরিষেবা পরিচালন করেন। কিন্তু ডেমনটোলস বিশ্ব বহু বছর আগে বুঝতে পেরেছিল যে "লগিং" ডেমনের সাহায্যে পরিষেবা পরিচালনার কাঠামো একটি সহজ ফ্যাশনে কাজগুলি করতে বেশ ঝরঝরে .ণ দেয়। সমস্ত লগ স্ট্রিমগুলিকে এক বিশাল মেশ-ম্যাসে ফ্যান করার দরকার নেই, লগের ডেটা পার্স করুন, এবং তারপরে স্ট্রিমগুলি ফ্যান করে আলাদা লগ ফাইলগুলি পৃথক করে; এবং তারপরে (কিছু ক্ষেত্রে) পাশের একটি অবিশ্বাস্য বাহ্যিক লগ রোটেশন প্রক্রিয়াটি বল্ট করুন। এর স্ট্যান্ডার্ড লগ পরিচালনার অংশ হিসাবে ডিমনটোলস-ফ্যামিলি কাঠামো ইতিমধ্যে লগ রোটেশন, লগফিল রচনা এবং স্ট্রিম বিভাজন করে।
তদ্ব্যতীত: সমস্ত পরিষেবা জুড়ে সাধারণ সরঞ্জামগুলির সাথে সুবিধাগুলি বাদ দেওয়ার চেইন-লোডিং মডেলটির অর্থ হ'ল লগিং প্রোগ্রামগুলিতে অতিরিক্ত ব্যবহারকারীর সুবিধার কোনও দরকার নেই; এবং ইউসিএসপিআই মডেলের অর্থ হল যে তাদের কেবল স্ট্রিম বনাম ডেটাগ্রাম ট্রান্সপোর্টের মত পার্থক্য সম্পর্কে যত্ন নেওয়া দরকার।
নশ টুলসেট এর উদাহরণ দেয়। যতক্ষণ এক করতে চালানোর rsyslogdনীচে বাক্সের বাইরে, এবং মাত্র কার্নেল পরিচালনা, /run/logএবং এর ফলে UDP লগ ইন করুন পুরাতন ভাবে ইনপুট; এটা এছাড়াও উপলব্ধ আরো "daemontools নেটিভ 'এসব কথা লগ-ইন করার উপায়:
klogdপরিষেবা যা পড়তে পারে /proc/kmsgএবং সহজভাবে লিখতে পারে যে লগ স্ট্রিমটিকে তার প্রমিত ত্রুটিতে দেখায়। এটি নামের একটি সাধারণ প্রোগ্রাম দ্বারা সম্পন্ন হয় klog-read। সম্পর্কিত লগিং ড্যামন একটি /var/log/sv/klogdলগ ডিরেক্টরিতে তার স্ট্যান্ডার্ড ইনপুটটিতে লগ স্ট্রিমটি ফিড করে ।local-syslog-readপরিষেবা যা /dev/log( /run/logবিএসডিগুলিতে) থেকে ডেটাগ্রাম পড়ে এবং কেবল সেই লগ স্ট্রিমটিকে তার প্রমিত ত্রুটিতে লেখায়। এটি একটি প্রোগ্রাম দ্বারা সম্পন্ন হয় syslog-read। সম্পর্কিত লগিং ড্যামন একটি /var/log/sv/local-syslog-readলগ ডিরেক্টরিতে তার স্ট্যান্ডার্ড ইনপুটটিতে লগ স্ট্রিমটি ফিড করে ।udp-syslog-readপরিষেবা যা ইউডিপি সিসলোগ বন্দরে শোনায়, এতে কী পাঠানো হয় তা পড়ে এবং কেবল সেই লগ স্ট্রিমটিকে তার প্রমিত ত্রুটিতে লেখায়। আবার, প্রোগ্রামটি হয় syslog-read। সম্পর্কিত লগিং ড্যামন একটি /var/log/sv/udp-syslog-readলগ ডিরেক্টরিতে তার স্ট্যান্ডার্ড ইনপুটটিতে লগ স্ট্রিমটি ফিড করে ।local-priv-syslog-readপরিষেবা যা থেকে ডেটাগ্রামগুলি পড়ে /run/logprivএবং কেবল সেই লগ স্ট্রিমটিকে তার প্রমিত ত্রুটিতে লেখায়। আবার, প্রোগ্রামটি হয় syslog-read। সম্পর্কিত লগিং ড্যামন একটি /var/log/sv/local-priv-syslog-readলগ ডিরেক্টরিতে তার স্ট্যান্ডার্ড ইনপুটটিতে লগ স্ট্রিমটি ফিড করে ।এই টুলসেটটি এমন একটি সরঞ্জামও নিয়ে আসে যা export-to-rsyslogএক বা একাধিক লগ ডিরেক্টরি (নন-ইন্টারফেসিভ লগ কার্সার সিস্টেম ব্যবহার করে ) নিরীক্ষণ করতে পারে এবং নেটওয়ার্কের মাধ্যমে আরএফসি 5424 ফর্মের নতুন এন্ট্রিগুলি একটি নির্ধারিত আরএফসি 5426 সার্ভারে প্রেরণ করতে পারে।
systemd এর একটি একক একক লগ পরিচালনা প্রোগ্রাম রয়েছে systemd-journald,। এটি সিস্টেমড দ্বারা পরিচালিত একটি পরিষেবা হিসাবে চলে।
/dev/kmsgকার্নেল লগ ডেটার জন্য পড়তে পারে ।/dev/log(একটি প্রতীকী লিঙ্ক /run/systemd/journal/dev-log) পড়ে readssyslog()AF_LOCALসিস্টেম /run/systemd/journal/stdout-পরিচালিত পরিষেবাদি থেকে আসা লগ ডেটার জন্য স্ট্রিম সকেটে শোনা ।AF_LOCALডেটাগ্রাম সকেটে শোনা যায় ।/run/systemd/journal/socketsd_journal_sendv()/run/log/journal/বা এর মধ্যে লিখেছে /var/log/journal/।AF_LOCALডেটাগ্রামের সকেটের সাথে (ক্লায়েন্ট হিসাবে) সংযুক্ত করতে পারে /run/systemd/journal/syslogতবে সেখানে জার্নাল ডেটা লেখেন, যদি সিসলগে ফরোয়ার্ড কনফিগার করা থাকে।/dev/kmsgপ্রক্রিয়াটি ব্যবহার করে কার্নেল বাফারে জার্নাল ডেটা লিখে ।এই প্রোগ্রামটি ক্র্যাশ হয়ে গেলে বা পরিষেবাটি বন্ধ হয়ে গেলে সিস্টেমে খারাপ জিনিসগুলি ঘটে।
সিস্টেমেড নিজেই /run/systemd/journal/stdoutসকেটের সাথে সংযুক্ত হওয়ার জন্য (কিছু) পরিষেবাগুলির স্ট্যান্ডার্ড আউটপুট এবং ত্রুটির ব্যবস্থা করে । সুতরাং সাধারণ ফ্যাশনে স্ট্যান্ডার্ড ত্রুটিতে লগইন করা ডেমনগুলি তাদের আউটপুট জার্নালে প্রেরণ করে।
এটি সম্পূর্ণরূপে ক্লগড, সিসলগড, সিসলগ-এনজি, এবং আরএসিস্লাগডকে সরবরাহ করে।
এগুলি এখন সিস্টেম-নির্দিষ্ট হওয়া দরকার। একটি সিস্টেমযুক্ত সিস্টেমে তারা সার্ভারের শেষ হতে পারে না /dev/log। পরিবর্তে, তারা দুটি পদ্ধতির একটি গ্রহণ করে:
/run/systemd/journal/syslog, যা (যদি আপনি মনে করেন) এর systemd-journaldসাথে জার্নাল ডেটা সংযোগ স্থাপন এবং লেখার চেষ্টা করে। কয়েক বছর আগে, কেউ এটি করতে rsyslogd এর imuxsockইনপুট পদ্ধতিটি কনফিগার করেছিল ।imjournalইনপুট পদ্ধতিটি কনফিগার করে ।