Du existierst nicht, geh weg!

Hin und wieder (dreimal in den letzten vier Wochen) existiere ich nicht. Die Nachricht im Titel dieser Frage ist meine Antwort, wenn ich versuche, sie auszuführen, sshwährend sie nicht vorhanden ist. Wenn ich nicht existiere, wird beim Ausführen idmeine Benutzer-ID und nicht mein Benutzername angezeigt, wie dies sonst der Fall ist. Und ich kann nicht verwenden sudo:

; sudo date
sudo: unknown uid: 13799

Jedes Mal verschwindet das Problem spontan innerhalb einer Stunde und ich existiere wieder. Glücklicherweise habe ich immer ein Terminalfenster mit einer Root-Shell, sodass ich immer noch im System herumstöbern kann. Und ich sehe nichts falsches, zumindest nichts, aus dem ich einen Sinn machen kann, außer vielleicht diesen Zeilen in /var/log/opendirectoryd.log:

2012-02-27 07:31:39.911 CET - 70535.351417.351419.351421 - Client: netstat, UID: 0, EUID: 0, GID: 0, EGID: 0
2012-02-27 07:31:39.911 CET - 70535.351417.351419.351421, Node: /Local/Default, Module: PlistFile - recordtype 'networks' attribute 'address' is not indexed: performance hit
2012-02-27 07:31:40.904 CET - 70539.351444.351448 - Client: launchd, UID: 13799, EUID: 13799, GID: 20, EGID: 20
2012-02-27 07:31:40.904 CET - 70539.351444.351448, Module: SystemCache - unable to find node 71E63E19-F41E-4AF3-89A0-F50FE5185E5B
2012-02-27 07:31:40.905 CET - 70539.351444.351448 - Client: launchd, UID: 13799, EUID: 13799, GID: 20, EGID: 20
2012-02-27 07:31:40.905 CET - 70539.351444.351448, Module: SystemCache - ODQueryCreateWithNode failed with error 'Node ID is invalid' (90001)

Diese stammen von heute Morgen, als ich den Laptop aufgeweckt habe (ich habe odutildie Protokollierungsstufe ein wenig angehoben). Ich habe herumgespielt dsclund alles scheint normal zu sein - ich kann alle Daten meines Benutzers sehen - aber ich bin nicht sehr vertraut mit Verzeichnisdiensten, daher habe ich vielleicht etwas verpasst. (Wie kann ich mich mit dscl bei uid nachschlagen?)

Meine Frage ist also zweifach: Läutet dieses Problem eine Glocke? Mein Google-Fu ist nicht in der Lage, etwas Relevantes zu finden. Und können Sie Vorschläge machen, um das Problem besser in den Griff zu bekommen, Tests durchzuführen und Dinge zu suchen?

Während ich diese Frage getippt habe, endete die heutige Veranstaltung und ich existiere wieder. Es kann also eine Woche oder länger dauern, bis ich das nächste Mal das Debuggen erhalte. Ich bin auf OS X 10.7.3 übrigens auf einem MacBook Pro.

lion open-directory

— Harald Hanche-Olsen
quelle

Haben Sie Lion Server auf Ihrem MacBook Pro installiert und führen Sie Open Directory aus? Ist Ihr MacBook Pro an Ihrem Arbeitsplatz oder an einem anderen Ort mit einem Open Directory-Server verbunden?

— Jason Salaz

@JasonSalaz: Nein, es ist einfach Lion, nichts Besonderes, Standard-Setup. Es wird opendirectorydlokal ausgeführt, aber dies ist die Standardkonfiguration, die meiner Meinung nach von einer Reihe von Computern mit dem Migrationsassistenten bis zurück zu Tiger geerbt wurde, sofern der Arbeitsspeicher verfügbar ist (was möglicherweise nicht der Fall ist - ich habe möglicherweise vor Jahren während einer Migration von Grund auf neu begonnen ).

— Harald Hanche-Olsen

apple.stackexchange.com/questions/43940/… ist diesem Thread sehr ähnlich.

— mspasov

@mspasov: Danke für den Hinweis! Ich werde die dort erwähnte Fehlerbehebung versuchen, wenn sie mir das nächste Mal passiert, da ich mir sicher bin, dass es so sein wird.

— Harald Hanche-Olsen

Dies klingelt tatsächlich, da ich ähnliche Probleme auf einer Vielzahl von Systemen gesehen habe, die von 10.3 bis 10.6 reichen. Hier sind einige der Ursachen, die ich in keiner bestimmten Reihenfolge beobachtet habe.

