আপনি কীভাবে RHEL7 এ ক্র্যাশ এবং একটি রিবুটের মধ্যে পার্থক্য করতে পারেন?


10

কোনও RHEL7 সার্ভারটি systemctl (অথবা পুনরায় বুট / শাটডাউন উপকরণ) মাধ্যমে পুনরায় বুট করা হয়েছিল কিনা, বা সার্ভারটি ক্র্যাশ হয়েছে কিনা তা নির্ধারণ করার কোনও উপায় আছে কি? প্রাক- last -x runlevelসিস্টেমযুক্ত এটি নির্ধারণ করা মোটামুটি সহজ ছিল , তবে RHEL7 এর সাথে এটি এতটা পরিষ্কার নয়।

উত্তর:


4

এটি করার একাধিক উপায় রয়েছে, তবে আমি ভাবতে পারি সেরা 4 টির জন্য cover (সম্পাদনা: আমি redhat.com এ পাবলিক আর্টিকেল হিসাবে এর একটি ক্লিন-আপ সংস্করণ প্রকাশ করেছি See দেখুন: আরএইচইএল in এর ক্র্যাশ এবং কৌতূহলী পুনরায় বুটের মধ্যে কীভাবে পার্থক্য করা যায় ))

(1) নিরীক্ষিত লগগুলি

নিরীক্ষণ আশ্চর্যজনক। এটি যাচাই করে তা বিভিন্ন ইভেন্ট দেখতে পারে ausearch -m। সমস্যাটিতে এপ্রোপস, এটি সিস্টেম শাটডাউন এবং সিস্টেম বুট লগ করে, যাতে আপনি কমান্ডটি ব্যবহার করতে পারেন ausearch -i -m system_boot,system_shutdown | tail -4। এই রিপোর্ট একটি যদি SYSTEM_SHUTDOWN একটি দ্বারা অনুসরণ SYSTEM_BOOT , সব ঠিক; তবে, যদি এটি পরপর 2 টি SYSTEM_BOOT লাইনগুলি প্রতিবেদন করে , তবে স্পষ্টতই সিস্টেমটি নিচের উদাহরণের মতো মনোযোগ সহকারে শাটডাউন করেনি:

[root@a72 ~]# ausearch -i -m system_boot,system_shutdown | tail -4
----
type=SYSTEM_BOOT msg=audit(09/20/2016 01:10:32.392:7) : pid=657 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success' 
----
type=SYSTEM_BOOT msg=audit(09/20/2016 01:11:41.134:7) : pid=656 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success' 

(2) সর্বশেষ -x

উপরের মত একই, তবে সাধারণ last -n2 -x shutdown rebootকমান্ড দিয়ে। সিস্টেম ক্র্যাশ হয়েছে যেখানে উদাহরণ:

[root@a72 ~]# last -n2 -x shutdown reboot
reboot   system boot  3.10.0-327.el7.x Tue Sep 20 01:11 - 01:20  (00:08)    
reboot   system boot  3.10.0-327.el7.x Tue Sep 20 01:10 - 01:20  (00:09)    

বা যেখানে সিস্টেমের একটি সুদৃশ্য রিবুট ছিল:

[root@a72 ~]# last -n2 -x shutdown reboot
reboot   system boot  3.10.0-327.el7.x Tue Sep 20 01:21 - 01:21  (00:00)    
shutdown system down  3.10.0-327.el7.x Tue Sep 20 01:21 - 01:21  (00:00)    

(3) আপনার নিজস্ব পরিষেবা ইউনিট তৈরি করুন

এটি আইএমএইচও সর্বোত্তম পন্থা কারণ আপনি যা খুশি তাই এটিকে উপযুক্ত করতে পারেন। এটি করার জন্য এক মিলিয়ন উপায় রয়েছে। এখানে আমি স্রেফ তৈরি করেছি। এই পরবর্তী পরিষেবাটি কেবল শাটডাউনে চলবে।

[root@a72 ~]# cat /etc/systemd/system/set_gracefulshutdown.service
[Unit]
Description=Set flag for graceful shutdown
DefaultDependencies=no
RefuseManualStart=true
Before=shutdown.target

[Service]
Type=oneshot
ExecStart=/bin/touch /root/graceful_shutdown

[Install]
WantedBy=shutdown.target
[root@a72 ~]# systemctl enable set_gracefulshutdown.service 
Created symlink from /etc/systemd/system/shutdown.target.wants/set_gracefulshutdown.service to /etc/systemd/system/set_gracefulshutdown.service.

তারপরে সিস্টেমটি বুট হয়ে গেলে, উপরের শাটডাউন পরিষেবার দ্বারা তৈরি ফাইলটি উপস্থিত থাকলে কেবল এই পরবর্তী পরিষেবাটি শুরু হবে।

[root@a72 ~]# cat /etc/systemd/system/check_graceful.service 
[Unit]
Description=Check if system booted after a graceful shutdown
ConditionPathExists=/root/graceful_shutdown
RefuseManualStart=true
RefuseManualStop=true

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/bin/rm /root/graceful_shutdown

