Skip to content

Hanging script at the end of Python multiprocessing

While writing and stress-testing a Python script which uses the multiprocessing library, I ran into the problem that occasionally the script hangs at the end. Literally runs past the last line of code and then hangs.

In this script I'm using Queues and Events, so I made sure that I properly close the queues in the forked/spawned (tried both) processes and also clean out all queues in the parent. Nevertheless occasionally - like seldom, but it happens - the script hangs. Checked the process list, checked remaining threads, checked the queues, all fine. Still ...

When I hit Ctrl+C, I get the following stack trace:

^CError in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/usr/lib/python3.9/multiprocessing/util.py", line 300, in _run_finalizers
    finalizer()
  File "/usr/lib/python3.9/multiprocessing/util.py", line 224, in __call__
    res = self._callback(*self._args, **self._kwargs)
  File "/usr/lib/python3.9/multiprocessing/queues.py", line 201, in _finalize_join
    thread.join()
  File "/usr/lib/python3.9/threading.py", line 1053, in join
    self._wait_for_tstate_lock()
  File "/usr/lib/python3.9/threading.py", line 1073, in _wait_for_tstate_lock
    if lock.acquire(block, timeout):
KeyboardInterrupt

(Can't change the Python 3.9, as I don't control the target system where this is supposed to run)

There's nothing left to join, the only two remaining threads are MainThread and QueueFeederThread.

 

After some more debugging I had the simple idea not only to empty the queue before finishing the script, but setting the queue variable to None:

worker_queue = None

This helps. The script is no longer hanging at the end. At a later point I will see if the problem is fixed in newer versions.

Ansible, delegate_to and set_fact

Another Ansible upgrade, another Playbook failing.

