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.

Thunderbird Lightning: cannot add new calendar

If the calendar plugin Thunderbird Lightning stops working after a system upgrade (Ubuntu 8.04 -> 9.10 in my case), just reinstall the libstdc++5 library. Before installing the library you have to deinstall the plugin from thunderbird and reinstall it afterwards.

The Thunderbird behaviour is a bit curious: the calendar and todo tabs are shown, but all previously defined calendars are missing. In addition it is not possible to add new calendars, these options are greyed out.

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).