NextBSD, kann das mal ein Guru (Yamagi o.ä) erklären ?

peterle schrieb:
Ich finde eine Meldung, warum er gestorben ist, deutlich hilfreicher, als wenn der arme Kerl, angeschossen und verblutend noch mehr Unheil anrichtet, als er es eh schon getan hat.
Zum Vergrößern anklicken....
Ihr tut so als ob das oft und dann vielleicht auch noch ununterbrochen der Fall wäre. Keine Software is wirklich Fehlerfrei und unter bestimmten Umständen, die evtl. sehr selten auftreten, kann sie eben mal abstürzen was kein Drama sein muss (aber durchaus auch sein kann). Und die Restart-Strategie kann man doch sicherlich konfigurieren. Dass es da einen Log-Eintrag gibt, evtl. auch eine mail an den Admin, versteht sich doch wohl, - es sei denn man hat es wirklich mit Bananen-Software zu tun und die sollte man eben tunlichst meiden.:)
 
Die Frage ist doch, was der abtsürzende Dienst mit den Daten macht und wie fehlertolerant das ganze aufgebaut ist.
Wenn er sich selber wieder verlustfrei zusammenflicken kann, dann ist das eine Sache, wenn er mir aber einen Fehler unbemerkt in der DB hinterläßt und der Rest darauf aufbaut, kann das drei Jahre, vier Monate, 20 Tage, 7 Stunden und 43 Minuten später recht katastrophale Auswirkungen haben.

Ich bin da aber aus Prinzip schon eigensinnig und denke mir, daß aus unbekanntem Grunde abstürzende Systeme mit großer Vorsicht zu genießen sind und letztendlich nerven die mich einfach nur.
 
Nicht jeder Dienst verwaltet "in sich" Daten. Webserver, Proxies, Multimedia Streaming/Routing etc. pp.

Und wer seinen Server nicht regelmäßig mal checkt, der hat sowieso ganz andere Probleme als Dienste die sich selbst wiederherstellen.

Oder lässt du deine Server auch ohne RAID laufen, weil ein Plattendefekt sofort sichtbar sein sollte? :D
 
Ich zum Beispiel hätte auch relativ wenig Lust im Urlaub angeklingelt zu werden, nur weil wegen ungünstiger Konstellation von Mars und Jupiter der Samba-Server ausgestiegen ist.
 
peterle schrieb:
Die Frage ist doch, was der abtsürzende Dienst mit den Daten macht und wie fehlertolerant das ganze aufgebaut ist.
Wenn er sich selber wieder verlustfrei zusammenflicken kann, dann ist das eine Sache, wenn er mir aber einen Fehler unbemerkt in der DB hinterläßt und der Rest darauf aufbaut, kann das drei Jahre, vier Monate, 20 Tage, 7 Stunden und 43 Minuten später recht katastrophale Auswirkungen haben.
Zum Vergrößern anklicken....
Nachts um drei quengelt der Kunde, weil der Service down ist. Du machst dann erstmal eine umfassende Datenanalyse (fachlich?) - das dann nochmal nach dem "och, auch erstmal wieder neu starten" - usw.?

Man kann sich da immer was konstruieren, warum auto-restart schlecht sein kann -- aber in 99% der Faelle ist es das nicht.
Um eine post-mortem (quasi) Analyse sollte man sich natuerlich trotzdem kuemmern.
 
