Pentadbiran sistem

Panduan Penyelesaian Masalah Umum GNU/Linux untuk Pemula

Panduan Penyelesaian Masalah Umum GNU/Linux untuk Pemula

Dalam panduan ini, matlamat kami adalah untuk mempelajari alat dan persekitaran yang disediakan oleh sistem GNU/Linux biasa untuk dapat memulakan penyelesaian masalah walaupun pada mesin yang tidak diketahui.
Dalam tutorial ini anda akan belajar:

  • Cara memeriksa ruang cakera
  • Cara memeriksa saiz memori
  • Cara memeriksa beban sistem
  • Cara Mencari dan Membunuh Proses Sistem
  • Cara log pengguna untuk mencari maklumat penyelesaian masalah sistem yang berkaitan
Panduan Penyelesaian Masalah Umum GNU/Linux untuk Pemula

Keperluan perisian dan konvensyen yang digunakan

Keperluan Perisian dan Konvensyen Talian Perintah Linux
Kategori Keperluan, konvensyen atau versi perisian yang digunakan
Sistem Ubuntu 20.04, Fedora 31
Perisian N/a
Yang lain Akses istimewa ke sistem linux anda sebagai akar atau melalui sudo perintah.
Konvensyen # - Memerlukan arahan Linux yang diberikan untuk dilaksanakan dengan keistimewaan akar sama ada secara langsung sebagai pengguna root atau dengan menggunakan sudo perintah
$ - Memerlukan arahan Linux yang diberikan sebagai pengguna yang tidak layak

Pengenalan

Walaupun GNU/Linux terkenal kerana kestabilan dan keteguhan, ada kes di mana sesuatu boleh menjadi salah. Sumber masalah mungkin dalaman dan luaran. Sebagai contoh, terdapat proses yang tidak berfungsi yang berjalan pada sistem yang memakan sumber, atau cakera keras lama mungkin rosak, mengakibatkan kesilapan I/O yang dilaporkan.

Dalam apa jua keadaan, kita perlu tahu di mana hendak melihat dan apa yang perlu dilakukan untuk mendapatkan maklumat mengenai keadaan, dan panduan ini cuba memberikannya - cara umum untuk mendapatkan idea yang salah. Sebarang resolusi masalah bermula dengan mengetahui mengenai isu ini, mencari butiran, mencari punca utama, dan menyelesaikannya. Seperti mana -mana tugas, GNU/Linux menyediakan alat yang tidak terkira banyaknya untuk membantu kemajuan, ini juga berlaku dalam penyelesaian masalah. Beberapa petua dan kaedah berikut hanyalah beberapa perkara biasa yang boleh digunakan pada banyak pengagihan dan versi.

Gejala

Katakan kami mempunyai komputer riba yang bagus yang kami kerjakan. Ia menjalankan Ubuntu, Centos atau Red Hat Linux terkini di atasnya, dengan kemas kini selalu ada untuk memastikan semuanya segar. Komputer riba adalah untuk kegunaan umum setiap hari: kami memproses e -mel, berbual, melayari internet, mungkin menghasilkan beberapa spreadsheet di atasnya, dll. Tidak ada yang istimewa dipasang, suite pejabat, penyemak imbas, pelanggan e -mel, dan sebagainya. Dari satu hari ke yang lain, tiba -tiba mesin menjadi sangat perlahan. Kami sudah mengusahakannya selama kira -kira sejam, jadi itu bukan masalah selepas boot. Apa yang sedang berlaku… ?

Memeriksa sumber sistem

Gnu/linux tidak menjadi perlahan tanpa alasan. Dan kemungkinan besar akan memberitahu kita di mana ia menyakitkan, selagi ia dapat menjawab. Seperti mana -mana program yang dijalankan di komputer, sistem operasi menggunakan sumber sistem, dan dengan mereka yang sedang berjalan, operasi perlu menunggu sehingga ada cukup untuk meneruskannya. Ini sememangnya akan menyebabkan tanggapan untuk semakin perlahan dan lebih perlahan, jadi jika ada masalah, selalu berguna untuk memeriksa keadaan sumber sistem. Secara umum sumber sistem (tempatan) kami terdiri daripada cakera, ingatan, dan CPU. Mari kita periksa semuanya.

