FreeBSD 11: bundy refuses to start with " ValueError: the fd 7 must be in non-blocking mode"

[cstrotm]

on FreeBSD 11, bundy installed from package will terminate on startup

INFO [bundy-init.init]: BUNDY_STARTING starting BUNDY: bundy 20110223 (BUNDY 1.2.0)
FATAL [bundy-init.util]: PYTHON_UNHANDLED_EXCEPTION program terminated with exception ValueError: the fd 7 must be in non-blocking mode. More info in /tmp/tmpk8uzjry4

Detail information:

Traceback (most recent call last):
  File "/usr/local/lib/python3.5/site-packages/bundy/util/traceback_handler.py", line 33, in traceback_handler
    return main()
  File "/usr/local/libexec/bundy/bundy-init", line 1375, in main
    signal.set_wakeup_fd(wakeup_pipe[1])
ValueError: the fd 7 must be in non-blocking mode

Seems to be a regerssion caused by an API change in Python3 between 3.3 and 3.4

[shane-kerr]

Carsten, I pushed a fix for this into master (sorry I thought I was working on my own branch). Can you please give it a try?

[cstrotm]

Hi Shane, thank you very much, I will give it a try. My solution-try looked similar, but was failing down the road, but I already see what I've done wrong ... I'll test and give feedback ...

[cstrotm]

Unfortunately, it now leads to another issue down the road, which might or might not be related:

csx201# bundy                                       
INFO [bundy-init.init]: BUNDY_STARTING starting BUNDY: bundy 20110223 (BUNDY 1.2.0)
DEBUG [bundy-init.init]: BUNDY_CHECK_MSGQ_ALREADY_RUNNING checking if msgq is already running
INFO [bundy-init.init]: BUNDY_CONFIGURATOR_START bundy component configurator is starting up
DEBUG [bundy-init.init]: BUNDY_CONFIGURATOR_BUILD building plan '{}' -> '{'cfgmgr': {'kind': 'core', 'priority': 198, 'special': 'cfgmgr'}, 'sockcreator': {'kind': 'core', 'priority': 200, 'special': 'sockcreator'}, 'msgq': {'kind': 'core', 'priority': 199, 'special': 'msgq'}}'
DEBUG [bundy-init.init]: BUNDY_CONFIGURATOR_RUN running plan of 3 tasks
DEBUG [bundy-init.init]: BUNDY_CONFIGURATOR_TASK performing task start on Socket creator
INFO [bundy-init.init]: BUNDY_COMPONENT_START component Socket creator is starting
INFO [bundy-init.init]: BUNDY_SOCKCREATOR_INIT initializing socket creator parser
DEBUG [bundy-init.init]: BUNDY_STARTED_PROCESS_PID started bundy-sockcreator (PID 1139)
DEBUG [bundy-init.init]: BUNDY_CONFIGURATOR_TASK performing task start on msgq
INFO [bundy-init.init]: BUNDY_COMPONENT_START component msgq is starting
INFO [bundy-init.init]: BUNDY_STARTING_PROCESS starting process bundy-msgq
DEBUG [bundy-init.init]: BUNDY_STARTED_PROCESS_PID started bundy-msgq (PID 1140)
ERROR [bundy-init.init]: BUNDY_COMPONENT_START_EXCEPTION component msgq failed to start: recv() on cc session timed out
ERROR [bundy-init.init]: BUNDY_COMPONENT_FAILED component msgq (pid None) failed: unknown condition
FATAL [bundy-init.init]: BUNDY_COMPONENT_UNSATISFIED component msgq is required to run and failed
ERROR [bundy-init.init]: BUNDY_CONFIGURATOR_PLAN_INTERRUPTED configurator plan interrupted, only 1 of 3 done
INFO [bundy-init.init]: BUNDY_KILLING_ALL_PROCESSES killing all started processes
INFO [bundy-init.init]: BUNDY_SEND_SIGKILL sending SIGKILL to Socket creator (PID 1139)
WARN [bundy-init.init]: BUNDY_SOCKCREATOR_KILL killing the socket creator
FATAL [bundy-init.init]: BUNDY_STARTUP_ERROR error during startup: Unable to start bundy-msgq: recv() on cc session timed out
csx201# ps aux | grep bundy
root       1140   0.0  0.4   95492  17368  0  I    17:03    0:00.23 /usr/local/bin/python3.5 /usr/local/libexec/bundy/bundy-msgq
root       1142   0.0  0.1   14804   2380  0  S+   17:04    0:00.00 grep bundy

bundy-msgq has been started, but it seems that the bundy-init does not wait long enough. That might be a result of the pipe now being non-blocking, or it might be an unrelated other issue.

I will try if the same or similar issue will appear on a different platform (macOS or Linux) and report.

[shane-kerr]

Ug. I am really sorry for pushing this on the main branch and not on an issue branch. 😢

Anyway, should we try setting the pipe back to blocking after we set it as the wakeup file descriptor? 😄

I put this one-line change in a new branch, that you can try here:

https://github.com/shane-kerr/bundy/tree/issue118

[cstrotm]

On 11.05.17 10:05 PM, Shane Kerr wrote:

Ug. I am really sorry for pushing this on the main branch and not on an issue branch. 😢

Anyway, should we try setting the pipe back to blocking after we set it as the wakeup file descriptor? 😄

I put this one-line change in a new branch, that you can try here:

https://github.com/shane-kerr/bundy/tree/issue118

I'm trying to verify that the new error is connected to the change (non-blocking pipe). I want to test under macOS, as it is BSD like but different enough. However I've ended up fixing compiling with Botan 2 and now I'm chasing some infinitive recursion warnings. Yak shaving business :)

I'll give feedback once I have the code compiling on the latest macOS.

-- CS

[cstrotm]

Hi Shane, the problem with msgq was unrelated to the non-blocking pipe, see Issue #120 and my proposed fix (tested under Debian 9 == yeti-dns01 and Fedora 26)