Server crash ... mittlerweile jeden Tag

Question

Hi,

nachdem sich ja weitere Praxen vornehmen den tomedo-Server zu virtualisieren möchte ich darauf hinweisen, dass der Server in einer virtualisierten Umgebung nicht stabil läuft!

Die crashlogs sind allesamt so: oder so ähnlich

2018-10-26 05:32:55.386 ServerToolsHelper.m:1519[lvl=1] Datenbankverbindung an 127.0.0.1:5432/tomedo_live konnte nicht hergestellt werden
2018-10-26 05:32:55.386 ServerToolsHelper.m:1521[lvl=1] Datenbankverbindung an 127.0.0.1:5432/tomedo_live konnte nicht geschlossen werden
2018-10-26 05:32:55.386 ServerToolsMainWindowController.m:995[lvl=1] Datenbankverbindung konnte nicht hergestellt werden. Fehler: (null)
2018-10-26 05:32:55.388 ServerToolsHelper.m:1529[lvl=1] starte tomcat neu.
2018-10-26 05:32:55.388 ServerToolsStatus.m:249[lvl=1] ServerStatus: 3 (stoppt)
2018-10-26 05:32:56.549 ServerToolsStatus.m:674[lvl=1]
2018-10-26 05:33:02.195 ServerToolsStatus.m:219[lvl=1] ServerStatus: 0 (gestoppt)
2018-10-26 05:33:02.203 ServerToolsStatus.m:229[lvl=1] ServerStatus: 1 (startet)
2018-10-26 05:33:03.003 ServerToolsStatus.m:219[lvl=1] ServerStatus: 0 (gestoppt)
2018-10-26 05:33:03.003 ServerToolsHelper.m:1533[lvl=1] tomcat server konnte nicht neugestartet werden. Fehler: Pipe konnte nicht erstellt werden.

Während des Betriebs kann ich keine Probleme feststellen. Der Server tut was er soll. Erst wenn es nachts darum geht Autobackups zu machen, dann kriegt der Server Schluckauf!

Klar kann man es auf die VM schieben. Wenn die ganze Welt aber mittlerweile stabil virtualisiert wäre ich mir nicht so sicher ob es sich nicht doch um ein natives tomedo-Problem handelt.

Ich darf mittlerweile jeden Morgen den Server von Hand wieder starten... dann läuft er prima...bis zum nächsten Autobackup...

 

P.S. die Servertools crashen auch regelmäßig. Das scheint aber ein anderes Thema zu sein und hat die Ticketnummer TOM-6973.

P.P.S. darf man Java denn jetzt updaten? Und auf welche Version? Der Installer möchte gerne Java 8 Update 191 build 12 drüberziehen...

VG

JM

Comments

Mag es bei großen Unternehmen oder Stukturen kostensparend sein, den Server zu virtualisieren, so müsste mir jemand den wirklichen Vorteil in einer Praxis mit ein paar Ärzten erst einmal erklären. Wir haben einen Mac mini Server im Keller stehen, der läuft und läuft und wir haben derartige Probleme nie gesehen. Würden Server und Raid-System geklaut oder sonstwie unbrauchbar, könnten wir das über das entfernte Backup Alles über VPN wiederherstellen, und zwar ohne irgendeinen EDV-Techniker. Damit sind wir mehr als zufrieden. Das möchte ich bei einer VM erst einmal sehen...

Mfg, Eghart Bredow

---

Ich empfehle Ihnen sich etwas mit der Virtualisierungstechnik ausseinander zu setzen.

Bei vmware sollten Sie sich mal und vMotion, veeam Backup anschauen. Alles was Apple im Businesssegement zu bieten hat ist in den 90ern festgefroren....

Um zu virtualisieren braucht man keinen EDV-Techniker... und alles geht deutlich leichter und schneller als das Apple-gefrickel.

Answer 1

Leider haben alle von Ihnen gesendeten Absturzberichte das selbe Muster: Der Absturz wird durch einen Speicherzugriffsfehler tief in einer Apple-Systembibliothek ausgelöst, die für den Netzwerkzugriff bzw. damit zusammenhängende Aufrufe verantwortlich ist ("com.apple.network.connections"). Die Servertools machen in dem Augenblick eigentlich nichts anderes, als diese Bibliothek aufzurufen, z.B. um im Internet nach Updates zu suchen, oder um zu prüfen, ob die Datenbank erreichbar ist, oder eben auf die Datenbank zuzugreifen (z.B. im Zuges eines Backups). Es gibt dafür somit auch nicht wirklich eine Lösung, denn diese Systembibliothek ist für die genannten Zugriffe notwendig. Man könnte höchstens gar nicht mehr aufs Netzwerk oder die Datenbank zuzugreifen (was natürlich schade für alle Anwender wäre, wenn der Server nicht mehr anzeigen kann, dass es Updates gibt bzw. gar kein Backup mehr macht).

