Konsolenmeldungen erscheinen nicht

[pti'Luc]

Vielleicht noch eine Hilfestellung zum Auffinden der richtigen Verzeichnisse:
Wenn Du in dem Programm "Konsole" einen Rechtsklick auf die Pfad machst (z.B. ~/Library/Logs), dann kannst Du dort "Im Finder zeigen" auswählen. Dann muss man auch nicht mühsam suchen!

Wie Rastafari ja schon sagte, dürfen diese drei Verzeichnisse gefahrlos geleert werden:

/Library/Logs/
$HOME/Library/Logs/ oder auch ~/Library/Logs/
/private/var/log/

 

[raven]

So ich werde mal den rat von rastafari und pti'Luc ausfühen und mich auf die Löschaktion begben. danach neu booten ins Terminal sehen und melde mich wieder ob da was geschreiben wird. Besten Dank für eure Geduld und Hilfe

Der ganze Krempel gelöscht, neu gebootet und die Konsolenmeldungen sind wieder da. Ab Bottvorgang.
Diesmal alles gelösch wie empfohlen.

/Library/Logs/ 
~/Library/Logs/ 
/private/var/log/

 

[SilentCry]

Das geschieht aber bei einer (später wiederhergestellten) simplen Dateikopie ganz unwillkürlich von alleine.

Und? Dann stellt man die Zugriffstechte wieder her, wenn das wirklich so sein sollte. Wie gesagt, bei meinem Versuch (sudo mv com.apple.syslogd.plist sicherheitskopie.com.apple.syslogd.plist und retour) ist alles ohne weitere Schritte glatt gegangen. Aber ein sudo chmod ... hätten wir auch noch hin bekommen, wenn die fehlende/zugrifssrechtverwirrte plist-Datei den syslogd-Start behindert hätte.

Natürlich läuft er weiter. Bis zum nächsten Systemstart. Nicht hilfreich.

Und, frei nach Buzz Lightyear: "und darüber hinaus".

Unsinn. Programme starten sich nicht wie von Geisterhand selbst.
(An dem Tag an dem das passiert kloppe ich OS X in die Tonne, und Apple kann 95% seiner Programmierer entlassen. Fantasterei.)

Tja, sorry, du liegst schlicht falsch. Ich habe es PHYSISCH AUSPROBIERT, was also, bei allem Respekt, willst du mir für Bullshit erzählen? Ich habe die .plist-Datei umbenannt, den Rechner neu gestartet und er lief nicht nur wie ein Glöckchen sondern auch der syslogd wurde vom launchdeamon gestartet. Also entweder nennst du mich hier öffentlich einen Lügner, dann ist das Gespräch beendet oder du gestehst einfach ein, dass der Effekt mit der plist-Datei nicht annähernd so dramatisch ist, wie du das hier schilderst.

Den Rest deines Postings lasse ich mal gut sein, mögen die Mitleser entscheiden, ob deine Vergleiche passend sind, meiner Meinung nach sind sie es nicht, aber aus Respekt, den ich durch die früheren Dialoge mit dir gewonnen habe, stelle ich mein Empfinden darüber mal in die Ecke,

Nur das hier:

"Note that allowing non-root write access to the /System/Library/LaunchDaemons directory WILL render your system unbootable."
Nicht "may", nicht "can", kein "possibly".... wieso wohl?

[/quote]
Du könntest jetzt auch aus dem Booby Trap Manual der Navy Seals zitieren, dass man nicht in die eigene Sprengfalle laufen soll. Auch richtig, nur hat es nichts mit dem Thema zu tun. Ich wollte nie die Zugriffsrechte ganzer LaucnDaemon-Verzeichnisse ändern, es ging lediglich um eine f*ing .plist-Datei, deren Fehlen NACHGEWIESENERMAßEN keinerlei Auswirkung auf die Systemstabilität hat.

 

[Rastafari]

Dann stellt man die Zugriffstechte wieder her, wenn das wirklich so sein sollte.

Hättest du rechtzeitig dran gedacht - bevor die Kiste beim nächten Start komplett streikt?
Gibs zu - nein. Du hast das schlicht gar nicht bedacht.

ie gesagt, bei meinem Versuch (sudo mv com.apple.syslogd.plist sicherheitskopie.com.apple.syslogd.plist und retour) ist alles ohne weitere Schritte glatt gegangen.

Ein mv ändert ja auch keine Dateirechte. Ein cp aber schon.

bei allem Respekt, willst du mir für Bullshit erzählen?

Bei allem Respekt, zügle dein Adrenalin und fahr lieber das Dopamin hoch.

Ich habe die .plist-Datei umbenannt

Und, was soll das aussagen? Der Dateiname ist so wichtig wie ein Fleck Buttermilch im Teppich.
"Informativ", nichts weiter. Keinerlei Bedeutung für genau gar nichts.
Natürlich zeigt ein Umbenennen keinen Effekt, hätte ich dir auch sagen können.
*Entferne* die Datei doch mal aus diesem "magischen" Ordner. Have fun.

Also entweder nennst du mich hier öffentlich einen Lügner, dann ist das Gespräch beendet oder du gestehst einfach ein, dass der Effekt mit der plist-Datei nicht annähernd so dramatisch ist, wie du das hier schilderst.

Oder ich nenne dich einfach jemanden, der vielleicht gerade ganz gewaltig auf seinem Sauerstoffschlauch steht und sich viel zu weit aus dem Fenster lehnt.

 

[pti'Luc]

Och Jungs! Das muss doch wirklich nicht sein ...

 

[Rastafari]

Och Jungs! Das muss doch wirklich nicht sein ...

EY DU! Willst du mir produzieren oder was? Ich weiss wo deine Haus wohnt!

 

[pti'Luc]

Ne, weeßte nüsch!
Außerdem hab ich Besseres zu tun!

 

[raven]

Och Jungs, ich hatte ein Probelm in der Hoffnung das es bei hatte bleibt und nicht wiederkommt. Und bin dankbar, dass ihr geholfen habt. Respekt von euch beiden, Rastafari und SilentCry, über euer Wissen, aber geht euch nicht an die Gurgel bitte. Meine Kenntnisse sind zu bescheiden, deswegen und mitunter bin ich ja bei AT.

Meine Konsole werde ich mal eine Weile beobachte, spordisch. Bei aufkeimenden Problemen wende ich mich gerne wieder an die Spezialisten

 

[SilentCry]

Das ist mir zu doof. Du hast schlicht mächtig übertrieben, hast Zugriffsrechte von Verzeichnissen in Zusammenhang gebracht mit dem moven einer Datei, was miteinander so viel zu tun hat wie ein Ziegelstein mit einem Salzkristall und ich habe deine Überdramatisierung locker mit einem echten Test widerlegt. Fullstop.
Zum Mitlesen: Ich habe es AUSPROBIERT, es passiert ÜBERHAUPT NICHTS Böses wenn man diese .plist-Datei moved, deine ganzen Ausführungen über "Zerschießen vom System" sind einfach nur mächtig übertrieben und nicht ICH sollte das Dopamin hoch fahren sondern du deinen Drama Queen-Modus beenden und wieder auf den Boden der Fakten zurückkehren, und zwar den Fakten, die aufgrund meines einfachen Tests einwandfrei belegt sind während du nur irgendwelche Manuals zitierst, die wenig bis nichts zu dem schlichten Thema dieser .plist-Datei zu tun haben.

 

[Rastafari]

Ich kanns dir nur noch mal sagen:
Syslog ist ein A und O beim "auf die Beine stellen" einer lauffähigen Unix-Distri - und das ist beileibe nicht trivial ans laufen zu kriegen.
Ein zur Laufzeit nicht verfügbares Syslog ist eine tückische Falle, die ein Unix-System voll auf die Fresse legen kann - bei gleichzeitig einer sehr problematischen Fehlersuche danach, und bei sehr stark einschränkten Reparaturmöglichkeiten, weil dann gerne schlicht gar nichts mehr geht.

Die aktuelle Implementation des Syslog-Subsystems in OS X kümmert sich um weit mehr als nur die recht banalen Konsolenprotokolle, die du als Benutzer oder Admin mit dem entsprechenden Dienstprogramm einsehen kannst. Die Verwaltung und dynamische Pflege von solchen fundamentalen Unix "Nuts & Bolts" wie zB "utmp", "wtmp" und ähnliches erledigt dieser Daemon mal eben so nebenher auch gleich noch mit. Es sei denn, du hast ihn kaltgestellt - dumm gelaufen.
Wenn du meinst, irgendwie auch ohne solche absolut unentbehrlichen Essentials um die Runden zu kommen - nur zu.
"Versuch macht kluch, und Crash macht fesch".
Ist ja nicht mein, sondern dein Rechner, und solange der nicht als Feuerball vom Himmel stürzen oder in einer gewaltigen Explosion ganze Stadtteile einäschern kann, wird das mich nicht sonderlich jucken wenn du dein fälliges Lehrgeld zu zahlen hast.
Wünsche ein lustiges, frohes frickeln noch. Und tschüss.

 

[SilentCry]

Lieber Rastafari, alter Kumpel aus vielen Sicherheitsdiskussionen, lass mich versuchen, das Verhältnis zwischen uns wieder zu kitten.
Du hattest Recht, dass:
- mein Versuch das Problem nicht löst
- die .plist nicht wie ich erwartet habe neu angelegt wird (da habe ich Apple wohl überschätzt)
- alle Eingriffe in Systemdienste ein Risiko bergen (das ich aber mit der Sicherheitskopie kalkulierbar gemacht habe)
- man die Zugriffsrechte für diese Systemdienste nicht ändern darf (was aber auch nicht mein Ansatz war)
- dein Lösungsvorschlag mit dem Löschen der Logs im Gegensatz zu meinem Versuch das Problem gelöst hat (1:0 für dich)

Bitte aber sei so nett und gestehe ein, dass
- ich ravens System keinem unkalkulierten Risiko ausgesetzt habe
- mein kleiner Test gezeigt hat, dass das Löschen dieser Datei keine dramatischen Auswirkungen hat und sich auch leicht wieder rückgängig machen lässt
- ich auch nie präpotent behauptet habe, das Löschen der plist-Datei würde das Problem sicher lösen sondern dass ich das als _Versuch_ formuliert habe.
- du mit deinem Hinweis auf die Rechte der Systemdienste einen wesentlich weiter gefassten Aspekt beleuchtet hast als es das moven der .plist-Datei betraf (durchaus interessanter Aspekt, nur eben viel mehr als mein recht banaler move...)

Ich habe mir auch erlaubt, die Developer Library zu Rate zu ziehen. Ich kann nicht erkennen, inwiefern der syslogd für mehr als das Logging und Bereitstellen von Verwaltungs-APIs verantwortlich sein soll. Ja, er startet den aslmanager periodisch, aber auch da sehe ich jetzt nicht das dramatische Problem.

Versteh' mich bitte richtig: Natürlich sollte man ausgesprochen _vorsichtig_ sein, wenn man im Betriebssystem herumwerkelt. Ich kann nur deinen indirekten Vorwurf, ich hätte raven dazu angeleitet, ihr System nachhaltig und irreparabel zu beschädigen, nicht im Raum stehen lassen. Ich kenne raven gut, sie ist in der IT auch sehr erfahren und gewohnt, Vorsicht walten zu lassen, einem Newbe hätte ich sowieso schon keine Shell-Aufgabe gestellt.

OK? *versöhnlich schau und die virtuelle Hand entgegen streck*

 

[Rastafari]

- mein kleiner Test gezeigt hat, dass das Löschen dieser Datei keine dramatischen Auswirkungen hat

Nein. Du hast gar nichts getestet, ein reines Umbenennen dieser Dateien (ohne sie an einen anderen Ort zu verschieben) hatte nämlich überhaupt keinen Effekt. Du hast dich damit nur erfolgreich selbst ausgetrixxt.

und sich auch leicht wieder rückgängig machen lässt

Im Single-User Mode oder von einem externen Volume gebootet - ja. Sonst nicht.
Ist nicht unbedingt die Art von Tips, die man wie Bonbons verteilen muss - imho.

nur eben viel mehr als mein recht banaler move...

Nochmals: verschieben und wieder zurück verschieben ist *nicht* äquivalent zu kopieren und dann verschieben.
(An anderen Stellen im System kannst du da sogar noch viel mehr verbiegen, denn der 'kextd' beispülsweise wertet auch die Zeitstempel von Objekten aus.)

Ich kann nicht erkennen, inwiefern der syslogd für mehr als das Logging und Bereitstellen von Verwaltungs-APIs verantwortlich sein soll

Echt nicht?
-utmp_ttl Sets the time-to-live in seconds for messages used by the utmp, wtmp, and lastlog subsystems. ...
-fs_ttl Sets the time-to-live in seconds for filesystem error messages generated by the kernel. ...
D'accord?

Natürlich sollte man ausgesprochen _vorsichtig_ sein, wenn man im Betriebssystem herumwerkelt.

Ich formuliere das simpler: FINGER WEG vom Ordner /System/
Da drin gibts keine dynamischen Daten, da drin geht also nichts einfach so mal eben kaputt, da drin gibts also auch nichts zu basteln wenns klemmt.

 

[SilentCry]

Nein. Du hast gar nichts getestet, ein reines Umbenennen dieser Dateien (ohne sie an einen anderen Ort zu verschieben) hatte nämlich überhaupt keinen Effekt. Du hast dich damit nur erfolgreich selbst ausgetrixxt.

Das sehe ich nicht so. Unter Unix ist ein mv genau das Kommando der Wahl dafür. Und wenn der syslogd so clever sein soll, eine umbenannte .plist-Datei zu laden und zu finden, dann hätte ich dafür gerne einen Beweis.
Fakt ist: Ich habe dem syslogd die Datei unzugänglich gemacht und er ist trotzdem gelaufen. Keine deiner angedeuteten Möglich- oder Beinahe-Katastrophen sind passiert.

Im Single-User Mode oder von einem externen Volume gebootet - ja. Sonst nicht.
Ist nicht unbedingt die Art von Tips, die man wie Bonbons verteilen muss - imho.

d'acord. Aber raven kenne ich gut genug. Die käme auch klar mit einem Single User Mode.

Nochmals: verschieben und wieder zurück verschieben ist *nicht* äquivalent zu kopieren und dann verschieben.
(An anderen Stellen im System kannst du da sogar noch viel mehr verbiegen, denn der 'kextd' beispülsweise wertet auch die Zeitstempel von Objekten aus.)

Stimmt. Nächstes mal drücke ich mich deutlicher aus und gebe auch dem mv-Befehl mit an.

Echt nicht?
-utmp_ttl Sets the time-to-live in seconds for messages used by the utmp, wtmp, and lastlog subsystems. ...
-fs_ttl Sets the time-to-live in seconds for filesystem error messages generated by the kernel. ...
D'accord?

Hab ich gelesen, aber trotzdem, alles "nur Logging". Na, dann läuft im schlimmsten Fall ein Log nicht. Was für eine Katastrophe! Ah, als Reflexion: Quel catastrophe.

Ich formuliere das simpler: FINGER WEG vom Ordner /System/
Da drin gibts keine dynamischen Daten, da drin geht also nichts einfach so mal eben kaputt, da drin gibts also auch nichts zu basteln wenns klemmt.

Dann formuliere ich es auch mal simpler: Der Feigling stirbt tausend Mal, der Mutige nur ein Mal. (Und der dumme Mutige halt recht früh, zugegeben aber ich habe ja keine Tips für erfolgreiches Gewinnen beim Russischen Roulette ausgeteilt, die sich dann als riskanter erwiesen hätten...)

 

[Rastafari]

Das sehe ich nicht so.

"To see or not to see - das gibt 'ne Quetschung"
[Willi Schüttelbier; "Omelett, Prinz aus Dämlichkeit"; dritter Akt, erste Szene]

Unter Unix ist ein mv genau das Kommando der Wahl dafür.

Klar ist es das. Die Frage ist halt nur... wohin?

Und wenn der syslogd so clever sein soll, eine umbenannte .plist-Datei zu laden und zu finden, dann hätte ich dafür gerne einen Beweis.

Den hätte ich auch gerne. Weil syslogd diese Datei weder sucht noch findet, geschweige denn sie irgendwie benutzt.
Falsche Baustelle. Versuchs mal mit einem Grundkurs zu launchd.

Ich habe dem syslogd die Datei unzugänglich gemacht

Sag' ganz langsam: "Cheeeeeeze"

Hab ich gelesen, aber trotzdem, alles "nur Logging".

Fehler/Statusmeldungen des Kernels zu Dateisystemen sind alles andere als nur 'logging'.

Der Feigling stirbt tausend Mal, der Mutige nur ein Mal.

Auf in den Kampf, Don Quichotte.

 

[SilentCry]

Hm. Wenn ich Don Quijote bin, bist du dann die Windmühle?

Aber auch ich kann zitieren, wenn auch nicht Shakespear, so doch Peter Rapp, ein österreichischer Moderator und Entertainer, als mitten in einer Life-Show unmittelbar neben ihm ein rund 20 Kilo schwerer Scheinwerfer unter lautem Getöse aufschlug: "Regie! Scheinwerfer 12 ist soeben ausgefallen" und er hat dann unbeeindruckt vom Beinaheableben einfach weiter moderiert.

Genau so hat sich mein syslogd verhalten. Und einen Grundkurs in launchd spare ich mir, der war hier nicht Thema, ich komme ja nicht aus einem Kulturkreis, in dem man die Eltern für alles verantwortlich macht. Biologisch nicht und auch nicht technisch.
Du willst ja nur wieder ablenken. Im Manual steht deutlich, dass der syslogd diese .plist-Datei verwendet. Die Datei war weg, dem syslogd war's mehr oder minder egal (und vor allem: Es hatte keinerlei unbehebbaren nachteiligen Effekte.)

 

[Rastafari]

Im Manual steht deutlich, dass der syslogd diese .plist-Datei verwendet.

Unsinn. Das gestartete Programm (hier: syslogd) kümmert sich einen Dreck darum, von wem und wie es gestartet wurde.
Die gesamten Ordner LaunchDaemons und LaunchAgents sind das alleinige Habitat von --> launchd.

 

[SilentCry]

man syslogd (Hervorhebung durch mich)):

FILES
/etc/syslog.conf bsd_out module configuration file
/etc/asl.conf asl_action module configuration file
/var/run/syslog.pid process ID file
/var/run/log name of the UNIX domain datagram log socket
/dev/klog kernel log device
/var/log/asl data store directory
/var/log/asl.archive default archive directory
/System/Library/LaunchDaemons/com.apple.syslogd.plist
launchd configuration file for syslogd

Also, wie bereits besprochen, der syslogd wird vom Launch Daemon gestartet, das dabei verwendete Konfigurations-File siehe oben in rot.
Wie man es auch dreht und wendet, moved man das .plist-File weg passiert weder dem launchd noch dem syslogd was Dramatisches.

Edit: Ja, zugegeben, ich hätte nicht schreiben sollen, dass der syslogd diese .plist-Datei _verwendet_, das ist technisch betrachtet falsch. Der launchd nutzt diese Datei um den Start des syslogd steuern/konfigurieren. Ist aber imho jetzt nur eine reine Spitzfindigkeit, es ging um die möglichen (aber nicht realen) dramatischen Auswirkungen des Fehlens dieser .plist-Datei.

 

[Rastafari]

moved man das .plist-File weg passiert weder dem launchd noch dem syslogd was Dramatisches.

Benennst du diese Datei um, passiert genau gar nichts - und genau das hast du vermeintlich "getestet". Der Name dieser Dateien ist nur eine benutzergerechte Konvention, aber tatsächlich für die Funktion völlig irrelevant. Du könntest sie auch in "picture.jpg" oder "mucke.mp3" umbenennen, selbst das würde das reinrassige BSD-Programm launchd nicht die Bohne interessieren.
Entfernst du sie aber, bzw bewegst sie aus diesem Ordner heraus, wird sie von launchd nicht länger erfasst, also auch nicht benutzt, ergo wird das dort eingetragene Programm auch nicht gestartet. Und Programme laufen nun mal nicht, ohne vorher gestartet worden zu sein. Es sei denn, wir reden hier vom "Magically OS" des Bordcomputers auf Gene Roddenberrys Enterprise.

 

[raven]

Den sichern Systemstart habe ich schon mal gemacht. Starten mit gedrückter V Taste, dann werde ich sicherlich auch den Start mit S (Single-User) hinbekommen. Wenn es von Nöten wäre oder würde. Zur allgemeinen Info, bisher schreibt es alles sauber in die Konsole.

Weshalb man das Datum erst am nächste Tag sehen kann würde mich intressieren. Vllt. haben die Fachkräfte hier eine Erklärung dazu. Es stellt für mich kein Problem dar, sondern ich würde gerne wissen warum. In der Konsole kann ich das heutige Datum nicht sehen, poste ich das Logfile wird es sichbar.

Beispiel aus der Konsole von gestern Abend und dem Start heute:
Teilsauszug:

18.08.13 20:17:37.771 coreservicesd[62]: SendFlattenedData, got error #268435459 (ipc/send) invalid destination port from ::mach_msg(), sending notification kLSNotifyApplicationDeath to notificationID=139
18.08.13 20:17:38.037 shutdown[631]: halt by name: 
[COLOR=#0000cd]18.08.13 20:17:38.038 shutdown[631]: SHUTDOWN_TIME: 1376849858 37661[/COLOR]
[COLOR=#0000cd]19.08.13 16:45:30.000 bootlog[0]: BOOT_TIME 1376923530 0[/COLOR]
19.08.13 16:45:38.000 kernel[0]: PMAP: PCID enabled
19.08.13 16:45:38.000 kernel[0]: Darwin Kernel Version 12.4.0: Wed May  1 17:57:12 PDT 2013; root:xnu-2050.24.15~1/RELEASE_X86_64
19.08.13 16:45:38.000 kernel[0]: vm_page_bootstrap: 954963 free pages and 85421 wired pages
19.08.13 16:45:38.000 kernel[0]: kext submap [0xffffff7f80737000 - 0xffffff8000000000], kernel text [0xffffff8000200000 - 0xffffff8000737000]
19.08.13 16:45:38.000 kernel[0]: zone leak detection enabled
19.08.13 16:45:38.000 kernel[0]: standard timeslicing quantum is 10000 us
19.08.13 16:45:38.000 kernel[0]: standard background quantum is 2500 us

 

[pti'Luc]

OT: Verdammt, ich hab kein Popcorn im Haus!

Aber: Das ist bisher durchaus lehrreich und auch das Schmunzeln (zu Shakespeare, Rapp und Schüttelbier) bleibt dem Mitleser nicht vorenthalten! Ich mag euch! Nicht aufhören! (Wirklich!)