I have a number Playbooks which run on virtual machines. Some tasks are "outsourced" to the physical machine where the VM is running on, using "delegate_to". One of the tasks (which I haven't used in a while, because I rarely touch this machine) stopped working, and instead throws a "variable undefined" error. But from the beginning, here is the VM Playbook:

- block:
  - include: server-part.yml
  delegate_to: "{{ ansible_host }}"
  delegate_facts: True

That's the short form of it, and the $ansible_host variable holds the physical server address. That part is working. In "server-part.yml" I have the following:

# re-do the gather_facts task for the host
- action: setup

- name: Determine network interface name
  set_fact:
    main_interface: "{{ item }}"
  with_items:
    "{{ hostvars[physicalhost]['ansible_interfaces'] }}"
  when: item is match("^e[tn]")
  changed_when: false

- name: Verify interface name is set
  fail:
    msg: "Could not determine network interface name!"
  when: main_interface is not defined

The only physical network interface in this server is "eth0", that's still the case. There are a couple reasons why I still scan the list of interfaces, instead of just depending on "eth0". The main reason however is that this part also works with the enumeration systemd is doing with network interfaces (they have "en" names, instead of "eth"). But suddenly $main_interface in the next step is no longer defined.

Digging deeper (aka: -vvvv) it shows that Ansible is setting the correct interface name in the "set_fact" task, but then the variable is no longer defined immediately after that. What? I'm not sure I had to use this Playbook since my host was upgraded to Ansible 2.8.3, but I couldn't find any issues matching this problem either.

 

Continue reading "Ansible, delegate_to and set_fact"

Apache Karaf client in openHAB, and the "Session has been closed" error

Don't you love it when things suddenly stop working?

In my openHAB installation I have a check which verifies that the weather data is up to date. Otherwise it restarts the openhab2 service. And this check stopped working ... Leaving the kitchen display not updated for a longer time. The same display where I expect the entire installation to "just work", and don't create so many different problems. Seems to be a hard problem to have an openHAB installation without any trouble ...

 

Continue reading "Apache Karaf client in openHAB, and the "Session has been closed" error"

openHAB HABpanel configuration gets destroyed, HABpanel stays blank

openHAB is a stream of pure joy when it comes to debugging. Especially when all I want is a small display in the kitchen, working autonomous and without the need to restart it all the time or login to fix issues.

The latest installment of that endeavor was a black screen in the browser, with no way to even get to the usual HABpanel controls. After some debugging, it turns out that the file "habpanel.config" (/var/lib/openhab2/config/org/openhab/habpanel.config) on the openHAB server was destroyed, or more accurate: shortened to 4829 bytes. Lucky me I have this file in my Ansible playbooks, and whenever there is a change, a copy of this file is fetched to my Ansible host. From there it goes into my backups, and I can restore a couple dozen versions back, if needed. So not all is bad, but still something is not working as expected. First I installed a copy of this file from my backups - but turns out shortly later the file is shortened again. Later I figured that the file is always shortened when the openHAB service restarts. This particular instance was still running openHAB 2.4, and I used this opportunity to upgrade to 2.5, test my Playbooks (and exclude the one config file from everything) and see if the problem persists. It does. Except that after upgrading to 2.5 the file is no longer shortened to 4829 bytes, but to 4875 bytes.

Every time that happens, the file ends somewhere in the middle of the HABpanel panel configuration - and naturally the HABpanel service can no longer read that file and shows a blank screen. I would wish that it rather shows an error message, or does something useful here, but oh well.

For a while (and mostly because I was busy with other tasks) I helped myself by changing the owner of "habpanel.config" and the directory this files lives in to "root:root". This threw a couple other errors into the logfile, but helped somewhat because the config file got no longer destroyed when the service restarted.

 

Continue reading "openHAB HABpanel configuration gets destroyed, HABpanel stays blank"

Navigon 6310 und Navigon 6350 Live - schon wieder

Wir hatten ja mit dem Navigon schon viel Spaß (siehe hier und hier). Nun sind während des heißen Sommers im Fuß der Fahrzeughalterungen sämtliche Befestigungen für die dort eingebaute Feder gebrochen - das Plastik sah geschmolzen und porös aus. Nun denn, Kaufbeleg herausgesucht und ins Geschäft. Bei der Gelegenheit wurde das gesamte Gerät eingeschickt und die bereits bekannten Probleme wurden reklamiert.

Ergebnis: die Fahrzeughalterung wurde getauscht. Das Gerät wurde auf Werkseinstellungen zurückgesetzt. Mehr wurde nicht getan. Nicht mal eine aktuelle Softwareversion aufgespielt. Als Konsequenz waren natürlich auch sämtliche aktualisierten Karten gelöscht - da die "Probezeit" jedoch vorbei ist, dürfen wir jetzt die Aktualisierungen für die Karten kaufen. Vielen Dank Navigon, das ist echter Service.

Eine aktuelle Software ist mittlerweile wieder installiert. Der Spaß kann weitergehen:

Wenn man nun an einer Autobahnausfahrt oder an einem Autobahnkreuz vorbeifährt, bei dem die Ausfahrt am Ende wieder auf die Autobahn führt, möchte das Gerät einen neuerdings unbedingt über die Ausfahrt schicken. Keine Ahnung, welcher Programmierer sich so etwas ausgedacht hat - auf jeden Fall ist der Umweg über die Ausfahrt langsamer als über die Autobahn. Beim ersten Mal war es noch lustig, ab dem vierten oder fünften Mal ist das nur noch störend.

Wird wohl mal langsam Zeit für ein anderes Gerät.

Navigon 6310 und Navigon 6350 Live - nicht für das Ausland geeignet

Mit unserem Navigationsgerät Navigon 6350 Live hatten wir vor ca. einem Monat schon einmal viel Spaß in Belgien. Das Gerät hat sich vor Brüssel mehrfach unmotiviert ausgeschaltet.

Das gleiche Vergnügen hatte ich nun bei einer Fahrt in die andere Richtung. Am Wochenende durfte ich aus familiären Gründen Richtung Polen/Schlesien fahren. Genau auf dem Grenzstreifen beim Überfahren der Grenze bei Görlitz hat sich das Navigationsgerät das erste Mal ausgeschaltet. Bis hinter Breslau/Wrocław war das Gerät danach nicht zu bewegen, auch nur einen Satelliten zu finden: wenn man auf "Optionen" tippt, gibt es dort eine Anzeige für GPS-Status. Diese stand während der gesamten rund 200 km auf "0 Satelliten". Zwei oder drei Neustarts haben an dieser Situation nichts verändert, zum Glück kenne ich diese Strecke auswendig.

Erst hinter Breslau wurden dann langsam mehrere Satelliten gefunden - gefolgt von einem weiteren Absturz, kaum dass die aktuelle Position bestimmt werden konnte.

Das Spiel setzte sich auf der Hinfahrt fort, um dann auf der Rückfahrt noch mehrere Male aufzutreten. Kaum passierten wir die Grenze zu Deutschland, war wieder alles in Ordnung.

Vielleicht sollten die Tester von Navigon einfach mal mit ihren eigenen Geräten ins Ausland fahren ... Atlas mitnehmen nicht vergessen, könnte sonst sein, dass ihr euch verliert.

Navigon 6310 und Navigon 6350 Live - nicht zu empfehlen

Nachdem unser altes Navi unfreiwillig seinen Weg in die falschen Hände gefunden hat, wollten wir ein neues haben. Nach etwas Suchen sind wir erst mal beim Navigon 6350 Live hängen geblieben.

Gleich zu Anfang gab es erst mal Ärger: das USB-Kabel war kaputt, das Gerät wurde an keinem Rechner erkannt. Dumm, dass das Kabel eine Spezialanfertigung ist und man nicht einfach ein beliebiges anderes USB-Kabel nutzen kann.

Nach etwas Stress im Geschäft ("im Service funktioniert alles", beim Testen mit dem Kunden dann auf einmal doch nicht) wurde das Kabel ausgetauscht. Danach war ein Verbinden mit dem Rechner möglich.

Was besonders negativ auffällt: das Gerät braucht häufig zwischen 10 und 15 Minuten, um seine aktuelle Position zu finden. Ein schnelleres Finden der Position klappt nur, wenn das Gerät nur kurz (maximal wenige Stunden) ausgeschaltet war. Andernfalls ist z. B. ein Spaziergang vom Hotel zur Pizzeria in der Stadt, das Bestellen einer Pizza und der Spaziergang zurück nicht ausreichend, damit das Gerät seine Position erkennt. Auch nach dem erstmaligen Finden der Position verliert das Navigon in den ersten Minuten immer mal wieder den Empfang des GPS-Signal. Das äußert sich in teilweise minutenlangen Aussetzern beim Navigieren. Erst nach ca. 20 Minuten funktioniert alles einwandfrei. Da das Gerät den GPS-Status (Anzahl gefundener Satelliten) anzeigt, sieht man, dass die Anzahl erkannter Satelliten in der ersten Zeit stark schwankt. Dieses Verhalten ist eigentlich nur lästig und selbst das 2 1/2 Jahre alte JVC hat das wesentlich besser hinbekommen.

Das Navigieren mit dem Gerät funktioniert sehr gut, die Darstellung der Abfahrten sowie die Warnung vor gefährlichen Stellen (z. B. Kurven) ist hilfreich - man müsste als Fahrer bloß mal drauf achten ;-) Die grafische Darstellung lässt keine Wünsche offen und das Display ist groß genug, um das Gerät überall im Fahrzeug zu positionieren.

