Häufige Erstellung von Core Dateien sind nervend, wie abstellen?

R

ralli

Guest
Ich bin mit der neuen OpenBSD Version 6.3 rundherum zufrieden. Allerdings nervt mich doch, das hauptsächlich Thunar öfters und smtube nach Beendigung immer wieder Core Dump Dateien erzeugen. Ansonsten laufen die Progs einwandfrei. Kann ich das irgendwie unterbinden?
 
Schau mal in deine Limits/login.conf. Dort gibt es ein Limit (rlimit_core/coredumpsize), damit legst du die maximale Größe eines corefiles fest. Beim Wert 0 sollte keins erstellt werden.

Rob
 
Schau mal in deine Limits/login.conf. Dort gibt es ein Limit (rlimit_core/coredumpsize), damit legst du die maximale Größe eines corefiles fest. Beim Wert 0 sollte keins erstellt werden.
Hallo Rob,

leider findet sich in meiner /etc/login.conf keine Klasse Limits und deshalb auch kein EIntrag (rlimit_core/coredumpsize). Kannst Du mir bitt genau posten, was ich eintragen muß, wenn die Klasse nicht vorhanden ist? Danke!
 
Hmm,

also, du hattest doch schon mal die /etc/login.conf geändert, nicht wahr?
Also passe einfach die Loginklasse, die du nutzt, entsprechend an und setze das Limit coredumpsize auf 0.

Z.B.:

Code:
staff:\
    :coredumpsize=0:\
    :datasize-cur=512M:\
    :datasize-max=infinity:\
    :maxproc-max=512:\
    ... \
    :tc=default:

Denk dran, dass du dich einmal abmelden und neu anmelden musst, damit die Änderungen überhaupt greifen.

Rob
 
also, du hattest doch schon mal die /etc/login.conf geändert, nicht wahr?
Also passe einfach die Loginklasse, die du nutzt, entsprechend an und setze das Limit coredumpsize auf 0.
Danke hat funktioniert. :) Das entspricht wohl bei FreeBSD kern.coredump=0 in der sysctl.conf. Habe gegogelt und habe auch in der Manpage nichts brauchbares gefunden.
 
So kleiner Nachtrag, es funktioniert nicht mit der Einstellung

Code:
:coredumpsize=0:\

Guckst Du hier:

thunar.png
 
So kleiner Nachtrag, es funktioniert nicht mit der Einstellung

Code:
:coredumpsize=0:\
Guckst Du hier:
Hehe, aus der Konsole posten mit
Code:
ls -lisah
jetzt steht die Frage im Raum wie alt (und groß) die Dinger sind :). Haben die Dinger Inhalt oder sinds leere Dateien?

EDIT:
Hast du sichergestellt, dass du auch in der richtigen Gruppe bist?
 
Hatte die alten bereits gelöscht, habe es aber mal provoziert:

Code:
7249685 130496 -rw-------   1 ralph  ralph  63.7M Apr  6 09:42 smtube.core

Nix mit 0 Byte.

Eingetragen hatte ich es in die Gruppe staff, war das nicht richtig?

Code:
staff:\
        :coredumpsize=0:\
        :datasize-cur=infinity:\
        :datasize-max=infinity:\
        :datasize=infinity:\
        :openfiles-cur=1024:\
        :stacksize-cur=16M:\
        :maxproc-max=512:\
        :maxproc-cur=512:\
        :ignorenologin:\
        :requirehome@:\
        :tc=default:
 
Ganz frisch:

Code:
7249724  24160 -rw-------   1 ralph  ralph  11.8M Apr  6 09:43 thunar.core
 
Nicht uninteressant wäre natürlich die Frage, wieso da anscheinend laufend Programme crashen...
Ja, das würde mich auch interessieren, denn wenn ich die Ursache nicht wirklich kenne, kann ich es auch nicht abstellen, wenn überhaupt. Also die Hauptübeltäter kann man wohl zusammen fassen :

Smtube (mit Qt 5.9.4 compiliert)

Thunar 1.6.14

seltener aber auch

xfsettingsd

xfdesktop

Ob XFCE 4.12 auch mit Qt gebaut wurde, entzieht sich meinen Kenntnissen.

Hab mal Nautilus für Thunar probeweise installiert, da gibt es diese Probleme nicht. Aber das zieht natürlich wieder denhalben Gnome Desktop nach sich.

Vielleicht liegt es auch am Intel GraKa Treiber, aber das ist spekulativ.
 
Sofern ralph die laufenden Prozesse nach dem Start gehören und ralph in der Gruppe staff ist, ja

Falls jedoch alle 3 als root ausgeführt weden, ist der Eintrag unter staff wertlos!
Ich lege nach der Grundinstallation immer mit adduser den User ralph an, den ich auch den Gruppen wheel und staff hinzufüge. Und natürlich logge ich mich für die normale Arbeit immer als user ralph an und nie als root.
 
Und natürlich logge ich mich für die normale Arbeit immer als user ralph an und nie als root.
Hm, kann mir fast nicht vorstellen, dass das bei den Tools der Fall ist, aber schonmal unter
Code:
# top
nachgesehen, ob diese auch wirklich während der Laufzeit ralph gehören (Privsep ist aber wohl eher unwahrscheinlich)?

