Sudo komutunun yürütülmesi neden uzun sürüyor?

Geçtiğimiz birkaç ay boyunca Linux’u (Fedora 10, ardından 11) alıyorum (ve bundan zevk alıyorum - tekrar tekrar bilgisayarları keşfetmek, öğrenmek için pek çok şey gibi).

Kullanıcımı aşağıda gösterildiği gibi / etc / sudoers dosyasının son satırına ekledim, böylece sudo komutunu çalıştırdığımda parolamı sormuyorum:

Kullanıcı Adım ALL = (ALL) NOPASSWD: ALL

Şimdi sudo kullanarak bir komut çalıştırdığımda, görevi yerine getirmeden önce (~ 10 saniye) fark edilebilir bir süreyi duraklatıyor. Bu neden olabilir ve bunu nasıl düzeltebilirim? Fedora 11 x86 64'te Sudo sürüm 1.7.1 kullanıyorum.

SO üzerine bu soruyu sordum ve buraya taşındı. Artık, soruyu sahip olduğum gibi düzenleme yeteneğine sahip olmadığımı, hatta doğru cevabı kabul edemediğimi, ancak bunun neden ve nasıl çözüleceği gerçek nedeni olduğu ortaya çıktı:

Burada bulunan kullanıcı "rohandhruva" orada doğru cevabı verir:

Bu, yükleme işlemi sırasında ana bilgisayar adını değiştirirseniz olur.

Sorunu çözmek için / etc / hosts dosyasını düzenleyin

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 <ADD_YOURS_HERE> 
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 <ADD_YOURS_HERE>

Syslog arka planınızın düzgün çalıştığını kontrol edin; bu benim için soruna neden oldu.

Aşağıdaki komutu çalıştırın

logger 'Hello world'

1. Komut makul bir süre içinde geri dönüyor mu?

2. 'Merhaba dünya' geldi /var/log/syslogmi?

Durum böyle değilse, syslog arka plan programı çöktü. Yeniden başlatmak, sorununuzu çözmelidir.

Ağa bağlı bir bağda okunması gereken dosyalardan / dizinlerden biri mi, yoksa yavaş bir USB aygıtından okumayı tetikliyor mu? Strace deneyin ve yavaş olduğunu görün; çok hızlı geçerse, yap

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

Her satır önceki sisteme girildiğinden beri geçen süre ile başlayacaktır.

(İlk sudo gerekli görünüyor; bunun sonuçları ne kadar bozacağını bilmiyorum.)

Son zamanlarda aynı sorunu yaşadığımı öğrendim. Sudo gecikmesi olmadı ve ardından ani bir 10-20 saniyelik gecikme oldu. Spesifik sorunu kullanarak şunları belirledim:

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

Kendin gibi:

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

Ve sonra sistem aramalarının nerede asılı olduğunu bulun.

Benim durumumda, bir DNS çevirisine asıldığını, görünüşe göre listemdeki DNSen’den /etc/resolv.confbirinin çok buzlu veya kötü gittiğini gördüm . Bu yüzden çözünürlük sırasını değiştirdim ve işleri hızlıca tekrar başlattım.

Fedora hakkında emin değilim, ancak sudo'nun giriş yaptığınız yeri kontrol edeceği başka sistemler kullandım, eğer DNS'iniz iyi ayarlanmadıysa, zaman aşımına uğrayabilecek yaşları alabilir. Bu aynı zamanda SSH'nin makineye girdiği zaman da görülebilir - bir istemin ortaya çıkması yıllar alır.

Aynı problemden nefret ediyorum, /var/log/auth.log ve syslog hatalarını kontrol ettim. LDAP sunucuma erişilemediğini ve her şeyin yavaşladığını ortaya koyuyor.

Artık LDAP tabanlı auth kullanmamıştım, bu yüzden tüm "ldap" referanslarını /etc/nsswitch.conf adresinden kaldırdım.

O zamandan beri her şey yine bir cazibe gibi çalışıyor.

