Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Software>Ruhezustand bricht immer ab

Ruhezustand bricht immer ab

cfkane11.09.1708:28
Moin allerseits!

Obwohl mein iMac sonst monatelang ohne Neustart läuft, zickt er seit ca. zwei Wochen. Kaum aktiviere ich den Ruhezustand, verläßt er ihn sofort wieder.
Habe das jetzt mal mit ein paar Programmen getestet.
Starte Mail oder InDesign keine Auswirkung
Starte Safari oder Firefox kein Ruhezustand mehr!
Hilft auch nicht, wenn ich die Browser wieder beende.

Hat da einer eine Idee, woran das liegen könnte?
Gibt es Logs, wo dazu was protokolliert wird? Oder ...?

Die einzige Konfigurationsänderung in der letzten Zeit (an die ich mich erinnere) war die Installation von Mellel 4.

Hardware: weißer iMac 2007
OS: 10.6.8

Besten Dank und schöne Grüße,
0

Kommentare

Jaguar1
Jaguar111.09.1709:29
Irgendwelche neuen externe Geräte?

BTW: wie wär's mal mit was neuem?
„Die Menschen sind nicht immer was sie scheinen, aber selten etwas besseres.“
0
cfkane11.09.1709:42
Jaguar1
Irgendwelche neuen externe Geräte?
Stimmt, eine neue externe FW-Platte. Aber die lief das letzte Mal ... bestimmt auch schon wieder 14 Tage her. Aber warum sollte sich die auf die Browser auswirken?
Jaguar1
BTW: wie wär's mal mit was neuem?
Doch nichts überstürzen
+2
Deichkind11.09.1710:54
Protokolldateien des Systems kann mit dem Programm "Konsole" (in Programme/Dienstprogramme) öffnen, während man als Administrator angemeldet ist.
0
chb11.09.1714:54
pmset -g log

Da steht auch immer der jeweilige Auslöser für Sleep / Wake usw. dabei
+3
heiko.w
heiko.w11.09.1715:11
Danke chb, das kannte ich noch nicht!

Am besten gibt man im Terminal folgendes ein:
pmset -g log > $HOME/Desktop/Ruhezustand.log

Dann bekommt man die Logdatei auf dem Schreibtisch abgelegt.
+2
cfkane11.09.1721:21
Habt alle Dank für Eure Hilfe!

pmset -g log funktioniert nicht bei mir nicht. Da kommt:
Couldn't locate MessageTracer database (at path /var/log/DiagnosticMessages)

Aber der Blick in die Konsole hat geholfen! Die Software Awaken war der Übeltäter! Deren Hintergrunddienst beendet – und schon schläft der iMac wieder

PS: Ist es jetzt tragisch/schlechtes Zeichen, daß pmset nicht will?

Grüße,
0
Peter Eckel12.09.1700:07
Versuch's mal mit

sudo pmset -g log

unter nachfolgender Eingabe Deines Paßwortes. Ich habe kein so altes System mehr, aber es klingt ein wenig nach Dateitzugriffsberechtigung. Mit aktuellen Systemen geht es.
„Ceterum censeo librum facierum esse delendum.“
0
cfkane12.09.1700:29
Peter Eckel
Versuch's mal mit

sudo pmset -g log

Guter Hinweis. Aber sudo kapier ich immer nicht so recht. Er will dann ein Paßwort haben ... das vom aktuellen Nutzer? Aber das bringt ja nix, weil's nur ein Standardnutzer ist. Und nach einem Nutzernamen (für den Admin) fragt er nicht.
Also hab ich mich erstmal mit su als Admin angemeldet und dann pmset aufgerufen. Es folgte eine sehr lange Ausgabe. Also lag's an den Rechten!

Aber so hilfreich finde ich die Liste nicht. Es passierte ganz oft, daß es zur selben Zeit eine erfolgreiche Sleep-Message und eine Wake-Message (von USB7?!) gab. Tja ...
0
cfkane12.09.1700:57
Tja, vorbei das Glück. Wieder kein Schlafmodus (ich offenbar auch nicht ...). Die Lösung war auch ein bißchen komisch, weil Awaken ja nix mit den Browsern zu tun hat.
Beim Versuch, den Ruhezustand zu erreichen, ist die Konsole jetzt voll mit Meldungen über geänderte Hostnamen. Verhindert das den Ruhezustand? Aber das ist kein Haken bei "Bei Netzwerkzugriff aufwachen".

Versteht jemand den folgenden Log-Auszug?
Ich lese es so, daß der Mac versucht, die Zeit abzufragen, was aber fehlschlägt, worauf der Hostname von .local auf .fritz.box geändert wird.
Seltsam.

12.09.17 00:38:46 ntpd[35] sendto(17.253.54.253) (fd=22): Network is unreachable
12.09.17 00:38:48 configd[14] setting hostname to "Nautilus.local"
12.09.17 00:38:48 configd[14] network configuration changed.
12.09.17 00:38:48 configd[14] network configuration changed.
12.09.17 00:38:48 mDNSResponder[18] DeregisterInterface: Frequent transitions for interface en0 (2001:0A61:12D6:E701:021B:63FF:FE30:A7FE)
12.09.17 00:38:51 ntpd[35] bind() fd 25, family 30, port 123, scope 6, addr fe80::21b:63ff:fe30:a7fe, in6_is_addr_multicast=0 flags=0x11 fails: Can't assign requested address
12.09.17 00:38:51 ntpd[35] unable to create socket on en0 (17) for fe80::21b:63ff:fe30:a7fe#123
12.09.17 00:38:51 configd[14] network configuration changed.
12.09.17 00:38:51 mDNSResponder[18] RegisterInterface: Frequent transitions for interface en0 (FE80:0000:0000:0000:021B:63FF:FE30:A7FE)
12.09.17 00:38:52 configd[14] network configuration changed.
12.09.17 00:38:52 configd[14] setting hostname to "nautilus.fritz.box"
12.09.17 00:38:52 configd[14] network configuration changed.
0
cfkane12.09.1708:42
Früh kommen die gleichen Netzwerkmeldungen, aber dafür klappt der Ruhezustand öfters. Nur abends fast nie ... Schräg. Und nervig.
0
Peter Eckel12.09.1722:14
cfkane
Aber sudo kapier ich immer nicht so recht. Er will dann ein Paßwort haben ... das vom aktuellen Nutzer? Aber das bringt ja nix, weil's nur ein Standardnutzer ist. Und nach einem Nutzernamen (für den Admin) fragt er nicht.

Genau das ist der Sinn der Sache. Bei sudo wird genau das Paßwort des aktuellen Nutzers abgefragt, weil der das des Administrators ja gerade nicht wissen soll.

Das ist natürlich nur die halbe Miete, denn wie Du richtig bemerkst, muß irgendwo ja auch noch die Berechtigung des Benutzers hinterlegt sein muß, privilegierte Kommandos auszuführen. Der Schlüssel ist die Datei /etc/sudoers.

Standard bei macOS ist, daß die Administrativ-Benutzer in der Gruppe 'admin' sind und die Benutzer dieser Gruppe nach Eingabe ihres eigenen Paßwortes alle Kommandos unter root ausführen können. Das geht aber auch sehr viel feinfühliger. 'man sudoers' ist eine interessante Lektüre, wenngleich etwas sperrig.
„Ceterum censeo librum facierum esse delendum.“
0
MikeMuc12.09.1722:53
Man kann mit su in der Konsole zu einem Adminuser wechseln. Dann klappt es auch mit sudo.
0

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.