[Install]
WantedBy=multi-user.target
[root@a72 ~]# systemctl enable check_graceful
Created symlink from /etc/systemd/system/multi-user.target.wants/check_graceful.service to /etc/systemd/system/check_graceful.service.

সুতরাং যে কোনও সময় আমি যাচাই করে দেখতে পারি যে পূর্ববর্তী বুটটি কর্ণফুল শটডাউন করার পরে করা হয়েছিল systemctl is-active check_graceful, উদাহরণস্বরূপ:

[root@a72 ~]# systemctl is-active check_graceful && echo YAY || echo OH NOES
active
YAY
[root@a72 ~]# systemctl status check_graceful
● check_graceful.service - Check if system booted after a graceful shutdown
   Loaded: loaded (/etc/systemd/system/check_graceful.service; enabled; vendor preset: disabled)
   Active: active (exited) since Tue 2016-09-20 01:10:32 EDT; 20s ago
  Process: 669 ExecStart=/bin/rm /root/graceful_shutdown (code=exited, status=0/SUCCESS)
 Main PID: 669 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/check_graceful.service

Sep 20 01:10:32 a72.example.com systemd[1]: Starting Check if system booted after a graceful shutdown...
Sep 20 01:10:32 a72.example.com systemd[1]: Started Check if system booted after a graceful shutdown.

বা এখানে একটি কুরুচিপূর্ণ বন্ধের পরে:

[root@a72 ~]# systemctl is-active check_graceful && echo YAY || echo OH NOES
inactive
OH NOES
[root@a72 ~]# systemctl status check_graceful
● check_graceful.service - Check if system booted after a graceful shutdown
   Loaded: loaded (/etc/systemd/system/check_graceful.service; enabled; vendor preset: disabled)
   Active: inactive (dead)
Condition: start condition failed at Tue 2016-09-20 01:11:41 EDT; 16s ago
           ConditionPathExists=/root/graceful_shutdown was not met

Sep 20 01:11:41 a72.example.com systemd[1]: Started Check if system booted after a graceful shutdown.

(4) জার্নিটল

এটি উল্লেখযোগ্য যে আপনি যদি systemd-journaldঅবিচ্ছিন্ন জার্নাল রাখতে কনফিগার করেন তবে আপনি journalctl -b -1 -nপূর্বের বুটের শেষ কয়েকটি (ডিফল্টরূপে 10) লাইনগুলি দেখতে ( -b -2এটি এর আগে বুট, ইত্যাদি) ব্যবহার করতে পারেন। উদাহরণস্বরূপ যেখানে সিস্টেমটি করুণভাবে পুনরায় বুট হয়েছে:

[root@a72 ~]# mkdir /var/log/journal
[root@a72 ~]# systemctl -s SIGUSR1 kill systemd-journald
[root@a72 ~]# reboot
...
[root@a72 ~]# journalctl -b -1 -n
-- Logs begin at Tue 2016-09-20 01:01:15 EDT, end at Tue 2016-09-20 01:21:33 EDT. --
Sep 20 01:21:19 a72.example.com systemd[1]: Stopped Create Static Device Nodes in /dev.
Sep 20 01:21:19 a72.example.com systemd[1]: Stopping Create Static Device Nodes in /dev...
Sep 20 01:21:19 a72.example.com systemd[1]: Reached target Shutdown.
Sep 20 01:21:19 a72.example.com systemd[1]: Starting Shutdown.
Sep 20 01:21:19 a72.example.com systemd[1]: Reached target Final Step.
Sep 20 01:21:19 a72.example.com systemd[1]: Starting Final Step.
Sep 20 01:21:19 a72.example.com systemd[1]: Starting Reboot...
Sep 20 01:21:19 a72.example.com systemd[1]: Shutting down.
Sep 20 01:21:19 a72.example.com systemd-shutdown[1]: Sending SIGTERM to remaining processes...
Sep 20 01:21:19 a72.example.com systemd-journal[483]: Journal stopped

যদি আপনি এর মতো ভাল আউটপুট পান তবে স্পষ্টতই সিস্টেমটি দুর্দান্তভাবে বন্ধ হয়ে গেল। এটি বলেছিল, যখন খারাপ জিনিস ঘটে (সিস্টেম ক্র্যাশ হয়) তখন আমার অভিজ্ঞতায় এটি অত্যন্ত নির্ভরযোগ্য নয়। কখনও কখনও সূচকটি অদ্ভুত হয়ে যায়।


8

মজার কথা, আমি গত রাতে একটি সেন্টোস 7 সিস্টেম রিবুট করতে পেরেছি, এবং তাই দেখার জন্য আমার এটির একটি দুর্দান্ত লগ আছে।

ক্র্যাশ হওয়ার ক্ষেত্রে, ক্র্যাশের সময় এবং সিস্টেম পুনরায় আরম্ভের মধ্যে স্পষ্টতই কিছুই লগ হয় না।

