dns_hub lingers

[Tim Beale]

I had a look at this a while ago. I think I came to the conclusion that
it was only CTRL+C case that did this and the clean shutdown/pipe-close
worked fine.

It looks like in the CTRL+C case, the samba processes disappear
immediately, and so the usual graceful teardown_env_terminate() fails, e.g.

^Cteardown_env(vampire_dc)
Can't find pid for destination 'samba'
'./bin/smbcontrol samba shutdown
--configfile=/home/timbeale/code/clean/samba/st/vampire_dc/etc/smb.conf'
failed with '256'
samba child process 143771, died with signal 2, without coredump
/home/timbeale/code/clean/samba/selftest/selftest.pl: PID[143645]: Got
SIGPIPE teardown environments.

It might be because the CTRL+C signal goes to the entire process group,
which just kills samba. But perhaps the signal isn't getting to dns_hub,
or python3 handles the SIGINT slightly differently?

On 2/05/19 3:26 PM, Douglas Bagnall via samba-technical wrote:
> I find that our newest and simplest dns server still has a few
> surprises.
>
> After a number of `make test`s, I end up with several dns_hub.py
> processes hanging around (according to `ps faux |grep dns_hub`).
>
> Looking inside, I see:
>
> (gdb) py-bt
> Traceback (most recent call first):
>   <built-in method acquire of _thread.lock object at remote 0x7f32fb272e18>
>   File "/usr/lib/python3.6/threading.py", line 1072, in
> _wait_for_tstate_lock
>     elif lock.acquire(block, timeout):
>   File "/usr/lib/python3.6/threading.py", line 1056, in join
>     self._wait_for_tstate_lock()
>   File "/usr/lib/python3.6/threading.py", line 1294, in _shutdown
>     t.join()
>
> I can look into this eventually if no dns_hub experts leap forward.
> Garming thinks it has something to do with hitting control-C.
>
> Douglas
>