Zumindest ich wollte nie sagen, dass Serviceüberwachung sinnlos oder schädlich ist. Im Gegenteil. Ich bin zum Beispiel sehr froh, dass ich kein Script mehr brauche, um meinen Spamassassin minütlich zu pollen. Einfach Deamon Tools (http://www.freshports.org/sysutils/daemontools/) außen rum und gut ist. Allerdings muss man im Einzelfall abwägen. Wie gesagt ist es meiner Erfahrung nach keine gute Idee MySQL blind neuzustarten, spätestens wenn er im Recovery abschmiert sollte es abgeschaltet bleiben und der Admin geweckt werden.

Davon einmal abgesehen, bieten DragonflyBSD und FreeBSD inzwischen die Voraussetzungen eine saubere Serviceüberwachung zu implementieren: Man kann per procctl() das Attribut PROC_REAP_ACQUIRE setzen und wird dadurch zum "Reaper" aller Kindprozesse seiner Forks. Verwaiste Kindprozesse werden damit dem jeweiligen Prozess und nicht mehr init zugewiesen, man kann also herausfinden, welche indirekten Kinder nach dem Tod der direkten Forks noch laufen und darauf entsprechend reagieren.
 
Yamagi schrieb:
Davon einmal abgesehen, bieten DragonflyBSD und FreeBSD inzwischen die Voraussetzungen eine saubere Serviceüberwachung zu implementieren: Man kann per procctl() das Attribut PROC_REAP_ACQUIRE setzen und wird dadurch zum "Reaper" aller Kindprozesse seiner Forks. Verwaiste Kindprozesse werden damit dem jeweiligen Prozess und nicht mehr init zugewiesen, man kann also herausfinden, welche indirekten Kinder nach dem Tod der direkten Forks noch laufen und darauf entsprechend reagieren.
Zum Vergrößern anklicken....
Damit wäre ja der zentrale Hack in systemd überflüssig! Das man Probleme einfach so ordentlich lösen könnte! Nicht zu fassen!
 
Yamagi schrieb:
Davon einmal abgesehen, bieten DragonflyBSD und FreeBSD inzwischen die Voraussetzungen eine saubere Serviceüberwachung zu implementieren: Man kann per procctl() das Attribut PROC_REAP_ACQUIRE setzen und wird dadurch zum "Reaper" aller Kindprozesse seiner Forks. Verwaiste Kindprozesse werden damit dem jeweiligen Prozess und nicht mehr init zugewiesen, man kann also herausfinden, welche indirekten Kinder nach dem Tod der direkten Forks noch laufen und darauf entsprechend reagieren.
Zum Vergrößern anklicken....
Geht das auch mit der Shell? Also daß die Shell, in deren Kommandozeile ich z. B. den Firefox starte, zur Mutter seiner Kindprozesse wird? Oder müßte man eine Shell dafür patchen?
Kamikaze schrieb:
Damit wäre ja der zentrale Hack in systemd überflüssig! Das man Probleme einfach so ordentlich lösen könnte! Nicht zu fassen!
Zum Vergrößern anklicken....
Was ist denn der "zentrale Hack"?

Gruß,
Tronar
 
Tronar schrieb:
Geht das auch mit der Shell? Also daß die Shell, in deren Kommandozeile ich z. B. den Firefox starte, zur Mutter seiner Kindprozesse wird? Oder müßte man eine Shell dafür patchen?
Zum Vergrößern anklicken....
Da es ja erstmal nur ein durch C erreichbares Kernelinterface ist, brauchst du einen Userland-Wrapper. Also die Shell patchen, ein weiteres Tool schreiben oder so.
 
Tronar schrieb:
Geht das auch mit der Shell? Also daß die Shell, in deren Kommandozeile ich z. B. den Firefox starte, zur Mutter seiner Kindprozesse wird? Oder müßte man eine Shell dafür patchen?Was ist denn der "zentrale Hack"?
Zum Vergrößern anklicken....
Das systemd als init-Prozess läuft um verwaiste Prozesse einsammeln zu können.
 
Da gefragt wurde, ich befinde mich in der recht luxuriösen Situation nicht von der Administration leben zu müssen und mein bester Kunde dabei zu sein und die paar anderen kann ich mir aussuchen, auch wenn ein paar sehr sensible Unternehmen dabei sind. So habe ich natürlich den Vorteil auch einfach Nein zu sagen, wo andere die Zähne zusammenbeißen müssen.

Ich habe erfreulicherweise auch nie ernste Probleme mit mysteriöser Weise abstürzenden Diensten gehabt. In der Regel lag das an Fehlern in der Konfiguration und Auslegung - sprich der Speicher lief in gewissen Situationen voll und der Dienst reagierte nicht mehr.
Dann gab es Fälle in denen ich irgendwelches modernere Zeug getestet habe, welches zwar hoch gelobt, aber bescheiden "programmiert" - besser gesagt wäre wohl "zusammengefuckelt" - wurde und es daruch zu Abstürzen kam. Ich gebe zu, ich meide das Zeug dann einfach und empfehle Papier, Bleistifte, Telefon. Klassische verlässlich und stürzt nicht ab.
Eine Erfahrung habe ich mal mit einer WAWI gemacht, die dann und wann mal abrauchte - gute Windowsprofisoftware - und irgendwann hat mal einer nicht aufgepasst. Der Fehler wurde dann Monate später offensichtlich und die Arbeit von Monaten war für die Katz, die proprietäre Datenbank nämlich kaputt und nicht mehr update- oder konvertierbar. Das waren tausende Euros in den Orkus geschossen und nur weil einer mal eben das Ding einfach neu startete und sagte - Geht doch!
Glücklicherweise war das alles nichts, was irgendwelche Rechtsfolgen gehabt hätte.

Insofern, ja, wenn mitten in der Nacht aus ungeklärtem Grund ein Dienst abraucht, mache ich eine umgehende Sicherung des Systems und schaue mir das Problem erst einmal an und versuche den Grund zu finden, diesen zu beheben, die Daten zu checken und dann geht es wieder online.
Viele würden für sowas geschlachtet, aber ich bin wie gesagt da störrisch und kann mir den Luxus leisten.
 
-Nuke- schrieb:
Oder lässt du deine Server auch ohne RAID laufen, weil ein Plattendefekt sofort sichtbar sein sollte? :D
Zum Vergrößern anklicken....

ZFS macht genau das, was es soll:
  • es meldet einen Fehler
  • es versucht zu retten, was zu retten ist
  • es erstattet Bericht über das Ergebnis
  • es schließt den defekten Teil des Systems von weiteren Aktivitäten aus
Das macht aber sonst nichts in der ganzen Diskussion über das Neustarten von Diensten so - oder ich habe etwas Entscheidendes Miß- oder Nichtverstanden.
 
Nö. ZFS korrigiert gefundene Fehler einfach vor sich hin und kümmert sich sonst nicht weiter (also wenn es reparierbar ist). Klar, kannst du mittels zpool status nachgucken was er gemacht hat, aber _direkt_ melden tut er das nun auch nicht.

Wenn jetzt aber z.B. dein RAM kaputt ist, kann es auch sein, dass ZFS durch seine Auto-Korrektur die Daten zerlegt genau weil er ständig sofort repariert. Darum sollte man ja auch ZFS nicht unbedingt ohne ECC-RAM benutzen.

Lustigerweise hatte ich den Fall sogar schon.
 
Also meine Server senden mir freundlicherweise einen täglichen Report und dort findet sich auch der zpool status. Unabhängig davon meckert smartd rum, wenn eine Platte Probleme macht.

Du hast also mit dem "direkt" melden recht, das macht nur smartd.

Ein kleiner Blick dazu bringt mir z.B. das hier:
https://calomel.org/zfs_health_check_script.html

Daraus kann man sich dann auch noch was basteln, wenn man das will.

Und hier noch zur Info:
https://forums.freebsd.org/threads/how-can-i-make-zfs-notify-me-when-a-disk-fails.35756/
 
-Nuke- schrieb:
Klar, kannst du mittels zpool status nachgucken was er gemacht hat, aber _direkt_ melden tut er das nun auch nicht.
Zum Vergrößern anklicken....
peterle schrieb:
Du hast also mit dem "direkt" melden recht, das macht nur smartd.
Zum Vergrößern anklicken....
ZFS nicht direkt aber mit einem kleinen Umweg über devd ist das kein Problem. Habe dies bei mir so eingebaut:

/usr/local/etc/devd/devd.conf
Code: 
#
#ZPOOL DEVICE REMOVED
#
notify 10 {
  match "system"  "ZFS";
  match "type"  "resource.fs.zfs.removed";
  action "logger -p local0.crit 'ZPOOL: POOL DEGRADED!'";
  action "printf 'Service: ZPOOL\n  State: POOL DEGRADED!' | mail -s '** PROBLEM alert ** - from '$(hostname)' ZPOOL: POOL DEGRADED!' <MAIL>";
};
Anstelle der Mail, kann man natürlich irgend ein Kommando/Aktion eintragen. FreeBSD ist ein geniales System. Man muss nur wissen, wo man die Sachen findet :)

