proc (Fragen dazu)

L

logoft

Well-Known Member
Hallo,

ich lese ab und zu, mal hier mal da.
Ich habe etwas entdeckt. Da steht irgendwo das man proc in die fstab schreiben sollte, wenn man gnome benutzt. Ich habe gelesen proc ist kein echtes Filesystem. Kann mir einer kurz schreiben ob man etwas über proc wissen sollte? Ist das auch bei anderen Aufgaben proc 'zu mounten' ?? Muß man darüber etwas wissen?

mfg
 
Moin logoft,

die man-page zu procfs(5) ist sehr ausführlich. Alternativ findest Du auch online die gleiche ausführlich Beschreibung hierzu.

Grüßle

Jürgen
 
Es ist sicher gut, erst mal zu fragen. /proc ist kein echtes Dateisystem, wobei man nun diskutieren müsste, was denn ein echtes Dateisystem ist. fusefs oder tmpfs sind auch keine echten Dateisysteme und dennoch werden sie benutzt und zumindest tmpfs auch innerhalb der fstab behandelt.
proc ist aber wieder mit beiden nicht vergleichbar. Ich selbst würde einen /proc eher als ein Informationssystem bezeichnen, das mit einem eigenen Dateisystem eingebunden wird. So kann dieses System der alten Forderung entsprechend, dass in einem Unix alles eine Datei ist und es kann doch auch ein ganzer Hort von Informationen sein.
Die Frage ist nun sehr berechtigt, welche Programme auf Informationen im /proc zugreifen und wenn du nach der Installattion eines programmes keine entsprechende meldung erhältst, solltest du eigentlich davon ausgehen können, dass der /proc nicht gebraucht wird. Wie so oft bedeutet leider ein eigentlich gleichzeitig immer auch eigentlich nicht und tatsächlich gibt es wenige Programme, die offenbar die Meldung nicht bringen und trotzdem einen /proc erwarten. Weil ich selbst den Installationsmeldungen nicht pedantisch lausche, ergab sich daraus die Konsequenz, den /proc einzurichten. Das verschlingt keine Ressourcen und schadet nichts. Im schlimmsten Falle wird er einfach nicht gebraucht.

Ohne das genau zu wissen, würde ich denken, dass FreeBSD gar keine /proc braucht und daher Anwendungen für FreeBSD ebenfalls nicht auf einen /proc sehen sollten. Aber in Linux-Systmen ist das jedenfalls anders und manche Anwendungen werden ja Linux-lastig entwickelt und ich kann mir vorstellen, dass die Umsetzung für FreeBSD einfacher ist, wenn wir dazu auch einen /proc liefern.
Für den Linux-Kompatibillitätsmodus könnten wir auch einen eigenen linproc benutzen. Bei mir ist der ohne weiteren Kommentar auskommentiert, vielleicht machte er Probleme oder ist obsolet.

Es bleiben dir also die beiden Wege, es vollkommen ohne einen /proc zu probieren (was ich auch schon bei anderen Installationen gemacht habe) und erst dann zu reagieren, wenn du entsprechende Meldungen oder Fehler bekommst oder du richtest auf Verdacht mal einen /proc ein, der dann gegebenenfalls da ist, möglicherweise aber gar nicht gebraucht wird.

mount -p : darauf will ich bei der Gelegenheit hinweisen, weil ich diese Option unter dem Ubuntu-GNU/Linux vermisst hatte, als ich damit letztlich spielte. Das ist eine schöne Option, denn alle eingebundenen Systeme werden in einer fstab-kompatiblen Syntax aufgelistet. Nachdem du manuell herausgefunden hast, wie du etwas einbinden möchtest, brauchst du dir das nur mit diesem Befehl vorlegen zu lassen und findest sofort deinen Eintrag für die fstab.
 
Hallo Leute,

die Frage wäre noch ob mal proc lesen kann oder ob es binär gespeichet ist? Wenn das eine Art Schnell-find-Dateien sind könnte man damit lesen was man gemacht hat den ganzen Tag? Bei gnome steht man sollte proc in der fstab haben.

mfg
 
die verlinkte man-page sagt das schon ziemlich gut, finde ich. Da ist auch das Beispiel, wie ein /proc gemountet werden kann. mount -t procfs proc /proc und dazu wird /proc existieren müssen und das würde ich denn einfach mal testen.
/proc enthält auch lesbare Information, aber nicht oder eher weniger, was die Tätigkeit der Nutzer angeht als vielmehr zu Zuständen der HW.
/proc ist Standard in Linux. Du solltest da schon mal Bekanntschaft damit gemacht haben. Im Vergleich dazu ist der FreeBSD-proc aber klein und bescheiden.