Ruang cakera

Sekiranya sistem operasi berjalan keluar dari ruang cakera, itu berita buruk. Oleh kerana perkhidmatan yang berjalan tidak dapat menulis logfile mereka, mereka akan kebanyakannya terhempas jika berjalan, atau tidak akan bermula jika cakera sudah penuh. Selain fail logfiles, soket dan pid (pengenalpastian proses) perlu ditulis pada cakera, dan sementara ini adalah saiz kecil, jika tidak ada ruang lagi, ini tidak dapat dibuat.

Untuk memeriksa ruang cakera yang ada yang boleh kami gunakan df di terminal, dan tambah -h hujah, untuk melihat hasilnya dibundarkan kepada megabait dan gigabait. Bagi kami penyertaan minat akan menjadi jumlah yang menggunakan% sebanyak 100%. Itu bermaksud jumlah yang berkenaan penuh. Output contoh berikut menunjukkan kita baik -baik saja mengenai ruang cakera:

$ df -h saiz sistem fail yang digunakan menggunakan penggunaan% 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% /HOME TMPFS 361M 4.0k 361m 1%/run/user/1000
Salinan

Oleh itu, kami mempunyai ruang pada cakera. Perhatikan bahawa dalam kes komputer riba yang perlahan, keletihan ruang cakera tidak mungkin menjadi punca utama. Apabila cakera penuh, program akan terhempas atau tidak akan bermula sama sekali. Dalam kes yang melampau, walaupun log masuk akan gagal selepas boot.

Ingatan

Memori adalah sumber penting juga, dan jika kita kekurangannya, sistem pengendalian mungkin perlu menulis kepingan yang tidak digunakan pada masa ini untuk cakera sementara (juga dipanggil "swap out") untuk memberikan ingatan yang dibebaskan ke proses seterusnya, maka baca ia kembali apabila proses yang memiliki kandungan bertukar memerlukannya lagi. Kaedah keseluruhan ini dipanggil bertukar, dan sememangnya akan melambatkan sistem, sebagai menulis dan membaca ke dan dari cakera jauh lebih perlahan daripada bekerja di dalam ram.

Untuk memeriksa penggunaan memori kami mempunyai yang berguna percuma Perintah bahawa kita boleh menambah argumen untuk melihat hasil dalam megabait (-m) atau gigabait (-g):

$ percuma -m Jumlah Buff/Cache Berkongsi Percuma MEM: 7886 3509 1547 1231 2829 2852 Swap: 8015 0 8015
Salinan

Dalam contoh di atas, kita mempunyai memori 8 GB, 1,5 GB percuma, dan sekitar 3 GB dalam cache. The percuma Perintah juga menyediakan keadaan bertukar: dalam kes ini ia sangat kosong, yang bermaksud sistem pengendalian tidak perlu menulis apa -apa kandungan memori ke cakera sejak permulaan, bahkan pada beban puncak. Ini biasanya bermaksud kita mempunyai lebih banyak ingatan yang sebenarnya kita gunakan. Jadi mengenai ingatan kita lebih baik, kita mempunyai banyak.

Beban sistem

Memandangkan pemproses melakukan pengiraan sebenar, kehabisan masa pemproses untuk mengira sekali lagi dapat memperlahankan sistem ke bawah. Pengiraan yang diperlukan perlu menunggu sehingga pemproses mempunyai masa lapang untuk mengira mereka. Cara paling mudah untuk melihat beban pada pemproses kami ialah uptime Perintah:

$ uptime 12:18:24 UP 4:19, 8 pengguna, beban purata: 4,33, 2,28, 1,37
Salinan

Tiga nombor selepas purata beban bermakna purata dalam 1, 5 dan 15 minit terakhir. Dalam contoh ini mesin mempunyai 4 teras CPU, jadi kami cuba menggunakan lebih daripada kapasiti sebenar kami. Juga perhatikan bahawa nilai -nilai sejarah menunjukkan bahawa beban akan meningkat dengan ketara dalam beberapa minit terakhir. Mungkin kita menjumpai pelakunya?