Notfalls einfach mal ein
Code:
cat smtube.core
posten... *Scherz* :ugly:
 
den ich auch den Gruppen wheel und staff hinzufüge.

Ich schreibe das jetzt schon zum gefühlt dritten Mal: Hier werden wieder Loginklassen mit Gruppen verwechselt. Du musst deine Loginklasse entsprechend setzen, in welcher Gruppe du bist, spielt für die Einstellungen in der login.conf keine Rolle.

Rob
 
Ich schreibe das jetzt schon zum gefühlt dritten Mal: Hier werden wieder Loginklassen mit Gruppen verwechselt. Du musst deine Loginklasse entsprechend setzen, in welcher Gruppe du bist, spielt für die Einstellungen in der login.conf keine Rolle.
Hehe, ups, richtig gedacht und falsch geschrieben

@ralli
Code:
# userinfo ralph

Code:
userinfo sinus
login  sinus
passwd  *
uid  1000
groups  sinus wheel
change  NEVER
class  staff
gecos  sinus
dir  /home/sinus
shell  /bin/ksh
expire  NEVER
Was steht bei dir unter class?^^
 
Ich schreibe das jetzt schon zum gefühlt dritten Mal: Hier werden wieder Loginklassen mit Gruppen verwechselt. Du musst deine Loginklasse entsprechend setzen, in welcher Gruppe du bist, spielt für die Einstellungen in der login.conf keine Rolle.
Und ich respektiere Deine Hilfsbereitschaft, aber wenn Du bei uns in der Qualitätsplanung gearbeitet hättest, wärest Du keine Woche alt geworden...

Unser Leitspruch war:

Der Kunde will keine Erklärung des Problems, sondern die Lösung.

Nun bin ich weder Dein noch irgenwem anders Kunde. Dennoch solltest Du verstehen, das hier ein grundlegendes Verständnisproblem meinerseits vorliegt, und mir wirklich geholfen wäre, wenn Du nicht allein erklärst, was falsch ist, sondern was ich tun muß, um es richtig zu machen. Ein Beispiel reicht, ich bin nicht von Dummsdorf und lerne sehr schnell. Aber rätseln kann ich nicht und bin an dieser Stelle immer noch auf das Fachwissen von Profis angewiesen.

Danke!
 
Mit doas oder als root:
Code:
# usermod -L staff ralph
+ ausloggen.
Das hat offensichtlich die Lösung gebracht.:) Wenn Du mir bitte noch erkären würdest, was nun mit der Befehlsfolge passiert ist, wäre ich sehr dankbar. Im übrigen habe ich in der /etc/sysctl.conf den Wert erhöht:
Code:
kern.shminfo.shmall=536870912

Und die Werte in der Gruppe staff auch erhöht:

Code:
staff:\
        :coredumpsize=0:\
        :datasize-cur=infinity:\
        :datasize-max=infinity:\
        :datasize=infinity:\
        :openfiles-cur=2148:\
        :stacksize-cur=32M:\
        :maxproc-max=1024:\
        :maxproc-cur=1024:\
        :ignorenologin:\
        :requirehome@:\
        :tc=default:

Auf jeden Fall scheint jetzt Ruhe zu sein, ich werde das weiter beobachten. Smtube wirft schon mal keine Core Datei mehr, und Thunar bis jetzt auch nicht mehr.
 
Hab jetzt mal die Manpages von usermod zu Rate gezogen:

Code:
This option sets the login class for the user being created.  See
             login.conf(5) for more information on user login classes.  This
             value can be preset for all users by using the class field in the
             /etc/usermgmt.conf file.  See usermgmt.conf(5) for more details.

Also, diese Option legt die Anmeldeklasse für den Benutzer fest, der gerade erstellt wird. Langsam verstehe ich ....
 
So das Problem ist nicht nur tatsächlich gelöst, sondern mein OpenBSD 6.3 mit den notwendigen Anpassungen spürbar performanter geworden. Ich danke allen, die so viel Geduld mit mir aufbrachten und mich unterstützten. Habe wieder unendlich viel hinzu gelernt. Werde wohl in den nächsten Tagen mal etwas mehr Zeit aufwenden und die Manpages durcharbeiten. Es gibt ja immer wieder Neues zu entdecken. Ehrlich gesagt, dachte ich immer, Thunar oder Smtube wären nicht so sauber programmiert, aber das war wohl falsch gedacht, denn jetzt läuft es ja einwandfrei.
 
"Keine Coredatei" und "läuft einwandfrei" ist nach dem Abschalten von Coredateien eine Gleichsetzung, mit der ich persönlich sanfter umgehen würde.
 
Ich würde auch nach der Ursache für die Coredumps suchen anstatt sie einfach abzuschalten und mir damit "vorzugaukeln", dass alles gut wäre. Bei Thunar erinnere ich mich an einen Bug - wohl betriebssystemübergreifend - der Thunar zum Absturz brachte, wenn man zB Dateien umbenennt. Ich habe jetzt aber nicht geprüft, welche Version von Thunar in OpenBSD 6.3 ist.

Edit: Wobei ich jetzt nicht weiß, ob du das mit der Deaktivierung der Coredumps rückgängig gemacht hast und dennoch Ruhe ist.
 
Zurück
Oben