Bleibt letzten Endes bloß das Problem mit der langen Initialisierungszeit - das ist ein dicker Minuspunkt.

Update I: Das Gerät hat sich auf der Autobahn vor Brüssel in Belgien mehrmals unmotiviert ausgeschaltet und neu gestartet. Jedesmal kam dann die lange Wartezeit für das erneute Suchen der aktuellen Position hinzu - gefolgt von einem weiteren Absturz. Letztendlich hat es geholfen, das Gerät von der Bordspannung zu trennen und auf Batteriebetrieb weiter zu fahren.

Update II: Die Entfernungsanzeige, wie weit man aktuell noch auf dieser Straße fahren muss, ist sehr nervig gelöst. Das Gerät betrachtet jedes Autobahnkreuz- oder Dreieck und teilweise sogar Abfahrten als nächsten Punkt und zeigt die Entfernung halt nur bis dorthin an. Wenn ich eine lange Strecke auf ein und derselben Autobahn fahre, interessiert mich die Entfernung zum nächsten Autobahnkreuz jedoch überhaupt nicht. Viel lieber würde ich wissen, wie weit es noch insgesamt bis zu meiner Abfahrt ist (um z. B. noch passend eine Pause einzulegen).

Update III: Mitten in den Niederlanden hat die Navigation bei mehreren Autobahnknoten komplett versagt. Das Gerät hat weder angezeigt, auf welcher Autobahn man weiter fahren soll noch hat es überhaupt Kentniss von dem kommenden Knotenpunkt genommen. Statt dessen wurde einfach weiter die Übersichtskarte eingeblendet. Peinlich.

