Panduan Pemecahan Masalah Umum GNU/Linux untuk Pemula

Panduan Pemecahan Masalah Umum GNU/Linux untuk Pemula

Dalam panduan ini, tujuan kami adalah belajar tentang alat dan lingkungan yang disediakan oleh sistem GNU/Linux yang khas untuk dapat memulai pemecahan masalah bahkan pada mesin yang tidak dikenal.
Dalam tutorial ini Anda akan belajar:

  • Cara Memeriksa Ruang Disk
  • Cara memeriksa ukuran memori
  • Cara memeriksa beban sistem
  • Bagaimana menemukan dan membunuh proses sistem
  • Cara Log Pengguna Untuk Menemukan Informasi Pemecahan Masalah Sistem yang Relevan
Panduan Pemecahan Masalah Umum GNU/Linux untuk Pemula

Persyaratan dan konvensi perangkat lunak yang digunakan

Persyaratan Perangkat Lunak dan Konvensi Baris Perintah Linux
Kategori Persyaratan, konvensi atau versi perangkat lunak yang digunakan
Sistem Ubuntu 20.04, Fedora 31
Perangkat lunak N/a
Lainnya Akses istimewa ke sistem Linux Anda sebagai root atau melalui sudo memerintah.
Konvensi # - mensyaratkan perintah linux yang diberikan untuk dieksekusi dengan hak istimewa root baik secara langsung sebagai pengguna root atau dengan menggunakan sudo memerintah
$ - mensyaratkan perintah Linux yang diberikan untuk dieksekusi sebagai pengguna biasa

Perkenalan

Sementara GNU/Linux terkenal karena stabilitas dan ketahanannya, ada kasus di mana ada sesuatu yang salah. Sumber masalah mungkin baik internal dan eksternal. Misalnya, mungkin ada proses kerusakan yang berjalan pada sistem yang memakan sumber daya, atau hard drive lama mungkin salah, menghasilkan kesalahan I/O yang dilaporkan.

Bagaimanapun, kita perlu tahu ke mana harus mencari dan apa yang harus dilakukan untuk mendapatkan informasi tentang situasi, dan panduan ini mencoba memberikan hampir semua hal - cara umum untuk mendapatkan gagasan itu salah. Resolusi masalah apa pun dimulai dengan mengetahui tentang masalah ini, menemukan detailnya, menemukan akar penyebabnya, dan menyelesaikannya. Seperti halnya tugas apa pun, GNU/Linux menyediakan alat yang tak terhitung jumlahnya untuk membantu kemajuan, ini juga terjadi dalam pemecahan masalah. Beberapa tips dan metode berikut hanyalah beberapa yang umum yang dapat digunakan pada banyak distribusi dan versi.

Gejala

Misalkan kami memiliki laptop yang bagus yang kami kerjakan. Ini menjalankan Ubuntu, Centos atau Red Hat Linux terbaru di atasnya, dengan pembaruan selalu ada untuk menjaga semuanya tetap segar. Laptop ini untuk penggunaan umum sehari -hari: kami memproses email, mengobrol, menelusuri internet, mungkin menghasilkan beberapa spreadsheet di atasnya, dll. Tidak ada yang istimewa yang diinstal, suite kantor, browser, klien email, dan sebagainya. Dari satu hari ke hari lain, tiba -tiba mesin menjadi sangat lambat. Kami sudah mengerjakannya selama sekitar satu jam, jadi itu bukan masalah setelah boot. Apa yang terjadi… ?



Memeriksa Sumber Daya Sistem

GNU/Linux tidak menjadi lambat tanpa alasan. Dan kemungkinan besar akan memberi tahu kita di mana itu menyakitkan, selama itu bisa menjawab. Seperti halnya program apa pun yang berjalan di komputer, sistem operasi menggunakan sumber daya sistem, dan dengan mereka yang berjalan tebal, operasi harus menunggu sampai ada cukup banyak dari mereka untuk melanjutkan. Ini memang akan menyebabkan respons menjadi lebih lambat dan lebih lambat, jadi jika ada masalah, selalu berguna untuk memeriksa keadaan sumber daya sistem. Secara umum sumber daya sistem kami (lokal) terdiri dari disk, memori, dan CPU. Mari kita periksa semuanya.

