Mengapa perintah sudo perlu waktu lama untuk dieksekusi?

83

Saya telah mengambil Linux (Fedora 10, kemudian 11) selama beberapa bulan terakhir (dan sangat menikmatinya - itu seperti menemukan komputer lagi, begitu banyak hal untuk dipelajari).

Saya telah menambahkan pengguna saya ke baris terakhir file / etc / sudoers seperti yang ditunjukkan di bawah ini, sehingga saya tidak dimintai kata sandi ketika saya menjalankan perintah sudo:

MyUserName ALL = (ALL) NOPASSWD: ALL

Sekarang setiap kali saya mengeksekusi perintah menggunakan sudo, itu berhenti sejumlah waktu sebelum benar-benar melakukan tugas (~ 10 detik). Mengapa ini terjadi dan bagaimana saya memperbaikinya? Saya menjalankan Sudo versi 1.7.1 pada Fedora 11 x86 64.

linux  permissions  sudo 
— anon
sumber
Secara teknis ini dianggap sebagai mengedit skrip, bukan? Bukankah skrip adalah program?
6
NOPASSWD: dianggap sebagai risiko keamanan dan mengalahkan tujuan harus menggunakan sudo sejak awal.
Saya bisa membelinya, tetapi masalahnya masih tetap mengapa perlu waktu lama.
2
Dari mana mesin ini mendapatkan pengguna dan otentikasi? LDAP, mungkin dengan Kerberos mungkin?
— wzzrd
1
— Harry Tsai

Jawaban:

123

Saya mengajukan pertanyaan ini pada SO dan dipindahkan di sini. Yang mengatakan saya tidak lagi memiliki kemampuan untuk mengedit pertanyaan seolah-olah saya memilikinya, atau bahkan menerima jawaban yang benar, tetapi ini ternyata menjadi alasan sebenarnya mengapa dan bagaimana menyelesaikannya:

Ditemukan di sini Pengguna "rohandhruva" di sana memberikan jawaban yang benar:

Ini terjadi jika Anda mengubah nama host selama proses instalasi.

Untuk menyelesaikan masalah, edit file / etc / hosts

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 <ADD_YOURS_HERE> 
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 <ADD_YOURS_HERE>
— Cuga
sumber
3
Benar sekali. Agak mengejutkan bahwa distro seperti Fedora tidak mengedit / etc / hosts jika Anda mengubah nama host Anda pada waktu instalasi, tetapi apa pun. Itu sumber terbuka untuk Anda!
— dimo414
Ini memperbaiki penggunaan sudo saya yang lambat, terima kasih! Saya mengedit / etc / hostname, dan lupa mengedit file / etc / hosts.
— Joe
2
Menambahkan Hostname Anda ke baris 127.0.0.1 atau :: 1 dapat menyebabkan perangkat lunak terkait server tertentu dari mengikat ke Hostname kanan / IP / antarmuka. Salah satu contohnya adalah Cloudera Manager, layanan hadoop mendapatkan Hostname yang salah dan membingungkan CM karena mereka semua memutuskan untuk localhost. Saya sarankan membaca jawaban lain di bawah ini untuk solusi yang mungkin. Ini mungkin atau mungkin tidak menyebabkan masalah pada workstation mandiri yang tidak memiliki komputer lain yang terhubung dengannya.
— ddcruver
1
Itu juga bisa menjadi /etc/nsswitch.conf (untuk alasan yang sama). Milik saya diatur ke "host: file dns" dan jadi mencari nama host saya di server DNS dengan batas waktu yang lama. Saya mengubahnya menjadi "hosts: files dns" dan jadi sekarang ia akan mencari di / etc / hosts terlebih dahulu. Terima kasih atas jawaban ini, yang membuat saya mencari di nsswitch.conf!
— Alan Porter
1
Itu konyol bahwa ini adalah solusinya. Mengapa di dunia ini sudoperintah harus melihat hostname agar dapat berfungsi? Apa hubungannya dengan nama host saya sudo echo hello? Bagaimanapun, terima kasih atas jawabannya
— smac89
24

Pastikan daemon syslog Anda berfungsi dengan benar; ini menyebabkan masalah bagi saya.

Jalankan perintah berikut

logger 'Hello world'

  1. Apakah perintah kembali dalam jumlah waktu yang wajar?

  2. Apakah 'Hello world' muncul di /var/log/syslog?

Jika ini bukan masalahnya, daemon syslog telah macet. Restart itu akan memperbaiki masalah Anda.

— galgalesh
sumber
9
Anehnya itu masalah bagi saya. Siapa yang akan memikirkannya. Solusi bagi saya adalah hanya me-restart syslog. service rsyslog restart
— MikeKulls
Sama disini. service rsyslog restartmemperbaiki perintah sudo saya yang lambat.
— Pedro Cordeiro
Anehnya itu masalah bagi saya. Sebelum itu, seluruh permintaan untuk server sangat lambat. Saya hanya ingin tahu mengapa?
— michael wang
10

Apakah salah satu file / direktori yang perlu dibaca pada mount jaringan, atau entah bagaimana memicu pembacaan dari perangkat usb lambat? Coba strace dan lihat di mana lambatnya; jika terlalu cepat, lakukan

sudo strace -r -o trace.log sudo echo hi

Setiap baris akan mulai dengan waktu yang diambil sejak memasuki syscall sebelumnya.

(Sudo awal tampaknya diperlukan; Saya tidak tahu berapa banyak yang akan mengganggu hasil.)

— ysth
sumber
Terima kasih. Ini ada di HDD, tidak ada USB atau drive jaringan.
@Cuga: dan apa yang Anda pelajari dari strace?
@oligofren: Anda perlu melakukan sudo strace
— ysth
8

Baru-baru ini saya menemukan bahwa saya memiliki masalah yang sama. Tidak ada penundaan sudo dan kemudian tiba-tiba, sekitar penundaan 10-20 detik. Saya menentukan masalah spesifik menggunakan:

 1. chmod u+s /usr/sbin/strace  (as the root user)

Seperti dirimu sendiri:

 1. sudo -K
 2. strace sudo /bin/tcsh

Dan kemudian temukan di mana panggilan sistem tergantung.

Dalam kasus SAYA, saya menemukan bahwa itu tergantung pada terjemahan DNS, ternyata salah satu DNSen dalam daftar saya /etc/resolv.confsangat buzy atau rusak. Jadi saya mengubah urutan resolusi dan beberapa hal bekerja dengan cepat lagi.

— mdpc
sumber
Jawaban terbaik (untuk saya)! Mengetahui DBus Broker saya macet pada putuskan jaringan dan sudo / KDE sedang tidak terhubung untuk menghubungkannya. Terima kasih!
— PSSGCSim
Terima kasih, ini membantu saya. Saya juga harus membatalkan perubahan sebelumnya ke hostsbaris di /etc/nsswitch.conf saya. Saya telah menambahkan "resoluskan dns" sebagai awalan ke hostsnilai. Ketika saya menghapus awalan ini, sudo cepat lagi.
— mnieber
5

Saya tidak yakin tentang Fedora, tetapi saya telah menggunakan sistem lain tempat sudo akan memeriksa dari mana Anda masuk, yang jika DNS Anda tidak diatur dengan baik dapat memakan waktu lama hingga habis. Ini juga dapat dilihat saat SSH'ing masuk ke mesin - dibutuhkan waktu lama untuk menghasilkan prompt.

— Colin Coghill
sumber
5

Saya menangani masalah yang sama, saya memeriksa /var/log/auth.log dan syslog untuk kesalahan. Ternyata server LDAP saya tidak dapat dijangkau dan memperlambat semuanya.

Saya tidak lagi menggunakan autent berbasis LDAP, jadi saya menghapus semua referensi "ldap" dari /etc/nsswitch.conf

Sejak itu semuanya bekerja seperti pesona lagi.

— Sakuraba
sumber
Mengapa Anda mengirim jawaban yang jelas tidak terkait (OP tidak menggunakan LDAP) untuk pertanyaan berusia lima tahun?
— Sven
7
Karena mungkin membantu siapa saja. Saya memeriksa semua hal yang disebutkan di sini, tetapi tidak ada yang membantu. Orang lain mungkin fokus melihat ke arah yang benar dengan jawaban saya dengan memeriksa apakah ia memiliki masalah koneksi LDAP sebagai alasan mendasar dari perintah sudo yang lambat dan tidak responsif. Ini sama relevannya dengan jawaban terkait DNS di mana sesuatu di balik selimut salah yang tidak langsung terlihat oleh pengguna. Saya menganggap situs ini sebagai sumber pengetahuan umum dan bukan hanya sebagai satu jenis pertanyaan / jawaban dari situs web. Ini tentang mengumpulkan pengetahuan yang relevan.
— Sakuraba
6
Juga siapa di neraka biru yang akan mendiskreditkan bantuan saya. Situs ini berfungsi karena berbagi pengetahuan mendapat insentif, bukan karena orang downvot. Jika Anda tidak menyukainya, maka Anda berhak mengabaikannya.
— Sakuraba
5

Dalam hal ini, ditemukan nama host (yang dikonfigurasi dalam /etc/sysconfig/ jaringan) tidak ada dalam /etc/hostsfile; jadi setelah menambahkan file yang disebutkan sebelumnya, file segera terbuka.

— Zahid Hussain
sumber
3

