Insurgency Dedicated Server – crash_handler Prozess blockiert Port

Der Insurgency Dedicated Server für Linux hat seit einiger Zeit ein Stabilitäts-Problem. Wenn der Server crashed – was ja durchaus häufiger vorkommt – wird ein Crash-Dump für die Entwickler geschrieben. In diesem Fall wird der crash_handler-Prozess gestartet, der diesen dann an die Entwickler sendet. In der Prozessliste tauchen dann diese Prozesse auf:

[root@mineralwasser ~]# ps auxw | grep newworld
insurge+ 16353 100 0.0 21428 4612 pts/2 Rl+ 2016 4339:54 ./crash_handler 16350 http://crash.newworldinteractive.com/api/dumps/submit/insurgency 1 22907 -1
insurge+ 31057 100 0.0 21428 4540 pts/2 Rl+ 14:59 10:39 ./crash_handler 31054 http://crash.newworldinteractive.com/api/dumps/submit/insurgency 1 22907 -1
insurge+ 32614 100 0.0 21428 4776 pts/2 Rl+ 2016 3838:20 ./crash_handler 32611 http://crash.newworldinteractive.com/api/dumps/submit/insurgency 1 22907 -1

Es ist zwar cool, dass es so etwas gibt, jedoch hat dieser Prozess drei große Probleme. Der Prozess

  1. läuft endlos
  2. belegt permanent einen CPU Kern zu 100%
  3. verhindert das der Port des Gameservers freigegeben wird. Wenn der Server dann neu starten will, dann kann er auf diesen nicht binden. Daraufhin wird so lange hochgezählt, bis ein freier Port gefunden wurde. Das Resultat für die Spieler: Der Server verschwindet aus der Favoritenleiste, da der Server auf Port 27016 und nicht auf 27015 läuft.

Ich habe dazu ein Ticket bei New World Interactive eröffnet. Dort wurde mir sehr schnell gesagt, dass das Problem bekannt ist. Nun ja ich warte nun schon etwas länger darauf, deswegen habe ich einen Workaround gefunden. In die Crontab des UNIX-Gameserveraccounts einfach folgenden Eintrag hinzufügen:

# Kill the insurgency crash_handler process
*/1 * * * * /usr/bin/pkill crash_handler

Das funktioniert, da der Server dem crash_handler Prozess ein bisschen Zeit gibt, bevor der Server neustartet. Gerade genug, damit der Cronjob aktiv werden kann.

Insurgency Dedicated Server – crash_handler process blocks port

The insurgency dedicated server for linux currently has some problemes with its stability. If the server crashes – which happens quite often – a crash dump file is written and sent to the developers for further review. There’s a special binary named crash_handler which sends the dump file. When starte the process list looks like this:

 

[root@mineralwasser ~]# ps auxw | grep newworld
insurge+ 16353 100 0.0 21428 4612 pts/2 Rl+ 2016 4339:54 ./crash_handler 16350 http://crash.newworldinteractive.com/api/dumps/submit/insurgency 1 22907 -1
insurge+ 31057 100 0.0 21428 4540 pts/2 Rl+ 14:59 10:39 ./crash_handler 31054 http://crash.newworldinteractive.com/api/dumps/submit/insurgency 1 22907 -1
insurge+ 32614 100 0.0 21428 4776 pts/2 Rl+ 2016 3838:20 ./crash_handler 32611 http://crash.newworldinteractive.com/api/dumps/submit/insurgency 1 22907 -1

It’s okay that such a mechanism exists if it wouldn’t have three problems. The process:

  1. never finishes
  2. blocks 100% of a CPU core
  3. prevents the release of the gameserver port. For me that’s the main problem. If the new server is started after a crash the port is still blocked. The gameserver then seeks for the next free port. It won’t show up in you favourite list anymore because it binds then for example on port 27016 and not on 27015.

I’ve opened a ticket at New World Interactive. They told me pretty quick that the problem is known. For now I’m already waiting a bit long for a fix. I’ve found a workaround. Place the following command snippet in the gameservers‘ UNIX user:

# Kill the insurgency crash_handler process
*/1 * * * * /usr/bin/pkill crash_handler

This will kill the crash_handler-process every minute. The gameserver gladly gives the crash_handler-process enough time bevore the server finally restarts. Just enough that the cronjob can kick in and force the „release“ of the port.

UniFi: Access Point schaltet Radio ab ohne Controller

Beim Updaten des Betriebssystems auf dem mein Unifi Controller läuft hatte ich vor kurzem ein sehr ärgerliches Problem: Als der Controller abgeschaltet war hat der Access Point nach ca. drei Minuten aufgehört das WLAN auszustrahlen. Das ist Blöd, wenn der Laptop in dem weggebrochenen WLAN hängt.

Nur weil der Controller nicht erreichbar ist sollte der Access Point aber nicht aufhören das WLAN auszustrahlen. Dieses Verhalten kann man auch einstellen. Die Entsprechende Einstellung befindet sich in den Site-Setting und heißt „Enable connectivity monitoring and wireless uplink“:

 

Source: https://community.ubnt.com/t5/UniFi-Wireless/What-does-Uplink-Connectivity-monitor-do/td-p/1561335

UniFi Controller: TLS Zertifikat tauschen

Ich habe sehr lange die D-Link DAP-1665 für mein WLAN an meinen Wohnorten benutzt. Leider bin ich vom Handling und von der Performance her nicht wirklich überzeugt gewesen und habe deswegen auf Access Points von Ubiquity Networks geupgraded. Genauer gesagt auf die UniFi AP AC Lite.
Hersteller: https://www.ubnt.com/unifi/unifi-ap-ac-lite/
Amazon: http://amzn.to/2hMw3Fi

Die Besonderheit bei diesen Geräten ist, dass die Access Points von einem Controller gesteuert werden. Die WLAN Einstellungen und viele weitere Optionen werden zentral über dieses Managment Tool gesteuert. Im professionellem Umfeld  ist ein arbeiten ohne Controller überhaupt nicht denkbar. Im privatem Umfeld sind solche Systeme nicht üblich, da sie normalerweise sehr teuer und umständlich sind. Ubiquity hat mit seinen 100 € Access Points und kostenloser Controller Software aber ein tolles Produkt für dein Heimanwender geschaffen. Ein ganzes Haus zum Beispiel mit 4-8 Access Points effizient abzudecken sind somit kein Problem mehr.

Die Controller Software ist in Java implementiert und hat als Benutzerschnittstelle eine Weboberfläche. Diese ist standardmäßig mit TLS abgesichert, jedoch muss dazu ein valides Zertifikat erstellt werden, damit der Browser nicht permanent vor einer unsicheren Verbindung warnt.
Um die Weboberfläche mit einem eigenen SSL/TLS Zertifikat auszustatten, muss man ein bisschen basteln, da diese keine Möglichkeit zum Austausch bietet. Read More „UniFi Controller: TLS Zertifikat tauschen“