Falsche DNS-Serveradressen in der Netzwerkkonfiguration
Falscher LDAP-Server oder Server-Aliase (wenn der Computer Teil eines LDAP- oder OpenDirectory-Netzwerks ist)
Fehlerhafte PAM-Module (wenn Sie Software von Drittanbietern installiert haben, die PAM verwendet oder installiert /etc/pam.d)
Mischen von lokalen / BSD-Konten mit LDAP / OpenDirectory-Konten. Dies kann vorkommen, wenn Sie Konten haben, die wiederholt über viele Versionen migriert wurden.
Konto-GUIDs werden aufgrund einer Migration oder einer anderen Beschädigung der OpenDirectory-Datenbank nicht mehr synchron.
Beachten Sie, dass es bis zu einer Minute dauern kann, bis der Computer aus dem Ruhezustand aufwacht oder den Startvorgang beendet hat, bevor das Authentifizierungssystem voll funktionsfähig ist. Netzwerkkonnektivitätsprobleme können dies erheblich verzögern, insbesondere wenn das System Teil eines LDAP / OpenDirectory-Netzwerks ist.

Da Sie Konten migriert haben, versuchen Sie, ein neues Konto einzurichten, und prüfen Sie, ob das Problem dort auftritt. Möglicherweise können Sie das Problem beheben, indem Sie sich in die OpenDirectory-Datenbank einarbeiten. Es ist jedoch möglicherweise einfacher, das Problemkonto von Grund auf neu zu erstellen.

Aktualisieren

Da die UID zu irgendeinem Zeitpunkt in der Vergangenheit aus NFS-Gründen geändert wurde, sind GUID und UID wahrscheinlich nicht synchron. Probieren Sie die folgenden Terminalbefehle aus, um festzustellen, ob sich Unix und Directory Services auf derselben Seite befinden:

dscl . -read /Users/sbnoble GeneratedUID
dscl . -read /Users/sbnoble UniqueID
id

Die von "UniqueID" und "id" ausgegebene UID sollte mit der erwarteten NFS-UID übereinstimmen.

— Seth Noble
quelle

Vielen Dank. Ihre ersten drei Alternativen scheinen in meinem Fall nicht wahrscheinlich zu sein, aber Nummer vier und fünf können einen Blick wert sein. Da das Problem so selten auftritt, kann ich mir nicht vorstellen, ein neues Konto einzurichten, um festzustellen, ob das Problem auftritt, und es gibt eine praktikable Strategie. Ich müsste all meine Arbeit in dem neuen Konto erledigen, was bedeutet, dass ich alle meine Dateien dorthin migrieren müsste. Aber vielleicht könnte ich das tun und einfach meinen alten Account aufgeben. Hmm…

— Harald Hanche-Olsen

Eines habe ich vergessen zu erwähnen: Da ich auf Dateien über NFS zugreifen muss, ist es mir wichtig, meine UID auswählen zu können. Ich habe das in der Vergangenheit getan und die UID von dem System geändert, das mir beim Einrichten des Kontos zugewiesen wurde. Das ist vielleicht eine mögliche Ursache für die gegenwärtigen Probleme.

— Harald Hanche-Olsen

Das würde es schaffen. OS X hat effektiv zwei Benutzer-IDs: die klassische Unix-UID und eine eigene GUID (GeneratedUID). Daher sind Ihre UID und Ihre GUID nicht synchron. Das Problem in "OS X Server" mithilfe des Arbeitsgruppen-Managers zu beheben ist nicht zu schwierig. Aber im Client müsste man wohl auch die dsclKommandozeile benutzen . Siehe meine Bearbeitung oben.

— Seth Noble

Hmm. Mein UniqueID und (Unix) id beide kommen als 13799. Die GeneratedUID 781F6CC1-C5B3-4016-80AE-BE405C3EC721 ist, nicht , dass ich erwarten würde , dass die anderen entsprechen.

— Harald Hanche-Olsen

Die von Ihnen veröffentlichten Protokolleinträge zeigen, dass das System Probleme hat, die GUID zu finden 71E63E19-F41E-4AF3-89A0-F50FE5185E5B. Ich vermute, dass mit Ihrem Konto mehrere GUIDs und UIDs verknüpft sind. Wahrscheinlich müssen Sie einige Untersuchungen durchführen, dsclum festzustellen, welche Benutzerdatensätze vorhanden sind, und sie möglicherweise zu konsolidieren.

— Seth Noble