Gruss
 
nosh ist schon seit einigen Monaten immer mal wieder Thema auf den Maillinglisten. Es wäre sicher eine der denkbaren Alternativen zu rc, gerade da der Entwickler explizit FreeBSD als eine Zielplattform unterstützt. Eine weitere interessante Alternative ist s6 (http://skarnet.org/software/s6/index.html), dort scheint man sich aber eher auf Linux zu konzentrieren. Muss man mal schauen.

Nachtrag: Man könnte es natürlich mit dem "Package Base" Projekt kombinieren, was das Basisstem (optional) in spezielle Pakete zerlegen möchte. Dann könnte man sich das System zum Dienststart installieren, was man möchte. Sie müssten nur ausreichend kompatibel sein.
 
Die aktuellen s6 und s6-rc Version bauen ohne Patches auf FreeBSD und sind soweit ich es bisher getestet habe voll funktionsfähig. Allerdings nutzt s6-supervise keine der OS spezifischen APIs um Reaper für seine Kinder zu werden falls die sich danebenbenehmen.
 
Leider kam das bei Pro Linux [1] auch so rüber, als ob FreeBSD offiziell an nosh arbeiten.
Allerdings arbeitet da wohl nur ein einzelner Nicht-Entwickler dran, der den aktuellen Status in regelmäßigen Abständen auf den Mailing Listen bekannt gibt.
Bisher gab es dazu immer sehr wenig Resonanz, weswegen ich nicht glaube, dass das Projekt eine Chance bekommen wird.
Schade, vielleicht wäre es sogar ganz gut, da es parallelsiert startet und man die vorhandenen rc-Skripte nicht anpassen muss.

[1] http://www.pro-linux.de/news/1/22898/freebsd-entwickelt-systemd-alternative.html
 
Nosh hat einen sehr relevanten Vorteile für Maintainer: Es gibt sich weitgehend kompatibel zu bestehenden Systemen z.B. kann es die meisten systemd unit files in ein Service Directory konvertieren. Was mich stört ist, dass nosh in C++ geschrieben ist. In FreeBSD müssen deswegen einige nosh Binaries statisch gelinkt werden, weil die C++ Runtime nicht zwangläufig im Rootdateisystem liegt. Ob man jetzt lieber C++ oder C für so ein Projekt verwenden will ist eine Geschmacksfrage und ich würde den Flameware dazu gerne vermeiden. Was ich vermisse ist eine Dokumentation der Readiness API bzw. eine Aussage drüber ob es überhaupt eine gibt. Falls es keine gibt kann man das mit relativ geringem Aufwand implementieren.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben