33C3 BSD Assembly

The idea of having a BSD assembly at the 33C3 had been spreading through the community for a while. Things got real when shouted out to a couple of people via twitter. The elusive erdgeist was first to register the assembly. Ironically the only time I talked to him was after his talk. I don’t think he ever showed up at the assembly.

BSD assembly table

In terms of attendance the assembly was an outstanding success. Especially on the first day our table filled up and we had to start borrowing chairs from other tables, while our direct neighbour assembly, had at most two people in attendance.

This assembly was a counter reaction to the dwindling BSD presence at CCC events. As such this was mostly a get-to-know for interested parties. Apart from the obligatory RUN BSD stickers we didn’t have any visual clues and were notoriously difficult to find. The map feature of the wiki was broken throughout congress (according to unconfirmed rumours it worked in Safari), so we put instructions for finding us into the wiki and improvised a little with the sign. The next time we will be prepared a little better.

Throughout congress we mostly ran BSD support for visitors. Some fixes were committed to OpenBSD Wifi (mail a link to the commit please!). I got a lot of support in debugging this weird bug.

powerd++ Bug

The bug only occurs on FreeBSD 12-CURRENT and as far as we could tell with truss and dtrace, signals sent to a process compiled with a C++ compiler get lost. This affects custom signal handlers like in the powerd++ binary as well as the default signal handlers used by the loadrec binary. The bug shows itself by the processes not terminating upon reception of SIGHUP, SIGINT and SIGTERM.

According to dtrace signals sent via kill or CTRL+C are sent to the process, but the signal handlers never get called.

That is, unless pthread(3) is linked into the binary. My assumption is that pthread substitutes a lot of system functions with thread safe versions and one of those fixes the problem.