Ruang disk

Jika sistem operasi yang berjalan tidak ada di luar ruang disk, itu berita buruk. Karena layanan yang berjalan tidak dapat menulis file log mereka, mereka sebagian besar akan macet jika berjalan, atau tidak akan mulai jika disk sudah penuh. Terlepas dari file log, soket, dan file PID (pengidentifikasi proses) perlu ditulis pada disk, dan sementara ini berukuran kecil, jika sama sekali tidak ada ruang lagi, ini tidak dapat dibuat.

Untuk memeriksa ruang disk yang tersedia yang dapat kami gunakan df di terminal, dan tambahkan -H argumen, untuk melihat hasilnya dibulatkan ke megabytes dan gigabytes. Bagi kami entri yang diminati adalah volume yang menggunakan% 100%. Itu berarti volume yang dimaksud penuh. Contoh output berikut menunjukkan bahwa kami baik -baik saja tentang ruang disk:

$ df -H ukuran sistem file digunakan tersedia digunakan% dipasang pada devtmpfs 1.8g 0 1.8g 0% /dev tmpfs 1.8g 0 1.8g 0% /dev /shm tmpfs 1.8g 1.3m 1.8g 1% /run /dev /mapper /lv-root 49g 11g 36g 24% /tmpfs 1.8g 0 1.8g 0% /tmp /dev /sda2 976m 261m 649m 29% /boot /dev /mapper /lv-home 173g 18g 147g 11% /rumah tmpfs 361m 4.0k 361m 1%/run/user/1000
Menyalin

Jadi kami memiliki ruang di disk. Perhatikan bahwa dalam kasus laptop lambat kami, kelelahan ruang disk tidak mungkin menjadi akar penyebabnya. Saat disk penuh, program akan macet atau tidak akan dimulai sama sekali. Dalam kasus ekstrem, bahkan login akan gagal setelah boot.

Penyimpanan

Memori adalah sumber daya yang vital juga, dan jika kita kekurangan, sistem operasi mungkin perlu menulis potongan yang saat ini tidak digunakan untuk disk sementara (juga disebut "swap out") untuk memberikan memori yang dibebaskan ke proses berikutnya, lalu baca itu kembali saat proses memiliki konten yang ditukar membutuhkannya lagi. Seluruh metode ini disebut swapping, dan memang akan memperlambat sistem, karena menulis dan membaca ke dan dari disk jauh lebih lambat daripada bekerja di dalam ram.

Untuk memeriksa penggunaan memori, kami memiliki yang berguna bebas Perintah bahwa kita dapat menambahkan argumen untuk melihat hasilnya di megabyte (-M) atau gigabytes (-G):

$ gratis -m total digunakan buff bersama gratis/cache tersedia mem: 7886 3509 1547 1231 2829 2852 SWAP: 8015 0 8015
Menyalin

Dalam contoh di atas kita memiliki 8 GB memori, 1,5 GB gratis, dan sekitar 3 GB di cache. Itu bebas Perintah juga menyediakan keadaan menukar: Dalam hal ini benar -benar kosong, artinya sistem operasi tidak perlu menulis konten memori apa pun ke disk sejak startup, bahkan pada beban puncak tidak ada. Ini biasanya berarti kami memiliki lebih banyak memori yang sebenarnya kami gunakan. Jadi mengenai ingatan kita lebih dari baik, kita punya banyak.



Beban sistem

Saat prosesor melakukan perhitungan yang sebenarnya, kehabisan waktu prosesor untuk menghitung dapat kembali mengakibatkan memperlambat sistem. Perhitungan yang diperlukan harus menunggu sampai prosesor mana pun memiliki waktu luang untuk menghitungnya. Cara termudah untuk melihat beban pada prosesor kami adalah uptime memerintah:

$ uptime 12:18:24 UP 4:19, 8 Pengguna, Load Average: 4,33, 2,28, 1,37
Menyalin