Bazı durumlarda, ana bilgisayar adının ( /etc/sysconfig/ ağda yapılandırılmış ) /etc/hostsdosyada bulunmadığı ; bu yüzden yukarıda belirtilen dosyaya eklendiğinde dosya derhal açılır.

Benzer bir sorun yaşadım, hem hostname (örn. Mybox) hem de hostname komutunun tam çıktısını (mybox.mydomain.com) yerleştirerek düzelttim. Bu doğru temizledi. Anında erişime açık / etc / ana bilgisayarlara 2 dakika arasında gitti.

SELinux vakası

Aynı sudo komutu yalnızca bir arka plan programında yavaşsa ve komut satırında hızlıysa , en büyük olasılıkla SELinux neden olur . (SELinux = NSA Güvenliği Geliştirilmiş Linux çekirdek modülü, Fedora'da varsayılan olarak etkindir.)

Tipik bir durum, bir http sunucu ve kısıtlı sunucu yönetimi için özel bir komut dosyası vardır sudoers:

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

Bu durumda, denetim günlüğünde SELinux hakkında hiçbir şey bildirilmemesi normaldir ausearch -m avc -ts today, ancak geçici olarak zorla devredışı bırakırsak komut dosyası hızla ilerler setenforce 0. (ve daha sonra geri etkinleştir setenforce 1)

Sistem günlüğündeki tek ilgili mesajlar (journalcrl) 25 saniye gecikmeden sonra olanlar:

... sudo [...] pam_systemd (sudo: session): Oturum oluşturulamadı: Bir cevap alamadı. Muhtemel nedenler arasında şunlar yer alır: uzak uygulama bir yanıt göndermedi, mesaj veriyolu güvenliği politikası yanıtı engelledi, yanıt zaman aşımı süresi doldu veya ağ bağlantısı koptu.
... sudo [...]: pam_unix (sudo: session): kullanıcı kökü için oturum açıldı (uid = 0)

Tüm sessiz "dont-audit" SElinux mesajlarının kaydedilmesi, tarafından semodule -DBtekrar etkinleştirilebilir ve devre dışı bırakılabilir semodule -B.
(Umarım yakında bu dava için yakında bir SELinux politika modülü yazarım ya da bu cevabın bir yöntemi kullanılabilir.)

sudoersSahip olduğum örnek dosyaya baktığımda , NOPASSWD:bitten sonra bir boşluk olduğuna inanıyoruz .

/ Etc / hosts dosyanızı kontrol edin ve 127.0.0.1 için bir girişiniz olduğundan emin olun

( kaynak )

Herhangi bir ana bilgisayar sorununu düzelttikten sonra, eğer nscd gibi bir DNS önbellekleme uygulaması kullanıyorsanız, kötü bir DNS önbelleğini temizlediğinizden emin olun:

/etc/init.d/nscd force-reload

Benim için krb5-user / config / locales kuruluyordu. Bunu /var/log/auth.log dosyasını inceleyerek farkettim. Bu paketleri kaldırmak için apt-get remove ile düzeltildi. Açıkça kerberos (pam_krb5) gerektiren bir bilgisayardaysanız bu paketleri çıkarmayın.

Kimlik doğrulama için LDAP kullanıyor musunuz?

Eğer öyleyse muhtemelen politika ilkesini kullanmak istersiniz. /Etc/ldap/ldap.conf (veya /etc/ldap.conf) 'da:

bind_policy soft

Kimlik doğrulama zincirinizde bir çeşit zaman aşımı var gibi gözüküyor. Sudo'nun kimlik doğrulama ve darboğazları izlemeye çalıştığını kontrol edin.

Systemd Çantası

Benim için sistemim hafızası tükenmişti ve birçok işlem çöktü. Sistemim sistemdele dayanıyor ve oradaki bir şey çöktü. Yaptığım her şeyi hatırlamak benim için zor, ama:

• systemctl status <any.service> zaman aşımı olur
• Yapamam sudo reboot(sistem tabanlı)

Çözüm

Yeniden başlatma, sorunumu çözdü, ancak benim için sadece bir bandajdı. Neden hafızanızın tükendiğini ve düştüğünü öğrenmeniz gerekiyor.