Es ist hierbei leider ganz stark davon auszugehen, dass das Ursprungsproblem was die Systembiblilothek zum Absturz bringt in der (virtualisierten) Netzwerkschnittstelle liegt - insbesondere da uns bislang keine anderen Praxen bekannt sind, die das Problem haben. Auch die oben genannten "Schluckauf-Aussetzer" deuten auf genau das hin. Außer regelmäßig die Systemberichte an Apple zu schicken und zu hoffen, dass der Fehler irgendwann behoben wird, fällt mir hier leider auch nicht wirklich eine Lösung ein. 

Das Grundproblem hierbei ist aber, dass Apple wenig bis gar kein Interesse hat, die Virtualisierung seines Betriebssystems zu unterstützen... kann man denen auch nicht ganz verübeln, da sie im Gegensatz zu Microsoft ja das Betriebssystem und sämtliche Updates hierfür im Rahmen des Verkaufes eines Mac ohne Zusatzkosten bereitstellen und somit jede Virtualisierung eine Art "Raubkopie" ist an welcher der (arme) Konzern nichts verdient. Es ist hier also eher zu erwarten, dass mit jedem Apple-Update die Virtualisierungen sogar instabiler werden (könnten ja "versehentlich" neue Bugs rein kommen, die nur in einer VM auftreten).

Das soll nicht heißen, dass ich ein Gegner von Virtualisierung bin... ganz im Gegenteil, das macht in vielen Bereichen Sinn, nur halt bei Apple aufgrund der oben genannten Gründe nicht. Gerade deshalb arbeiten wir ja für den tomedo-Server an einer neuen, plattformübergreifenden Version der Servertools, die es erlaubt den Server auch problemlos auf einem Linux- oder gar () Windows-Rechner zu betreiben. Da kann dann auch fleißig und (hoffentlich) problemlos virtualisiert werden - bis dahin können wir aber leider im Bezug auf virtuelle Server nur sehr begrenzt helfen...

Comments

Hallo,

vielen Dank für die Antwort. Dann weiss ich wenigstens wo ich mit der Bugbounty beginnen kann. Bisher habe ich zwar Logs geschickt, aber keine Antwort erhalten.

Ich habe dem Support 2 unterschiedliche Arten von Logs geschickt: Servercrash und Server Tools crash (Server läuft weiter)... zeigen beide Arten den gleichen Fehler auf?

Mir ist nur unklar warum der Server praktisch nur während des Autobackups crasht. Er crasht weder im Tagesbetrieb noch wenn das Backup von Hand angestossen wird.

Ich werde mich mal mit dem VMXnet-Treiber im OSX ausseinandersetzen. Vielleicht könnte mir ein Entwickler ja etwas zu com.apple.network.connections schreiben. Hängt das Loopback-Device da auch dran? Erfolgt der Zugriff auf den Tomedo-Server über 127.0.0.1 oder über die Netzwerk-IP? etc...  dann könnte man das Problem bestimmt lösen.

ESXi 6.0 ist eigentlich für Apple zertifiziert. Ich kann in der VM auch sonst keinerlei Probleme erkennen. Kein anderes der Programme auf der VM die ja auch ständig nach Hause telefonieren sind je abgestützt. Auf dem Server laufen 13 weitere VMs ohne jegliche Probleme...

VG

JM

Answer 2

Prinzipiell ist die Virtualisierung - ich wollte seinerzeit Windows-Server 2009 auf meinem MacPro virtualisieren und habe mich deshalb damit beschäftigt - und die damit einhergehende bessere Skalierbarkeit bezüglich der verwendeten Hardware ganz unabhängig vom verwendeten Betriebssystem im Segment mittlere Datenverarbeitung: Großpraxen oder darüber hinaus, attraktiv, zumal hier professionelle load sharing- und load balancing-Systeme zum Einsatz kommen können. Ganz abgesehen davon, die gesamte Rechnerhardware outzusourcen (wovor ich nur wärmstens warnen kann!), um sich mit "dummen" Terminals zu plagen.

Dabei hatte ich ganz zufällig mit der Apple-Lizenzpolitik zu tun und ganz legal Mac OS X.5 Server und Mac OS X.6 Server virtualisiert laufen. Für alle anderen Versionen gibt es keine von Apple autorisieren Betriebssysteme, insofern sind virtualisierte Macs nicht erlaubt und im Produktiveinsatz nicht zu empfehlen. Man kann sich allerdings gegen horrende Unkostenbeteiligung extern Mac-Rechenleistung bei einzelnen Dienstleistern zukaufen (machen wohl einzelne Cross-platform-Entwickler).

Im Ergebnis bin ich seinerzeit auf Tomedo umgestiegen und habe es nicht bereut. Die Rechenleistung des Uralt-MacPRO 2013, der ja auch headless zu betreiben ist, dürfte noch 5 Jahre locker ausreichen.

Christoph Hainich

Comments

Macos Snow Leopard hat keine an Hardware gebundene Lizenz und wird daher sowohl bei Hackintosh-Installationen als auch bei Fremdvirtualisierungen benutzt. Da Vmware ESXi / vsphere 6.0 voll für Apple lizensiert ist darf man auf jedem Mac auf dem der ESXi läuft OSX auch virtualisieren.

Theoretisch muss man sich also von Snow Leopard aus die Updates hochhangeln um ein legales virtuelles Mojave auf einem nicht-Mac-Rechner zu erhalten :P

Da sich Apple aber immer weiter auf den Consumer Markt einschiesst und dem Businessegment seit 2009 (letzter XServe) immer weiter den Rücken kehrt bekommt man von seitens Apple halt keinen Support.

---

Das Outsourcen von Rechenleistung an den Server ist an für sich eine sehr elegante Sache. Sobald ich günstig an eine Nvidia Grid herankomme werde ich berichten, ob man einen 1500€-Rechner gegen ein 20€ Raspberry-Terminal tauschen kann :P

Answer 3

Meiner Meinung nach deutet der hier gezeigte Logauszug auf ein Filehandle-Problem hin. Sowohl für die Abfrage der Datenbankverbindung als auch zum Starten des tomcat müssen die Servertools mit einem anderen Programm kommunizieren, wozu ein Filehandle benötigt wird. Können diese Handles nicht vom Betriebssystem zur Verfügung gestellt werden, schlagen diese Abfragen fehl und für die Servertools erscheinen beide Dienste so, als ob sie nicht laufen würden.

Da die Servertools ein inkrementelles Backup erstellen, müssen u.U. Daten für eine große Menge an Dateien abgefragt werden. Es kann dadurch kurzzeitig zu einem hohen Bedarf an Filehandles kommen, den das System eventuell nicht decken kann.

Es ist auf jeden Fall einen Versuch wert, das Filehandle Limit zu erhöhen. Dazu im Terminal den folgenden Befehl ausführen:

sysctl -w kern.maxfiles=65536

Hier ist 65536 der neue Wert für das Limit. Den aktuellen Wert kann man sich mit

sysctl kern.maxfiles

anzeigen lassen. Der eingegebene Wert gilt nur bis zum nächsten Neustart. Wenn das System stabiler läuft und die Änderung persistiert werden soll, muss die Datei /etc/sysctl.conf editiert werden.

kern.maxfiles=65536

Comments

Diese Idee hatte Frau Ziegenhagen vom Support auch schon.

Da der Server eine Neuinstallation von High Sierra ist sind die Filehandles schon automatisch auf 65536 gestellt.

---

Dann würde ich die einfach mal auf 131.072 verdoppeln :) Falls es dann auch nicht stabiler wird, ist wenigstens eine Problemquelle ausgeschlossen.

Answer 4

Wozu wird eigentlich Xcode vom Server und den Server-Tools verwendet?

Seit dem letzten Xcode-Update habe ich keinerlei Stabilitätsprobleme mehr...

Comments

Xcode wird beim Kunden nur dazu verwendet, bestimmte Probleme (z.B. Langsamkeitsprobleme via 'Instruments') zu debuggen. In einer normalen Serverinstallation ist Xcode nicht installiert. Somit als Antwort auf ihre Frage: XCode wird vom Server und den Servertools überhaupt nicht verwendet.

Dass eine vorhandene XCode-Installation zu Problemen im Betriebssytem führt, kann ich mir eigentlich auch nur schwer vorstellen. ich halte dies nur für geringfügig wahrscheinlicher, wie dass ein andere inaktive/nicht gestartete App das Systemverhalten beeinflusst.

---

Hmm ok....hauptsache das System ist stabil.