Tiga angka setelah rata -rata beban berarti rata -rata dalam 1, 5 dan 15 menit terakhir. Dalam contoh ini mesin memiliki 4 core CPU, jadi kami mencoba menggunakan lebih dari kapasitas kami yang sebenarnya. Perhatikan juga bahwa nilai -nilai historis menunjukkan bahwa beban naik secara signifikan dalam beberapa menit terakhir. Mungkin kami menemukan pelakunya?

Proses konsumen teratas

Mari kita lihat seluruh gambaran CPU dan konsumsi memori, dengan proses teratas menggunakan sumber daya ini. Kami dapat mengeksekusi atas Perintah untuk melihat sistem memuat (dekat) waktu nyata:

Memeriksa proses konsumen teratas.

Baris atas pertama identik dengan output uptime, Selanjutnya kita dapat melihat nomornya jika tugas berjalan, tidur, dll. Perhatikan jumlah proses zombie (defungsi); Kasus ini 0, tetapi jika akan ada beberapa proses di negara bagian zombie, mereka harus diselidiki. Baris berikutnya menunjukkan beban pada CPU dalam persentase, dan persentase akumulasi tepatnya Apa Prosesornya sibuk. Di sini kita dapat melihat bahwa prosesor sibuk melayani program ruang pengguna.

Berikutnya adalah dua baris yang bisa terbiasa dari bebas output, penggunaan memori jika sistem. Di bawah ini adalah proses teratas, diurutkan berdasarkan penggunaan CPU. Sekarang kita bisa melihat apa yang memakan prosesor kita, itu adalah firefox dalam kasus kita.

Memeriksa proses

Bagaimana saya tahu itu, karena proses konsumsi teratas ditampilkan sebagai "konten web" di saya atas keluaran? Dengan menggunakan ps Untuk menanyakan tabel proses, menggunakan PID yang ditampilkan di sebelah proses teratas, yang ada dalam kasus ini 5785:

$ ps -ef | GREP 5785 | grep -v "grep" Sandmann 5785 2528 19 18:18 tty2 00:00:54/usr/lib/firefox/firefox -contentproc -Childid 13 -isforbrowser -prefslen 9825 -prefmapsize 226230 -parentbuild 2020077 -AppapSize 226230 -parentBuild 2020077 -AppapSize 226230 -parentBuild 20200771942194214 Firefox/Browser 2528 True Tab

Dengan langkah ini kami menemukan akar penyebab situasi kami. Firefox memakan waktu CPU kami sampai saat sistem kami mulai menjawab tindakan kami lebih lambat. Ini belum tentu kesalahan browser,
Karena Firefox dirancang untuk menampilkan halaman dari World Wide Web: untuk membuat masalah CPU untuk tujuan demonstrasi, yang saya lakukan hanyalah membuka beberapa lusin halaman uji stres dalam tab yang berbeda dari browser ke titik kekurangan CPU permukaan. Jadi saya tidak perlu menyalahkan browser saya, tetapi saya sendiri untuk membuka halaman haus sumber daya dan membiarkannya berjalan secara paralel. Dengan menutup beberapa, CPU saya
Penggunaan kembali normal.

Menghancurkan proses

Masalah dan solusinya terungkap di atas, tetapi bagaimana jika saya tidak dapat mengakses browser untuk menutup beberapa tab? Katakanlah sesi grafis saya terkunci dan saya tidak dapat masuk kembali, atau seorang jenderal
Proses yang menjadi liar bahkan tidak memiliki antarmuka di mana kita dapat mengubah perilakunya? Dalam kasus seperti itu kita dapat mengeluarkan penutupan proses oleh sistem operasi. Kita sudah tahu pid dari
proses nakal yang kami dapatkan ps, dan kita bisa menggunakan membunuh perintah untuk mematikannya:

$ Bunuh 5785

Proses yang berperingkat baik akan keluar, beberapa mungkin tidak. Jika demikian, tambahkan -9 Bendera akan memaksa penghentian proses:

$ kill -9 5785

Namun perhatikan bahwa ini dapat menyebabkan kehilangan data, karena prosesnya tidak punya waktu untuk menutup file yang dibuka atau menyelesaikannya. Hasilnya untuk disk sama sekali. Namun dalam kasus beberapa tugas yang berulang, stabilitas sistem mungkin lebih diprioritaskan daripada kehilangan sebagian hasil kami.



Menemukan informasi terkait

