Vraag Waarom duurt het sudo-commando lang om uit te voeren?


Ik heb de afgelopen maanden Linux (Fedora 10, toen 11) opgepikt (en er enorm van genoten - het is alsof ik computers opnieuw ontdekt, zoveel dingen om te leren).

Ik heb mijn gebruiker toegevoegd aan de laatste regel van het bestand / etc / sudoers, zoals hieronder weergegeven, zodat ik niet om mijn wachtwoord wordt gevraagd als ik de opdracht sudo voer:

MyUserName ALL = (ALL) NOPASSWD: ALL

Telkens als ik een opdracht voer met sudo, pauzeert het een merkbare hoeveelheid tijd voordat de taak daadwerkelijk wordt uitgevoerd (~ 10 seconden). Waarom is dit mogelijk en hoe kan ik dit oplossen? Ik gebruik Sudo versie 1.7.1 op Fedora 11 x86 64.


60


oorsprong


Technisch gezien telt dit als het bewerken van een script, toch? Is een script geen programma?
NOPASSWD: wordt beschouwd als een beveiligingsrisico en verslaat het doel van het gebruik van sudo in de eerste plaats.
Ik kan dat kopen, maar het probleem blijft nog steeds waarom het zo lang duurt.
Waar krijgt deze machine gebruikers en authenticatie vandaan? LDAP, mogelijk met Kerberos misschien? - wzzrd
Mogelijk duplicaat van Elke keer dat ik gebruik sudo het hangt voor het invullen - Harry Tsai


antwoorden:


Ik stelde deze vraag op SO en het werd hier verplaatst. Dat gezegd hebbende, heb ik niet langer de mogelijkheid om de vraag te bewerken alsof ik het bezit, of zelfs het juiste antwoord te accepteren, maar dit bleek de ware reden te zijn waarom en hoe het op te lossen:

Hier gevonden  Gebruiker "rohandhruva" daar geeft het juiste antwoord:

Dit gebeurt als u de   hostnaam tijdens het installatieproces.

Om het probleem op te lossen, bewerkt u het bestand   / 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>

87



Juist. Enigszins verrassend dat distros zoals Fedora geen / etc / hosts bewerken als je je hostnaam tijdens de installatie wijzigt, maar wat dan ook. Dat is open source voor jou! - dimo414
Dit loste mijn langzame sudo-gebruik op, bedankt! Ik heb / etc / hostnaam bewerkt en ben net vergeten het bestand / etc / hosts te bewerken. - Joe
Als u uw hostnaam toevoegt aan de regel 127.0.0.1 of :: 1, kan bepaalde servergerelateerde software vastlopen aan de juiste hostnaam / IP / interface. Een voorbeeld hiervan is Cloudera Manager, de hasoop-services krijgen de verkeerde hostnaam en verwarren CM omdat ze allemaal besluiten naar localhost. Ik stel voor om hieronder een ander antwoord te lezen voor een mogelijke oplossing. Dit kan al dan niet problemen veroorzaken voor een zelfstandig werkstation waar geen andere computers verbinding mee kunnen maken. - ddcruver
Het kan ook /etc/nsswitch.conf zijn (om soortgelijke redenen). De mijne was ingesteld op "hosts: dns-bestanden" en zo werd mijn hostnaam opgezocht op een DNS-server met een lange time-out. Ik veranderde het in "hosts: bestanden dns" en dus zal het eerst in / etc / hosts kijken. Bedankt voor dit antwoord, waardoor ik in nsswitch.conf keek! - Alan Porter


Controleer of je syslog-daemon correct werkt; dit veroorzaakte het probleem voor mij.

Voer de volgende opdracht uit

logger 'Hello world'
  1. Keert het commando binnen een redelijke tijd terug?

  2. Komt 'Hallo wereld' binnen /var/log/syslog?

Als dit niet het geval is, is de syslog-daemon gecrasht. Als u het opnieuw start, moet uw probleem worden opgelost.


20



Vreemd genoeg was dat het probleem voor mij. Wie zou het gedacht hebben. De oplossing voor mij was gewoon om syslog te herstarten. service rsyslog restart - MikeKulls
Hier ook. service rsyslog restart mijn slow sudo-opdrachten opgelost. - Pedro Cordeiro
Vreemd genoeg was dat het probleem voor mij. Daarvoor is het hele verzoek voor de server zo langzaam. Ik wil gewoon weten waarom? - michael wang