Was wer vielleicht wann in deinem System gemacht hat, logged Syslog. Das kann unterschiedlich eingestellt werden. In FreeBSD müsste ich die Dienste dazu erst nachschlagen, in Ubuntu nannte sich der rsyslogd.
 
pit234a schrieb:
die verlinkte man-page sagt das schon ziemlich gut, finde ich. Da ist auch das Beispiel, wie ein /proc gemountet werden kann. mount -t procfs proc /proc und dazu wird /proc existieren müssen und das würde ich denn einfach mal testen.
/proc enthält auch lesbare Information, aber nicht oder eher weniger, was die Tätigkeit der Nutzer angeht als vielmehr zu Zuständen der HW.
/proc ist Standard in Linux. Du solltest da schon mal Bekanntschaft damit gemacht haben. Im Vergleich dazu ist der FreeBSD-proc aber klein und bescheiden.

Was wer vielleicht wann in deinem System gemacht hat, logged Syslog. Das kann unterschiedlich eingestellt werden. In FreeBSD müsste ich die Dienste dazu erst nachschlagen, in Ubuntu nannte sich der rsyslogd.
Zum Vergrößern anklicken....

Vieles kann man nachlesen, aber in der "Überschrift" steht oft nicht was man sucht :-) Ja die Zeile für fstab steht drin. Aber wie man den Unterschied merken soll bei gnome mit und ohne proc ist da schwierig. Läufts da schneller/besser/stabiler? Sowas steht auch in der manpage? Da ist es besser mal 5 Zeilen zu lesen. Oder neben den Manpages eine FAQ zu entwerfen - FAQ proc oder FAQ fstab oder oder :-))
Interessant ist zum Beispiel das man über dem 1. Prompt sieht das man sich die Deutsche doc downloaden kann, aber ich finde sie nicht. In dem doc Verzeichnis sind soviel Verzeichnisse das die mich eher verwirren statt das sie mir helfen.

Unter Linux steht oft proc in der fstab.
Die fstab ist aber mit Vorsicht zu nutzen. Ist da ein Fehler drin startet das System nicht mehr.Leider hat man es versäumt dort eine Test-Option reinzusetzen. DRDOS hatte damals ein ? Fragezeichen in der Config.sys und alles konnte man mit ja oder nein laden oder nicht laden.
Ich hatte mir mal Linux zerschossen weil was falsches in der rc.conf stand. Linux ist stabil, solange man nichts testet. Ich habe aktuell ein Problem mit der CPU mit BSD, er schreibt Fehler in eine Datei. Ich muß abbrechen und dann gehts mit Return weiter.

Linux ist nicht gut. Ich hoffe BSD ist da bei Fehlern wenigstens "mitdenkender" und verzeiht mehr Fehler um wenigstens booten zu können. Lesen kann man alles, ist nur die Frage ob man es auch verstanden hat. Zum Beispiel könnte man mit QEMU booten und hätte Ergebnisse. Programme haben so viel Paameter, aber ein 'simulate' fand ich noch nie.
Zum Beispiel bietet grub ein boot-Prompt. Aber den sollte man auch mal testen. Lesen kann man alles, aber nur in der Praxis merkt man wie sich etwas verhält. Manche meinen lies - aber das hilft nicht immer.

mfg
 
Moin logoft,

Vieles kann man nachlesen, aber in der "Überschrift" steht oft nicht was man sucht :-) Ja die Zeile für fstab steht drin. Aber wie man den Unterschied merken soll bei gnome mit und ohne proc ist da schwierig. Läufts da schneller/besser/stabiler? Sowas steht auch in der manpage? Da ist es besser mal 5 Zeilen zu lesen. Oder neben den Manpages eine FAQ zu entwerfen - FAQ proc oder FAQ fstab oder oder :-))
Zum Vergrößern anklicken....
Solche Dinge wird es in einer man-page nicht geben. Es stimmt, dass einige Programme das procfs benötigen, um eine bestimmte Funktionalität bereitzustellen. Das ist aber Aufgabe des Entwicklers, das zu beschrieben und nicht die Aufgabe des Autors der Manpage.

Unter Linux steht oft proc in der fstab.
Die fstab ist aber mit Vorsicht zu nutzen. Ist da ein Fehler drin startet das System nicht mehr.Leider hat man es versäumt dort eine Test-Option reinzusetzen. DRDOS hatte damals ein ? Fragezeichen in der Config.sys und alles konnte man mit ja oder nein laden oder nicht laden.
Ich hatte mir mal Linux zerschossen weil was falsches in der rc.conf stand. Linux ist stabil, solange man nichts testet. Ich habe aktuell ein Problem mit der CPU mit BSD, er schreibt Fehler in eine Datei. Ich muß abbrechen und dann gehts mit Return weiter.
Linux ist nicht gut. Ich hoffe BSD ist da bei Fehlern wenigstens "mitdenkender" und verzeiht mehr Fehler um wenigstens booten zu können.
Zum Vergrößern anklicken....
Das ist unter FreeBSD, Solaris usw. nicht anders und liegt auch auf der Hand, wenn mal etwas tiefer reflektierst.
Folgendes Beispiel:
Du hast folgenden Eintrag in der fstab:
/dev/da0p1 / ufs rw 1 1
Es wird das Root-Verzeichnis / gemountet. Wenn in dieser Zeile ein Schreibfehler vorliegt, woher sollen FreeBSD usw. wissen, dass / von /dev/da0p1 gemountet werden soll? Also bricht der Bootvorgang ab. Du darfst nicht vergessen, wenn das Slice/Partition nicht eingebunden werden kann, dann findet das Betriebssystem wichtige Tools nicht und funktioniert dann halt nicht. Daher ist ein Abbruch des Bootvorgangs sinnvoller als einfach weiterzumachen. Das gilt für jeden fehlerhaften Eintrag in der fstab.
Du darfst eines nicht vergessen: ein Computer macht nur das, was Du ihm als Regelwerk vorgibst. Ist das Regelwerk Mist, dann macht der Rechner auch Mist. Das Betriebssystem spielt dabei keine Rolle.

Lesen kann man alles, ist nur die Frage ob man es auch verstanden hat. Zum Beispiel könnte man mit QEMU booten und hätte Ergebnisse. Programme haben so viel Paameter, aber ein 'simulate' fand ich noch nie.
Zum Beispiel bietet grub ein boot-Prompt. Aber den sollte man auch mal testen. Lesen kann man alles, aber nur in der Praxis merkt man wie sich etwas verhält. Manche meinen lies - aber das hilft nicht immer.
Zum Vergrößern anklicken....

Nicht (sauber) dokumentierte Parameter bzw. Funktionen sind ein generelles Problem. Da hilft nur ein kurzes Mail an den Entwickler. Ist er freundlich, dann antwortet er ausführlich. Ist er es nicht, dann kommt die tolle Antwort, man solle sich doch bitte den Programmcode durchflöhen.

Ich habe aktuell ein Problem mit der CPU mit BSD, er schreibt Fehler in eine Datei. Ich muß abbrechen und dann gehts mit Return weiter.
Zum Vergrößern anklicken....
Was ist das für ein Fehler? Falls es nichts mit diesem Thema zu tun hat, dann bitte einen neuen Thread aufmachen.

Grüßle

Jürgen
 
Nein, FreeBSD (aber auch Linux) ist da leider nicht mitdenkender. Hast Du einen Schreibfehler in der rc.conf, dann wird der Bootvorgang auch abgebrochen und Du stehst dann da als Einsteiger und muß Dir mühsam heraussuchen, wie Du Partitionen zum Lesen und Schreiben einhängst. Hast Du keinen zweiten PC zum Googeln oder Recherchieren, dann stehst Du auf dem Schlauch ... Das Fehlermanagement unter Linux und FreeBSD ist verbesserungswürdig. Wenn bei Debian Jessie bei einer Nvidia Karte keine xorg.conf angelegt wurde nach der Installation, dann bleibt der Bildschirm schwarz. Es könnte in einem solchen Fällen ja auch einen Fallbackmodus geben. In jeder Hochsprache gibt es nicht umsonst Fehlerbehandlungsroutinen, warum eigentlich werden sie bei Betriebssystemen nicht angewandt? Und als Anwender interessiert mich zumindest anfangs nicht, wer die Verantwortung für solcherlei Unterlasssungen trägt. Laufen muß es, egal ob bei FreeBSD oder Linux. Wer bereits bei der Installation negative Erfahrungen macht, wird sich möglicherweise abwenden und sich seinem alten OS wieder zuwenden.
 
Es wäre kein Problem eine Pause einzusetzen oder ja oder nein zu booten. Das ärgert mich auch bei Windows. Warumgibts keine Registry für Windows und eine für alle Programme? Wenn ich 20'000 Registry Einträge habe und ein Eintrag ist falsch, dann läuft der ganze Rechner nicht?? Völlig daneben.

Ein Betiebsystem sollte 1 GigaByte groß sein und den Rest könnte man auslagern. Die Rechner mit M.2 Schnittstelle sind maximal 512 GB groß. Es gibt schon 4 und 6 TerraByte Platten. Für mich wäre eine eigene Ordnung der Verzeichnisse besser.

Damals hatte Apple RISC Prozessoren. Das waren damals schnelle CPUs. Die Parallela CPU ist auch RISC.