Berinteraksi dengan proses dengan semacam antarmuka tidak selalu terjadi, dan banyak aplikasi hanya memiliki perintah dasar yang mengontrol perilaku mereka - yaitu, mulai, berhenti, memuat ulang, dan semacamnya, karena pekerjaan internal mereka disediakan oleh konfigurasi mereka. Contoh di atas lebih dari desktop, mari kita lihat contoh sisi server, di mana kita memiliki masalah dengan server web.

Misalkan kita memiliki server web yang melayani beberapa konten untuk dunia. Ini populer, jadi itu bukan kabar baik ketika kami mendapat panggilan bahwa layanan kami tidak tersedia. Kami dapat memeriksa halaman web di browser hanya untuk mendapatkan pesan kesalahan yang mengatakan "tidak dapat terhubung". Mari kita lihat mesin yang menjalankan server web!

Memeriksa file log

Mesin kami yang menampung server web adalah kotak fedora. Ini penting karena jalur sistem file yang perlu kita ikuti. Fedora, dan semua varian topi merah lainnya menyimpan logefile webserver apache di jalur /var/log/httpd. Di sini kita dapat memeriksa catatan eror menggunakan melihat, tetapi tidak menemukan informasi terkait tentang apa masalahnya. Memeriksa log akses juga tidak menunjukkan masalah pada pandangan pertama, tetapi berpikir dua kali akan memberi kita petunjuk: pada server web dengan lalu lintas yang cukup baik, entri terakhir log akses harus sangat baru, tetapi entri terakhir sudah berumur satu jam. Kami tahu dengan pengalaman bahwa situs web mendapat pengunjung setiap menit.

Systemd

Penggunaan instalasi fedora kami Systemd sebagai sistem init. Mari kita minta informasi tentang server web:

# Systemctl Status httpd ● httpd.Layanan - Server HTTP Apache dimuat: dimuat (/usr/lib/systemd/system/httpd.melayani; dengan disabilitas; Preset Vendor: Dinonaktifkan) Drop-in:/usr/lib/systemd/system/httpd.melayani.D └─PHP-FPM.conf Active: Gagal (Hasil: Sinyal) Sejak Sun 2020-08-02 19:03:21 CEST; 3 menit 5s lalu Docs: Man: httpd.Layanan (8) Proses: 29457 execStart =/usr/sbin/httpd $ options -dForround (kode = kill, sinyal = kill) PID utama: 29457 (kode = kill, sinyal = kill) Status: "Total Permintaan: 0; idle /Pekerja sibuk 100/0; Permintaan/detik: 0; byte disajikan/detik: 0 b/detik "CPU: 74ms 02 Agustus 19:03:21 mywebserver1.foobar systemd [1]: httpd.Layanan: Proses Pembunuhan 29665 (N/A) Dengan Sigkill Sinyal. 02 Agustus 19:03:21 MyWebserver1.foobar systemd [1]: httpd.Layanan: Proses Pembunuhan 29666 (N/A) dengan Sigkill sinyal. 02 Agustus 19:03:21 MyWebserver1.foobar systemd [1]: httpd.Layanan: Proses Pembunuhan 29667 (N/A) dengan Sigkill sinyal. 02 Agustus 19:03:21 MyWebserver1.foobar systemd [1]: httpd.Layanan: Proses Pembunuhan 29668 (N/A) Dengan Sigkill Sinyal. 02 Agustus 19:03:21 MyWebserver1.foobar systemd [1]: httpd.Layanan: Proses Pembunuhan 29669 (N/A) Dengan Sigkill Sigan. 02 Agustus 19:03:21 MyWebserver1.foobar systemd [1]: httpd.Layanan: Proses Pembunuhan 29670 (N/A) Dengan Sigkill Sigan. 02 Agustus 19:03:21 MyWebserver1.foobar systemd [1]: httpd.Layanan: Proses Pembunuhan 29671 (N/A) Dengan Sigkill Sinyal. 02 Agustus 19:03:21 MyWebserver1.foobar systemd [1]: httpd.Layanan: Proses Pembunuhan 29672 (N/A) Dengan Sigkill Sinyal. 02 Agustus 19:03:21 MyWebserver1.foobar systemd [1]: httpd.Layanan: Proses Pembunuhan 29673 (N/A) Dengan Sigkill Sigan. 02 Agustus 19:03:21 MyWebserver1.foobar systemd [1]: httpd.Layanan: gagal dengan hasil 'sinyal'.
Menyalin