একটি রিবুটের ক্ষেত্রে, এটি বেশ সুস্পষ্ট, যেমন আপনি সিস্টেমটি বন্ধ করতে সিস্টেমড যা কিছু করছেন তার প্রায় (প্রায়) লগইন পান।

এই জাতীয় একটি লগ এন্ট্রি আপনি বন্ধ বা সিঙ্গল-ইউজার মোডে যাওয়া ব্যতীত অন্য কোনও পরিস্থিতিতে দেখবেন না:

Jul 13 01:27:55 yaungol systemd: Stopped target Multi-User System.

আসলে কী লগ হয় তা দেখতে আপনি নিজের সিস্টেমটিকে রিবুট করতে পারেন।


1
আপনি বিশ্বাস করতে পারেন যে সেন্টোস 7 এটি লগ করে এবং আরএইচএল 7 এটি করে না? সেন্টস (এবং ফেডোরা) লগগুলিতে আমরা যা দেখেছি তার উপর ভিত্তি করে এটি ছিল আমাদের প্রাথমিক পদ্ধতির। আমরা যখন RHEL7 এ পরীক্ষা করেছি তখন কোনও ডাইস নেই।
kwb

1
@kwb একটি RHEL 7.2 সিস্টেম একবার দেখার পরে, হ্যাঁ, আমি এটি বিশ্বাস করি। আসলে, এটি প্রদর্শিত হয় যে লগ করা উচিত অনেকগুলি জিনিস লগ করা হচ্ছে না। আমি কেবল এটিই বলতে পারি: ডাব্লুটিএফ?
মাইকেল হ্যাম্পটন 20

আপনি ছেলেরা কী সম্পর্কে কথা বলছেন তা নিশ্চিত নয়। RHEL 7.0-7.2 এ সিস্টেমেড Stopping Multi-User Systemএবং Stopped target Multi-User Systemবার্তা উত্পন্ন করে ।
rsaw

@rsaw আমরা বার্তাগুলি উত্পন্ন হয়েছে তা ভালভাবেই অবগত। সমস্যাটি হ'ল তারা জার্নালে উপস্থিত হচ্ছেন না।
মাইকেল হ্যাম্পটন

@ মিশেলহ্যাম্পটন জার্নালটি ডিফল্টরূপে স্থির থাকে না। আপনি কেবলমাত্র আপনার বর্তমান বুট থেকে লগগুলি দেখতে পাচ্ছেন যদি না আপনি mkdir /var/log/journalবা স্পষ্টভাবে সেট আপ Storage=persistentকরেন /etc/systemd/journald.conf। আমি একটি পৃথক উত্তর পোস্ট।
rsaw

5

আমি উত্তরটি বিশেষত পছন্দ করি না তবে এটি উত্তর যা আমরা আরএইচ থেকে পেয়েছি। এটি অন্য কাউকে সাহায্য করার ক্ষেত্রে এটি এখানে পোস্ট করছি।

একটি সম্ভাব্য উপায় হ'ল গ্রিপ rsyslogdকরা /var/log/messages। একটি চমত্কার শাটডাউন হবে exiting on signal 15। একটি ক্রাশ হবে না।

tac /var/log/messages | grep 'rsyslogd.*start\|rsyslogd.*exit'

পরপর দুটি startলাইন ক্রাশ নির্দেশ করতে পারে। এবং এর startপরে exitএকটি পুনরায় বুট নির্দেশ করতে পারে।

দুর্ভাগ্যক্রমে এটি খারাপ ফলাফলও দিতে পারে যদি rsyslogd ডাউন হয়ে যায় বা পুনরায় বুট / ক্র্যাশের বাইরে পুনরায় চালু করা হয়।


খারাপ খেলুন রেড হ্যাট। অন্যান্য আচরণ রয়েছে যা exiting on signal 15পুনরায় বুট করার পাশাপাশি একই হবে । একটি সাধারণ service rsyslog restartএছাড়াও বার্তা exiting on signal 15বার্তায় ফলাফল ।
স্টিফান লাসিউইস্কি

এটি একটি বৈধ উত্তর, তবে যে কেউ রেড হ্যাট প্রযুক্তিগত সহায়তায় কাজ করে, আমি যা করতাম তা নয়। আমার উত্তর দেখুন।
rsaw

1

এই "সুতনু হরতাল" জন্য ধারাবাহিকভাবে কাজ বলে মনে হয় ( shutdown, reboot, systemctl) পাশাপাশি "ক্র্যাশ" (পাওয়ার বন্ধ, পুনরায় সেট, যেমন echo c > /proc/sysrq-trigger):

last -x | grep 'reboot\|shutdown'

একটি rebootরেখার পরে একটি shutdownলাইন একটি "ক্রেফুল শটডাউন" নির্দেশ করে। দুটি rebootলাইন একটি "ক্রাশ" নির্দেশ করে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.