Proses pengguna teratas

Mari lihat keseluruhan gambar CPU dan penggunaan memori, dengan proses teratas menggunakan sumber -sumber ini. Kita boleh melaksanakan Atas Perintah untuk melihat beban sistem dalam (berhampiran) masa nyata:

Memeriksa proses pengguna teratas.

Baris pertama atas adalah sama dengan output uptime, Seterusnya kita dapat melihat nombor jika tugas berjalan, tidur, dll. Perhatikan kiraan proses zombie (defungsi); Kes ini adalah 0, tetapi jika terdapat beberapa proses di Negeri Zombie, mereka harus disiasat. Baris seterusnya menunjukkan beban pada CPU dalam peratusan, dan peratusan terkumpul tepat apa pemproses sibuk dengan. Di sini kita dapat melihat bahawa pemproses sibuk melayani program ruang pengguna.

Seterusnya adalah dua baris yang boleh biasa dari percuma output, penggunaan memori jika sistem. Di bawah ini adalah proses teratas, disusun dengan penggunaan CPU. Sekarang kita dapat melihat apa yang memakan pemproses kita, ia adalah firefox dalam kes kita.

Memeriksa proses

Bagaimana saya tahu bahawa, kerana proses memakan teratas ditunjukkan sebagai "kandungan web" di saya Atas pengeluaran? Dengan menggunakan ps Untuk menanyakan jadual proses, menggunakan PID yang ditunjukkan di sebelah proses teratas, yang dalam kes 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/ Firefox/Browser 2528 Tab Benar

Dengan langkah ini kita dapati punca utama keadaan kita. Firefox memakan masa CPU kami sehingga sistem kami mula menjawab tindakan kami lebih perlahan. Ini tidak semestinya kesalahan penyemak imbas,
Kerana Firefox direka untuk memaparkan halaman dari World Wide Web: Untuk membuat isu CPU untuk tujuan demonstrasi, semua yang saya lakukan adalah membuka beberapa dozen contoh halaman ujian tekanan dalam tab yang berbeza dari penyemak imbas ke titik kekurangan CPU permukaan. Oleh itu, saya tidak perlu menyalahkan penyemak imbas saya, tetapi saya sendiri untuk membuka halaman yang lapar sumber dan membiarkan mereka berjalan selari. Dengan menutup beberapa, CPU saya
Penggunaan kembali normal.

Memusnahkan proses

Isu dan penyelesaiannya ditemui di atas, tetapi bagaimana jika saya tidak dapat mengakses pelayar untuk menutup beberapa tab? Katakan sesi grafik saya terkunci dan saya tidak dapat log masuk, atau umum
proses yang pergi liar bahkan tidak mempunyai antara muka di mana kita boleh mengubah tingkah laku itu? Dalam kes sedemikian, kita boleh mengeluarkan penutupan proses oleh sistem pengendalian. Kita sudah tahu pid dari
proses penyangak yang kami dapat ps, dan kita boleh menggunakan bunuh Perintah untuk menutupnya:

$ Kill 5785

Proses yang berkelakuan baik akan keluar, ada yang mungkin tidak. Jika ya, tambah -9 Bendera akan memaksa penamatan proses:

$ KILL -9 5785

Perhatikan bagaimanapun, ini boleh menyebabkan kehilangan data, kerana proses itu tidak mempunyai masa untuk menutup fail yang dibuka atau selesai menulis hasilnya ke cakera sama sekali. Tetapi dalam hal beberapa tugas berulang, kestabilan sistem mungkin mengambil keutamaan untuk kehilangan beberapa hasil kami.

Mencari maklumat yang berkaitan

Berinteraksi dengan proses dengan beberapa jenis antara muka tidak selalu berlaku, dan banyak aplikasi hanya mempunyai arahan asas yang mengawal tingkah laku mereka - iaitu, memulakan, berhenti, memuat semula, dan sebagainya, kerana kerja dalaman mereka disediakan oleh konfigurasi mereka. Contoh di atas adalah lebih banyak desktop, mari kita lihat contoh pelayan, di mana kita mempunyai masalah dengan pelayan web.