Contoh di atas sekali lagi sederhana, httpd Proses utama turun karena menerima sinyal membunuh. Mungkin ada sysadmin lain yang memiliki hak istimewa untuk melakukannya, jadi kami dapat memeriksa siapa
masuk (atau pada saat penutupan yang kuat dari server web), dan tanyakan padanya tentang masalah ini (pemberhentian layanan yang canggih akan kurang brutal, jadi pasti ada alasan di balik ini
peristiwa). Jika kami adalah satu -satunya admin di server, kami dapat memeriksa dari mana sinyal itu berasal - kami mungkin memiliki masalah pelanggaran, atau sistem operasi mengirim sinyal membunuh. Dalam kedua kasus itu kita dapat menggunakan
Logfiles server, karena ssh Login dicatat ke log keamanan (/var/log/aman Dalam kasus Fedora), dan ada juga entri audit yang dapat ditemukan di log utama (yang
/var/log/pesan pada kasus ini). Ada entri yang memberi tahu kita apa yang terjadi di yang terakhir:

2 Agustus 19:03:21 MyWebserver1.audit foobar [1]: service_stop pid = 1 uid = 0 auid = 4294967295 SES = 4294967295 msg = "unit = httpd comm =" Systemd "exe ="/usr/lib/lib/systemd "hostname" hostname =? addr =? terminal =? res = gagal "

Kesimpulan

Untuk tujuan demonstrasi saya membunuh proses utama webserver lab saya sendiri dalam contoh ini. Dalam masalah yang berhubungan dengan server, bantuan terbaik yang bisa kita dapatkan dengan cepat adalah dengan memeriksa logfile dan menanyakan sistem untuk menjalankan proses (atau ketidakhadiran mereka), dan memeriksa keadaan yang dilaporkan, untuk lebih dekat dengan masalah ini. Untuk melakukannya secara efektif, kita perlu mengetahui layanan yang kita jalankan: di mana mereka menulis file log mereka, caranya
Kita bisa mendapatkan informasi tentang keadaan mereka, dan mengetahui apa yang dicatat pada waktu operasi normal juga banyak membantu dalam mengidentifikasi suatu masalah - mungkin bahkan sebelum layanan itu sendiri mengalami masalah.

Ada banyak alat yang membantu kami mengotomatiskan sebagian besar hal -hal ini, seperti subsistem pemantauan, dan solusi agregasi log, tetapi ini semua dimulai dengan kami, admin yang tahu bagaimana layanan yang kami jalankan
bekerja, di mana dan apa yang harus diperiksa untuk mengetahui apakah mereka sehat. Alat sederhana yang ditunjukkan di atas dapat diakses dalam distribusi apa pun, dan dengan bantuannya kami dapat membantu memecahkan masalah dengan sistem kami tidak
bahkan akrab dengan. Itu adalah tingkat pemecahan masalah tingkat lanjut, tetapi alat dan penggunaannya yang ditunjukkan di sini adalah beberapa batu bata yang dapat digunakan siapa pun untuk mulai membangun keterampilan pemecahan masalah mereka di GNU/Linux.

Tutorial Linux Terkait:

  • Hal -hal yang harus diinstal pada ubuntu 20.04
  • Hal -hal yang harus dilakukan setelah menginstal ubuntu 20.04 FOSSA FOSSA Linux
  • Pengantar Otomatisasi Linux, Alat dan Teknik
  • Unduh Linux
  • Hal -hal yang harus dilakukan setelah menginstal ubuntu 22.04 Jammy Jellyfish…
  • Daftar Alat Linux Kali Terbaik untuk Pengujian Penetrasi dan ..
  • Instal Arch Linux di VMware Workstation
  • Distro linux terbaik untuk pengembang
  • File Konfigurasi Linux: 30 Teratas Paling Penting
  • Perintah Linux: 20 perintah terpenting teratas yang Anda butuhkan untuk…