Konsolenmeldungen erscheinen nicht

[raven]

Meinetwegen Popkorn?
Den Thread habe ich abonniert. Ist intressant und lehrreich. Warum es mir aber damals die Logiles nicht mehr in die Konsole schrieb würde mich intressieren. Zusätzlich möchte ich wissen warum ich täglich in der Konsole wohl die Uhrzeit sehe und erst am Tag danach das Datum. Ausser ich post es hier rein.

 

[pti'Luc]

Nein, ich meinte SilentCry und Rastafari.

 

[SilentCry]

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. ...

Tatsächlich.
Ich habe das jetzt versucht, wenn man die .plist aus dem Verzeichnis HINAUS bewegt, startet der syslogd nicht mehr.
Nun, in Ordnung, ich denke, das war's mit meinem Leben als Techniker, wenn Konfigurationsdateien gelesen werden, obwohl sie nicht mehr so heißen und man sie auf der Shell umbenannt hat, dann brauche ich nichts mehr zu testen oder zu versuchen, dann ist ohnehin alles nur noch schwarze Magie, denn wer sagt denn, dass ein Verschieben das nächste Mal hilft, vielleicht findet das magische launchd die Datei selbst dann noch, wenn ich sie extern auf einen danach abgesteckten USB-Stick verschiebe.

Ich ziehe mich zurück, zu einem System, dem man Dateien umbennen kann, was es aber nicht interessiert, kann ich nie wieder etwas sagen.

Nur eines noch: Der syslogd startet zwar nicht, wenn die Datei "gelöscht" ist, das System läuft aber einwandfrei weiter. Egal wie unfähig ich mich hier bewiesen habe, die schwarze Magie des OS X-Subsystems zu durchschauen, die umbenannte Konfigurationsdateien dennoch aufspürt wie ein Ringgeist den verkleideten Hobbit, die "katastrophale Auswirkung" auf das System bleibt dennoch ein Mythos.

 

[pti'Luc]

Anm.: Das ist gar nicht so magisch, denn das System liest einfach alle *.plist-Dateien ein und der entsprechende Daemon sucht sich dann seinen Teil aus der "Datenbank" im Hauptspeicher. Dafür ist dann aber schon der Name der Datei irrelevant. Erst wenn das System die Datei nicht mehr einlesen kann (weil sie eben nicht mehr im Verzeichnis vorhanden ist), kommt das zum tragen, weil die passenden Einträge fehlen.

Die Aufteilung in die verschiedenen Namen ist damit wirklich nur eine Vereinfachung für den Nutzer, weil er nicht in einer großen Datenbank (wie z.B. bei der Registry von Windows) suchen muss, sondern sich gleich den richtigen Zweig auf Dateiebene raussuchen kann.

Der Grund für das Auffinden ist, dass innerhalb jeder *.plist-atei noch mal das richtige "Label" steht und somit die Zuordnung für die Daemons weiterhin klar gegeben ist.



So zumindest verstehe ich das System hier - Rastafari möge mich gerne ergänzen.

 

[Rastafari]

Der Grund für das Auffinden ist, dass innerhalb jeder *.plist-atei noch mal das richtige "Label" steht

Aus diesem Label wird der intern zur Organisation verwendete Titel des Jobs überhaupt erstmalig definiert. Es wird ohne Ausnahme einfach ALLES an (formell gültigen) Dateien ausgewertet, was sich beim Start von launchd in diesen speziellen Ordnern befindet. Die Label der Jobs sind erst nach ihrem Start von irgendeiner Bedeutung - eventuell (weil später erst ein anderes beliebiges Programm/Skript sich auf ganz bestimmte Namensgebungen verlassen könnte).

 

[Rastafari]

einem System, dem man Dateien umbennen kann, was es aber nicht interessiert

Das war beim Mac schon immer so (in allen Versionen), und das Verhalten ist in der Mehrheit der Ordner in der Library ganz genau das gleiche. Völlig egal ob es sich um Schriftarten, Browser Plugins, Screensaver oder sonstwelche Module handelt, der Name ist Schall und Rauch. Der Ablageort zählt.

 

[SilentCry]

Wie ich schon sagte, das ist ein sehr intransparentes Verhalten. OK, wenn man das mal weiß, dass man mit der Datei "humstiwumsti.ichpfeifaufextensions" aber dem Label "com.apple.syslogd" eine gültige Konfigurationsdatei erstellen kann, die vom System geladen wird, weil sie sich im richtigen Ordner befindet, dann fällt man auf dieses Irrlicht "Dateiname" nicht mehr rein, aber _erwarten_ würde man es so nicht, _erwarten_ würde man, dass die Namen der Konfigurationsdateien ihre Bestimmung determinieren.

Und in Wahrheit hat man damit nichts gewonnen. Denn wenn ich jetzt dafür sorgen will, dass die Konfig für syslogd nicht gelesen wird, reicht es wohl, den Label zu ändern? Oder an wie vielen Stellen verbirgt sich die Bestimmung so einer Datei? Aus meiner Sicht eine fragwürdige Methode. Aber gut, werde ich wohl nicht ändern können.

Anyhow. Ich glaube, das Thema ist jetzt durch, es ist wahr, dass mein erster Test dergestalt keinerlei Wahrheiten brachte, dass der syslogd trotz fehlender plist startet, weil die plist-Datei ja nicht wirklich "gefehlt" hat. Umbenennen, so lernte ich, reicht nicht.

Also: Wenn die plist-Datei fehlt (wirklich fehlt, nicht nur umbenannt war), dann startet er syslogd _nicht_. Das ist die Korrektur zu meinem Testergebnis.
Die Systemstabilität allerdings beeinträchtigt ein nicht gestarteter syslogd nicht. Zumindest nicht so unmittelbar, dass das nicht locker wieder zu beheben wäre, indem man die Datei zurück spielt und ggf. die Rechte wieder herstellt (owner root, gruppe wheel, rw- r-- r--, wenn ich mich richtig erinnere).

Gut, habe was gelernt.

Namen sind nur Schall und Rauch,
sie unterscheiden nicht den Profi vom Laien,
und am Mac gilt dies nun auch
für Konfigurationsdateien.

 

[Rastafari]

Wie ich schon sagte, das ist ein sehr intransparentes Verhalten.

Transparenter geht doch gar nicht mehr.
Alles im Dateisystem frei einsehbar, alles in simplem, normierten XML-Klartext gehalten, alles durch den (fähigen) Admin manipulierbar.
Nur verstehen sollte man vielleicht, wozu eine bestimmte Datei überhaupt dient, bevor man daran rumbastelt. Wäre hilfreich.

BTW
Die typischen Ordnerstrukturen des "init"-Prozesses in klassisch ausgestatteten Unix-Distris funktionieren doch prinzipiell auch nicht viel anders. Auch dort wurden zu gegebenem Zeitpunkt (bei Änderung der 'runlevel') sämtliche Shellskripten abgearbeitet, die sich in den jeweils dafür vorgesehenen Unterordnern befinden. Die Umstellung von 'init' auf 'launchd' hat das alles nur massiv standardisiert, simplifiziert und parallelisiert.
Die Konfiguration von "periodic" funktioniert ebenso nach diesem überaus simplen und anwenderfreundlichen Grundprinzip, auch bei "perl" oder "python" findet sich das, oder oder oder.... ein uralter Hut.

Denn wenn ich jetzt dafür sorgen will, dass die Konfig für syslogd nicht gelesen wird

Nochmals: Das - ist - doch - überhaupt - nicht - die - Config - von - syslogd.
Das ist die "Konfiguration" von ---> launchd

reicht es wohl, den Label zu ändern?

Natürlich nicht.
Dann läuft nur genau der gleiche Job unter anderem Label
(was später zu Problemen führen wird, wenn die zum jeweiligen Daemon dazugehörigen Hilfsprogramme "ihren" Job nicht mehr vorfinden können).

Oder an wie vielen Stellen verbirgt sich die Bestimmung so einer Datei?

Ablageort.

Die Systemstabilität allerdings beeinträchtigt ein nicht gestarteter syslogd nicht.

Nicht (mehr) offensichtlich. Schwerwiegende Probleme mit diversen Funktionen sind aber vorhersehbar.
Kein X11, kein Installationsprogramm, Fehler im Journaling mit drohendem Datenverlust, kein ???, ...

 

[pti'Luc]

Danke für die entsprechenden Ergänzungen und Erklärungen! Wirklich gut, dass mal besser zu verstehen!

 

[MacAlzenau]

Da am jeweiligen Ablageort aber meistens mehrere Dateien befinden, bedeutet das dann, daß das suchende Programme diese alle öffnet, um nach der mit dem richtigen Label zu schauen?

 

[Rastafari]

Nein. Es werden sämtliche Dateien eingelesen, die Inhalte auf Plausibilität überprüft und dann wird simultan alles darin angeforderte gestartet, als jeweils ein "Job" pro Datei. Die "Labels", nach denen ein solcher Job identifiziert und kontrolliert werden kann, existieren erst danach.
Die durch diesen Mechanismus in Gang gesetzten Drittprogramme selbst interessieren sich für diese Launch-Items überhaupt nicht.
Diese Items dienen nur dem "Chefprozess" launchd dazu herauszufinden, welches Programm zu welchem Zeitpunkt, wie häufig, unter welchen Bedingungen usw gestartet werden soll (bzw wann nicht). Ausser dass sie über den Start oder Stop von allen möglichen Hintergrundprozessen bestimmen, haben sie mit deren interner Funktionsweise absolut nichts zu tun.

 

[gKar]

Wie ich schon sagte, das ist ein sehr intransparentes Verhalten. […] aber _erwarten_ würde man es so nicht, _erwarten_ würde man, dass die Namen der Konfigurationsdateien ihre Bestimmung determinieren.

Das ist etwas zu einfach gesprochen. Was genau Verzeichnisse oder Dateien bedeute, legen die beteiligten Parteien fest, und beim System-Ordner besonders kann man davon ausgehen, dass nicht der Benutzer zu diesen Parteien gehört, sondern Systembestandteile die Konventionen festlegen.
Bei Properties zu einem Programm ist z.B. klar, dass das Programm selbst festlegt, wie seine Properties-Datei heißen soll. Daher kann es auch feststellen, ob die Datei (noch) nicht existiert und sie dann neu erstellen. Für den Speicherort gibt es eine Konvention von Apple, aber im Endeffekt entscheidet auch dort das Programm selbst, ob es sich an diese Konvention hält oder nicht.

Bei „Containern“ wie Ordnern für Fonts, Lauch Daemons o.ä. sieht die Lage wieder ganz anders aus. Das System *kann* nicht wissen, nach welchen Dateinamen es suchen soll, es weiß nur, dass es in einem bestimmten Ordner nach Service-Definitionen, Fonts o.ä. suchen soll. So kann man neue Dienste oder Fonts durch einfaches Kopieren von Dateien in einen bestimmten Ordner installieren.
(Natürlich gibt es auch andere Ansätze, z.B. denke ich gerade an die Solaris SMF (Service Management Facility): Dort muss der Admin jede XML (Service Manifest) nicht in ein bestimmtes Verzeichnis spielen, wo das System sie automatisch findet, sondern er kann sie speichern, wo er will, muss sie dann aber per svc-Kommando explizit in die Service-Verwaltung importieren.)

 

[SilentCry]

Alles soweit gekauft. Aber das hier muss ich noch kommentieren:

Nicht (mehr) offensichtlich. Schwerwiegende Probleme mit diversen Funktionen sind aber vorhersehbar.
Kein X11, kein Installationsprogramm, Fehler im Journaling mit drohendem Datenverlust, kein ???, ...

Wir erinnern uns, woher der Vorschlag gekommen ist: raven hatte Probleme mit dem Logging. Mein Ansatz war TESWEISE die .plist-Datei des syslogd zu löschen um zu sehen, OB dieser (oder meinetwegen der launchd) diese Datei wieder anlegt und das Problem behoben wäre. War _wäre_ das Ergebnis gewesen: raven hätte hier gepostet "Hey SilentCry, nach dem Löschen der .plist läuft der syslogd gar nicht mehr" und ich hätte gesagt "ok, dann spiel die Datei wieder zurück, es war nur ein Versuch". Hätten wir dann weiter Probleme wegen der Rechte gehabt wäre dein, rastafari, Expertenwissen über die Rechte sehr hilfreich gewesen, wir hätten die Rechte wieder hergestellt und alles wäre wieder gewesen wie vorher.

_Das_ und nur _das_ meinte ich mit "keine katastrophalen Auswirkungen".

Dass ich wenig über die Mechanismen wusste, wie der launchd seine Prozesse verwaltet und wie die Logik von OS X ist, deren Konfig-Dateien zu lesen, ist zwar richtig, aber meine Einschätzung, dass das kurzfristige "Abstechen" eines (verzeih) eher lächerlichen Logging-Prozesses keine Katastrophe auslösen wird, war wohl richtig.

Und darum ging es mir in erster Linie.

Dass ich dabei noch etwas systemspezifisches Wissen dazu gewonnen habe, sehe ich als erfreulichen Nebeneffekt, wofür ich mich (vorrangig) bei dir, Rastafari, bedanken möchte.

 

[raven]

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/

Und nun suche ich diese Verzeichnisse wieder einmal. seit dem 07.03. schreibt es mir nichts mehr in die Konsole. gesehen als ich was suchte weil einige Seiten nach Flash-Update nicht mehr zu öffnen sind.

Und somit danke an @Rastafari : Ohne Probleme die Inhate gelöscht und die Konsole funktioniert wieder wie sie soll.

 

[@dante12]

Die Konsoleneneinträge sind für Safari Irrelevant. Die Logs sind ein wichtiger Bestandteil um bestimmte Probleme zu finden und zu eliminieren. Das löschen dieser Logs behebt das Problem mit Safari nicht.

Hier geht es also nicht in erster Linie das du gerne die Logs gelöscht haben möchtest sondern warum Safari bei bestimmten Seiten abstürzt oder habe ich das jetzt falsch verstanden.

Und nun suche ich diese Verzeichnisse wieder einmal

Diese Verzeichnisse oder andere sind sehr leicht zu finden und mit wenigen Schritten auch über den Finder.

1. Klick mal auf die Finder-Oberfläche und drücke die Tasten Command + Shift + G dann erscheint ein kleines Fenster.
2. Kopiere diesen Inhalt hinein: /Library/Logs und drücke die Enter (Return) - Taste.

Das nachfolgende Verzeichnis erkennt Finder nicht:

$HOME/Library/Logs

Das liegt daran das der Finder die $PATH - Variable nicht korrekt interpretiert. Aber im Terminal funktioniert das gib mal im Terminal:

$HOME/

und drücke die TAB-Taste. Du siehst das sich die $HOME-Variable in /Users/<Benutzername>/ ändert.

Im Finder wird als Ersatz die Tilde (~) = Tasten ALT + n, verwendet. Wenn du also ~/Library/Logs in das kleine Finder-Fenster einsetzt öffnet sich das gewünscht Verzeichnis. Alles was mit der Tilde zu tun hat bezieht sich auf dein Home-Verzeichnis.

 

[raven]

@@dante12 Das problem das ich hier hatte, ist längst gelöst. Trotzdem danke dir für die Informationen. Um Safari ging es gar nicht.
Mittlerweile habe ich aber eine anderes Prob, was ausgalgert wurde. Es ist etwas ähnliches aber nicht das Selbe

http://www.apfeltalk.de/community/t...n-teilweise-falsch-veraltet-angezeigt.499863/

Das nachfolgende Verzeichnis erkennt Finder nicht:

Nein der Finder sieht die nicht , aber in der Konsole sind sie sichtbar und können dann auch per Kontex im Finder angezeigt und der Inhalt der jeweiligen entleert werden.

schaut dann so aus

 

[raven]

@@dante12
Kurz gefasst: Es ging nicht um Safari, sondern es wurde nichts mehr in das Logfile geschrieben. Das war 2013

Hier geht es also nicht in erster Linie das du gerne die Logs gelöscht haben möchtest sondern warum Safari bei bestimmten Seiten abstürzt oder habe ich das jetzt falsch verstanden.

Ja du hast es falsch verstanden.