Katakan kami mempunyai webserver yang melayani beberapa kandungan ke dunia. Ia popular, jadi bukan berita baik apabila kami mendapat panggilan bahawa perkhidmatan kami tidak tersedia. Kami boleh menyemak laman web dalam penyemak imbas hanya untuk mendapatkan mesej ralat yang mengatakan "tidak dapat menyambung". Mari lihat mesin yang menjalankan webserver!

Memeriksa logfiles

Mesin kami yang menganjurkan webserver adalah kotak fedora. Ini penting kerana laluan sistem fail yang perlu kita ikuti. Fedora, dan semua variasi Red Hat lain menyimpan logfiles webserver Apache di jalan /var/log/httpd. Di sini kita boleh menyemak error_log menggunakan Lihat, tetapi tidak menemui apa -apa maklumat yang berkaitan dengan apa masalahnya. Memeriksa log akses juga tidak menunjukkan sebarang masalah pada pandangan pertama, tetapi berfikir dua kali akan memberi kita petunjuk: Pada pelayan web dengan trafik yang cukup baik, penyertaan terakhir log akses harus sangat baru -baru ini, tetapi entri terakhir sudah berusia sejam. Kami tahu dengan pengalaman bahawa laman web mendapat pelawat setiap minit.

Sistemd

Pemasangan Fedora kami menggunakan sistemd sebagai sistem init. Mari bertanya untuk beberapa maklumat mengenai webserver:

# status systemctl httpd ● httpd.Perkhidmatan - Pelayan HTTP Apache dimuatkan: dimuatkan (/usr/lib/systemd/system/httpd.perkhidmatan; dilumpuhkan; Pratetap vendor: dilumpuhkan) Drop-in:/usr/lib/systemd/system/httpd.perkhidmatan.d └─php-fpm.Conf Active: Gagal (Hasil: Isyarat) Sejak Sun 2020-08-02 19:03:21 CEST; 3min 5s yang lalu Dokumen: Man: httpd.Perkhidmatan (8) Proses: 29457 execstart =/usr/sbin/httpd $ options -dforeground (code = dibunuh, isyarat = membunuh) PID utama: 29457 (kod = dibunuh, isyarat = membunuh) Status: "Jumlah permintaan: 0; Idle /Pekerja sibuk 100/0; permintaan/sec: 0; bait berkhidmat/sec: 0 b/sec "cpu: 74ms 02 Ogos 19:03:21 mywebserver1.Foobar Systemd [1]: httpd.Perkhidmatan: Proses Membunuh 29665 (N/A) dengan Sigkill Signal. 02 Ogos 19:03:21 mywebserver1.Foobar Systemd [1]: httpd.Perkhidmatan: Proses Pembunuhan 29666 (N/A) dengan Sigkill Signal. 02 Ogos 19:03:21 mywebserver1.Foobar Systemd [1]: httpd.Perkhidmatan: Proses Membunuh 29667 (N/A) dengan Sigkill Signal. 02 Ogos 19:03:21 mywebserver1.Foobar Systemd [1]: httpd.Perkhidmatan: Proses Pembunuhan 29668 (N/A) dengan Sigkill Signal. 02 Ogos 19:03:21 mywebserver1.Foobar Systemd [1]: httpd.Perkhidmatan: Proses Membunuh 29669 (N/A) dengan Sigkill Signal. 02 Ogos 19:03:21 mywebserver1.Foobar Systemd [1]: httpd.Perkhidmatan: Proses Pembunuhan 29670 (N/A) dengan Sigkill Signal. 02 Ogos 19:03:21 mywebserver1.Foobar Systemd [1]: httpd.Perkhidmatan: Proses Membunuh 29671 (N/A) dengan Sigkill Signal. 02 Ogos 19:03:21 mywebserver1.Foobar Systemd [1]: httpd.Perkhidmatan: Proses Pembunuhan 29672 (N/A) dengan Sigkill Signal. 02 Ogos 19:03:21 mywebserver1.Foobar Systemd [1]: httpd.Perkhidmatan: Proses Pembunuhan 29673 (N/A) dengan Sigkill Signal. 02 Ogos 19:03:21 mywebserver1.Foobar Systemd [1]: httpd.Perkhidmatan: Gagal dengan hasil 'isyarat'.
Salinan