Is het een van de bestanden / mappen die het moet lezen in een geneste mount, of triggert het op een of andere manier lezen vanaf een langzaam usb-apparaat? Probeer eens te kijken waar het langzaam is; als het te snel voorbij gaat, doe

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

Elke regel begint met de tijd die is verstreken sinds het invoeren van de vorige syscall.

(De initiële sudo lijkt noodzakelijk te zijn, ik weet niet hoeveel dat de resultaten zal verstoren.)


10



Dankje. Dit is op de vaste schijf, geen USB- of netwerkstation.
@Cuga: en wat heb je geleerd van strace?
@oligofren: je moet sudo strace doen - ysth


Ik heb onlangs ontdekt dat ik hetzelfde probleem had. Er was geen sudo-vertraging geweest en toen opeens, ongeveer 10-20 seconden vertraging. Ik heb het specifieke probleem bepaald met behulp van:

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

Als uzelf:

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

En zoek vervolgens waar de systeemaanroepen hangen.

In MIJN geval vond ik dat het aan een DNS-vertaling hing, blijkbaar een van de DNSen in mijn lijst /etc/resolv.conf was erg druk of was slecht. Dus ik veranderde de resolutie volgorde en poof dingen werkte snel weer.


7





Ik ben niet zeker van Fedora, maar ik heb andere systemen gebruikt waar sudo zou controleren waar je bent ingelogd, en als je DNS niet goed is ingesteld, kan dit eeuwen duren om time-out. Dit is ook te zien als SSH binnenkomt op de machine - het duurt leeftijd om met een prompt te komen.


5





Ik had hetzelfde probleem, ik controleerde /var/log/auth.log en syslog op fouten. Blijkt dat mijn LDAP-server niet kon worden bereikt en het alles vertraagde.

Ik heb LDAP-gebaseerde auth niet meer gebruikt, dus heb ik alle "ldap" -referenties van /etc/nsswitch.conf verwijderd

Sindsdien werkt alles weer als een charme.


4



Waarom plaats je een duidelijk niet-verwant antwoord (het OP gebruikte geen LDAP) op een vijf jaar oude vraag? - Sven♦
Omdat het iedereen kan helpen. Ik controleerde alle dingen die hier werden genoemd, maar niets hielp. Iemand anders is misschien gefocust om met mijn antwoord in de goede richting te kijken door te controleren of hij LDAP-verbindingsproblemen heeft als de onderliggende reden van het trage en niet-reagerende sudo-commando. Het is net zo relevant als de DNS-gerelateerde antwoorden in die zin dat iets achter de covers een fout heeft die niet direct zichtbaar is voor de gebruiker. Ik beschouw deze site als een algemene bron van kennis en niet alleen als een enkele vraag / antwoord-type website. Het gaat om het verzamelen van relevante kennis. - Sakuraba
Ook wie ben jij in hemelsnaam om mijn hulp in diskrediet te brengen. Deze site werkt omdat het delen van kennis wordt gestimuleerd, niet omdat mensen ondergewaardeerd zijn. Als je het niet leuk vindt, mag je het negeren. - Sakuraba


In veel gevallen wordt de hostnaam gevonden (die is geconfigureerd in /etc/sysconfig/ netwerk) bestaat niet in /etc/hosts het dossier; dus bij het toevoegen van bovengenoemd bestand, wordt het bestand onmiddellijk geopend.


4





Ik had een soortgelijk probleem, ik repareerde het door zowel de hostnaam (bijv. Mybox) als de volledige uitvoer van de opdracht hostname (mybox.mydomain.com) te plaatsen. Dit maakte het helemaal goed. Ging van 2 minuten om / etc / hosts te openen naar onmiddellijke toegang.


3





Van het bekijken van het monster sudoers bestand dat ik heb, ik geloof dat er een spatie na de NOPASSWD: beetje.


1



Ik heb een spatie toegevoegd, maar deze heeft nog steeds de vertraging. Thx voor de suggestie.


Controleer uw / etc / hosts-bestand en zorg dat u een invoer voor 127.0.0.1 hebt

(bron)


1





Na het repareren van eventuele hostproblemen moet u ervoor zorgen dat u alle slechte DNS-cache wist als u een DNS-caching-applicatie uitvoert zoals nscd:

/etc/init.d/nscd force-reload

1