Saya memiliki masalah yang sama, saya memperbaikinya dengan menempatkan kedua nama host (mis. Mybox) dan hasil lengkap dari perintah hostname (mybox.mydomain.com). Ini jelas benar. Pergi dari 2 menit untuk membuka / etc / hosts ke akses instan.

—
sumber
3

Sel SELinux

Jika perintah sudo yang sama lambat hanya dalam daemon dan cepat pada baris perintah, maka itu kemungkinan disebabkan oleh SELinux . (SELinux = modul kernel Linux Enhanced NSA Security, diaktifkan di Fedora secara default.)

Kasus khas adalah server http dan skrip khusus untuk manajemen server, dibatasi pada sudoers:

apache ALL=(root_or_user) NOPASSWD: /full/path/the_safe_command

Biasanya dalam kasus ini bahwa tidak ada tentang SELinux yang dilaporkan dalam log audit ausearch -m avc -ts today, tetapi skrip berjalan cepat jika kita menonaktifkan sementara penegakan oleh setenforce 0. (lalu kembali aktifkan oleh setenforce 1)

Satu-satunya pesan yang relevan di log sistem (jurnalcrl) adalah ini setelah penundaan 25 detik:

... sudo [...] pam_systemd (sudo: session): Gagal membuat sesi: Tidak menerima balasan. Kemungkinan penyebabnya meliputi: aplikasi jarak jauh tidak mengirim balasan, kebijakan keamanan bus pesan memblokir balasan, batas waktu balasan kedaluwarsa, atau koneksi jaringan terputus.
... sudo [...]: pam_unix (sudo: session): sesi dibuka untuk root oleh pengguna (uid = 0)

Logging dari semua pesan SElinux "jangan-audit" yang dibungkam dapat diaktifkan oleh semodule -DBdan dinonaktifkan kembali oleh semodule -B.
(Saya harap saya segera menulis modul kebijakan SELinux untuk kasus ini di sini atau metode dari jawaban ini dapat digunakan.)

— hynekcer
sumber
Terima kasih atas informasi ini. Dari informasi di sini, saya kemudian dapat menemukan artikel terkait yang mencatat kemungkinan fprintd(otentikasi sidik jari) pelakunya. Menghapus fprintddan fprintd-pammenyelesaikan masalah untuk saya.
— KevinO
@KevinO Senang bahwa itu membantu Anda menemukan solusi. Namun saya tahu bahwa masalah saya sangat spesifik dan bahwa kontribusi saya pada pertanyaan seharusnya hanya metode bagaimana mendiagnosis atau mengecualikan kecurigaan tentang SELinux.
— hynekcer
Saya benar-benar memberinya +1! Itu adalah bus pesan yang mengarah ke solusi. Saya telah melihat beberapa kali pada sudo lambat, tetapi milik Anda adalah petunjuk yang saya butuhkan.
— KevinO
1

Dari melihat sudoersfile sampel yang saya miliki, saya percaya seharusnya ada spasi setelah NOPASSWD:bit.

— Chris Jester-Young
sumber
Saya menambahkan spasi, tetapi masih ada lag. Terima kasih untuk sarannya.
1

Setelah memperbaiki masalah host, pastikan Anda menghapus cache DNS yang buruk jika Anda menjalankan aplikasi cache DNS seperti nscd:

/etc/init.d/nscd force-reload
— Roger Smith
sumber
1

Bagi saya itu adalah krb5-user / config / locales sedang diinstal. Saya perhatikan ini dengan memeriksa /var/log/auth.log. Menggunakan apt-get remove untuk menghapus instalasi paket-paket itu. Jangan hapus paket-paket itu jika Anda menggunakan komputer yang membutuhkan kerberos (pam_krb5) jelas.

— Halsafar
sumber
0

Apakah Anda menggunakan LDAP untuk otentikasi?

Jika demikian, Anda mungkin ingin menggunakan kebijakan bind lunak. Di /etc/ldap/ldap.conf (atau /etc/ldap.conf):

bind_policy soft
— jtimberman
sumber
0

Sepertinya Anda memiliki semacam batas waktu dalam rantai otentikasi Anda. Periksa bagaimana sudo mencoba mengotentikasi dan mengawasi kemacetan.

— towo
sumber
0

Case Systemd

Bagi saya, sistem saya sudah kehabisan memori dan banyak proses macet. Sistem saya berbasis di sekitar systemd dan sesuatu di sana telah crash. Sulit bagi saya untuk mengingat semua yang saya lakukan, tetapi:

  • systemctl status <any.service> akan habis
  • Saya tidak bisa sudo reboot(berbasis systemd)

Larutan

Restart memperbaiki masalah saya, tetapi bagi saya hanyalah bandaid. Anda masih perlu mencari tahu mengapa Anda kehabisan memori / macet.

— Eric Fossum
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.