Contoh di atas sekali lagi yang mudah, httpd proses utama turun kerana ia menerima isyarat membunuh. Mungkin ada sysadmin lain yang mempunyai keistimewaan untuk berbuat demikian, jadi kita dapat memeriksa siapa
Log masuk (atau pada masa penutupan yang kuat dari webserver), dan minta dia tentang isu itu (perhentian perkhidmatan yang canggih akan kurang kejam, jadi mesti ada alasan di sebalik ini
acara). Jika kita adalah satu -satunya pentadbir di pelayan, kita boleh menyemak di mana isyarat itu berasal - kita mungkin mempunyai masalah pelanggaran, atau sistem operasi menghantar isyarat membunuh. Dalam kedua -dua kes kita boleh menggunakan
logfiles pelayan, kerana SSH Log masuk dilog masuk ke log keselamatan (/var/log/selamat dalam kes Fedora), dan terdapat juga entri audit yang boleh didapati di log utama (iaitu
/var/log/mesej Dalam kes ini). Terdapat entri yang memberitahu kita apa yang berlaku di yang terakhir:

2 Ogos 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/systemd/systemd "hostname =? addr =? terminal =? res = gagal "

Kesimpulan

Untuk tujuan demonstrasi saya membunuh proses utama webserver saya sendiri dalam contoh ini. Dalam isu yang berkaitan dengan pelayan, bantuan terbaik yang dapat kita lakukan dengan cepat adalah dengan memeriksa logfile dan menanyakan sistem untuk proses yang berjalan (atau ketiadaan mereka), dan memeriksa keadaan mereka yang dilaporkan, untuk lebih dekat dengan isu tersebut. Untuk melakukannya dengan berkesan, kita perlu mengetahui perkhidmatan yang kita jalankan: di mana mereka menulis logfile mereka, bagaimana
Kita boleh mendapatkan maklumat mengenai keadaan mereka, dan mengetahui apa yang dilog masuk pada masa operasi biasa juga banyak membantu dalam mengenal pasti masalah - bahkan sebelum perkhidmatan itu sendiri mengalami masalah.

Terdapat banyak alat yang membantu kami mengautomasikan kebanyakan perkara ini, seperti subsistem pemantauan, dan penyelesaian agregasi log, tetapi ini semua bermula dengan kami, pentadbir yang tahu bagaimana perkhidmatan yang kami jalankan
bekerja, di mana dan apa yang harus diperiksa untuk mengetahui sama ada mereka sihat. Alat mudah yang ditunjukkan di atas boleh diakses dalam sebarang pengedaran, dan dengan bantuan mereka, kami dapat membantu menyelesaikan masalah dengan sistem yang tidak kita lakukan
walaupun biasa dengan. Itu adalah tahap penyelesaian masalah yang lebih maju, tetapi alat dan penggunaannya yang ditunjukkan di sini adalah beberapa batu bata yang boleh digunakan untuk mula membina kemahiran penyelesaian masalah mereka pada GNU/Linux.

Tutorial Linux Berkaitan:

  • Perkara yang hendak dipasang di Ubuntu 20.04
  • Perkara yang perlu dilakukan setelah memasang ubuntu 20.04 Focal Fossa Linux
  • Pengenalan kepada Automasi, Alat dan Teknik Linux
  • Muat turun linux
  • Perkara yang perlu dilakukan setelah memasang Ubuntu 22.04 Jur -ubur Jammy ..
  • Senarai alat Kali Linux terbaik untuk ujian penembusan dan ..
  • Pasang Arch Linux di Workstation VMware
  • Distro linux terbaik untuk pemaju
  • Fail Konfigurasi Linux: 30 teratas yang paling penting
  • Perintah Linux: Top 20 Perintah Paling Penting yang Anda Perlu ..