Update IV: Ebenfalls in den Niederlanden ist die vorausberechnete Ankunfszeit mal eben um eine halbe Stunde vor oder zurück gesprungen. Nicht schritt- oder minutenweise sondern während der Fahrt gab es Sprünge in der Größenordnung einer halben Stunde. Ganz ohne Verkehrsmeldungen (es war mitten in der Nacht).

Ungenaue Zeitangaben des Navi

Weiter geht es in der Serie der möglichen Verbesserungen in der Software für Navigationsgeräte. Dieses Mal ist das leidige Problem der ungenauen Zeitangaben dran.

Wenn in einer Stadt zwei Hauptstraßen kreuzen, sollte pauschal eine Minute (zumindest mein Erfahrungswert) mehr einberechnet werden. Wenn an dieser Kreuzung links abgebogen werden soll, dürfen es auch 90 Sekunden sein. Das Ergebnis deckt sich dann ungefähr mit dem, was ich beim Autofahren beobachte. Bisher scheint zumindest unser Navi keinerlei Wartezeiten zu kalkulieren, dadurch erhöht sich die Ankunftszeit natürlich ständig, solange man an einer Kreuzung auf eine grüne Ampel wartet.

Wieder gilt: Verwendung freigestellt, aber bei Patenten melde ich Prior Art an ;-)

iTunes and the dullness

Got an iPod as a christmas present and since this iPod (the "Touch" version) is not supported by the usual Linux tools, i had to get a Windows machine at hand and install iTunes. Now it seems that this software is not what you expect to be "stable" ... despite the fact that it is running on windows.

I installed iTunes on the first machine: the software keeps crashing when i connect the iPod. Sometimes the first time i connected the iPod, sometimes the second time but never could connect the iPod more than 3 times without a crash of the Apple Mobile Helper which in consequence crashed the whole iTunes software. So i moved iTunes to another windows pc, rarely used, only Firefox and an ssh client on it. Things keep crashing, no chance.

So if i want to sync the iPod i have to wait until all downloads are finished or i have a good chance that i can restart all of them. This sucks.

But beside all this problems with beta software: iTunes is slow. Really slow. If i want to search for a new podcast or just surf in the store, the software sometimes needs 2 or 3 minutes just to open the connection. We have DSL at home, so speed should not be the cause of the problem.

Every webserver is able to return results in no time (speak: some seconds), but watching the iTunes network traffic you can see, that the software is sending the requests, the packets pass the border router and 30 seconds up to 2 or 3 minutes later the answer packets arrive. Not just one time, every times. What's wrong here? Just because you are market leader you can have slow hardware?

Sprechender Reisebegleiter

Wir hatten uns so ein hübsches kleines Navi gekauft, ein Traffic Assist Highspeed II, mit TMC und Karten für ganz Europa. Versprachen jedenfalls sowohl Verpackung wie Rückfrage beim Verkäufer. Letztendlich stellte sich heraus,das Harman/Becker auch dann schon mal ein Land angibt, wenn das Kartenmaterial maximal ein paar Städte und die Autobahnen dazwischen abdeckt.


Da weder Verkäufer noch Hersteller bereit waren, das Kartenmaterial kostenlos nachzuliefern, wenn Mitte diesen Jahres ein Update erscheint, wurde das ganze dann ein Garantiefall und prompt zurückgegeben. Die Geräte von Harman/Becker sind sicherlich nicht ganz billig, jedenfalls dieses nicht. Aber das man für versprochene Leistungen extra zahlen darf, scheint auch in der Klasse üblich zu sein.