Die Hadware hat sich verändert, aber nutzt das was? Ich teste lieber 5 Stunden als mir das Betriebsystem zu zerstören. Bei Windows gibts eine Sandbox. Ich will dann malgucken ob es das auch bei BSD gibt. Und ob es ein Backup gibt. Bei Windows gabs eine das Ghost heißt. Ich hatte es nur gehört, nicht getestet. Interessant ist das man Laufwerke mounten kann. Was unter Windows nicht so geht. Ich bin gespannt ob BSD Errorlevel kennt. Mit Errolevel könnte man Rückmeldungen der Programme verwenden.

mfg
 
hallo logoft,

Es wäre kein Problem eine Pause einzusetzen oder ja oder nein zu booten.
Zum Vergrößern anklicken....
Ich gebe jetzt mal eine im OpenSource-Bereich gerne verwendete Antwort: Es steht Dir frei, so etwas zu implementieren:D

Aber ernsthaft. Du hast bei FreeBSD die Möglichkeit in den sogenannten single user mode zu booten. Dort gibt es eine einfache Shell (sh). Es ist nur / gemountet und den Rest musst/kannst Du manuell erledigen. Im single user mode hast Du alle Möglichkeiten einen kaputten Bootvorgang zu analysieren. Es gibt halt keine grafische Benutzeroberfläche, sondern nur die klassische Console.

Aber: Mache Dich zunächst mit FreeBSD richtig vertraut, lies Dir das deutsche Handbuch durch oder besorge Dir ein gutes Buch aus klassischem bedruckten Papier. Es gibt gute Bücher auch in deutscher Sprache.

Zum Thema Backup: tar oder dump/restore sind mit an Board und Deine Freunde :D

Grüßle

Jürgen
 
Was bedeutet Fehlertoleranz?
Wenn ein Betriebssystem NICHT das macht, was ich von ihm will? Wenn ich etwas unsinniges oder falsches von ihm verlange und es genau diesen Unsinn macht, arbeitet es absolut korrekt. Es tut zwar unter Umständen nicht, was ich mir vorgestellt hatte, aber hier liegt das Problem eindeutig bei meiner Phantasie.
Den Umgang mit einem Betriebssystem zu erlernen bedeutet letztlich die eigene Phantasie mit der Realität abzugleichen und das ist ein langwieriger und teilweise schmerzhafter Prozess. Es heißt nicht umsonst, dass noch kein Meister vom Himmel gefallen ist und ich stimme darin absolut überein, dass Lesen alleine nicht genügt. Aber ohne jedes Lesen hat man sehr viel geringere Chancen und die Hinweise auf Handbuch und man-pages liegen darin begründet, dass kaum jemand von uns die Grundlagen besser und deutlicher beschreiben kann und weiterhin, dass wir eine gemeinsame Grundlage für das weitere Vorgehen brauchen. Man muss sich sprachlich innerhalb eines Threads annähern und das bedeutet, Vokabeln und Ausdrücke synchronisieren und dazu bilden besagte Quellen die Master-Referenz. Mehr nicht, aber auch nicht weniger.

Wie schon gesagt: wenn eine SW dir als Installationsmeldung erklärt, dass sie einen /proc benötigt, dann gibt es zunächst keinen Grund, daran zu zweifeln und dann ist es falsch, die Umsetzung in der fstab zu fürchten. Vor allem, weil man sich davor fürchtet, diese fstab unbrauchbar zu hinterlassen. Die fstab ist eine sehr einfache und klar strukturierte Konfigurationsdatei und sehr einfach zu verstehen. Wenn irgendwelche Gurus aus dem Web dir erklären, dass man da einen /proc braucht ohne dies weiter zu erklären, dann ist das eine andere Sache. Dann würde ich es zunächst ohne probieren. Der Unterschied kann kein schneller oder langsamer sein, der Unterschied muss in hängenden oder kollabierenden Anwendungen auszumachen sein.
Um eine anschaulichere Vorstellung unseres /proc zu liefern, mal ein beliebiges Beispiel:
Code: 
o-box@senyo ~:-> ls /proc
0	1055	11	1512	17024	2037	2064	2111	2137	2160	2400	26731	3593	5	8	947
1	1064	12	1539	18	2059	2065	2123	2140	2163	2418	26732	3596	6	857	curproc
10	1079	13	1541	189	2060	2066	2129	2141	2181	2419	26733	3741	619	892
1007	1086	14	16	19	2061	2067	2134	2143	2187	2420	26741	3742	636	895
1027	1089	15	17	2	2062	2071	2135	2144	22148	2422	3	3743	643	9
1045	1093	1511	17022	20	2063	2074	2136	2158	2216	2423	3354	4	7	909
 o-box@senyo ~:-> ls /proc/2065
cmdline	ctl	etype	file	map	rlimit	status
o-box@senyo ~:-> cat /proc/2065/status
getty 2065 1 2065 2065 ttyv6 ctty,sldr 1455742781,995517 0,0 0,2156 ttyin 0 0 0,0 -
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben