[daemon-manager.cc] Don't log in signal handlers.

Since signals are interrupts, this can cause deadlocks. In particular, I just caught my daemon-manager hanging in malloc():

(gdb) where
#0  __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
#1  0x00007f0af052f45a in _L_lock_10416 () at malloc.c:5154
#2  0x00007f0af052cc75 in __GI___libc_malloc (bytes=26) at malloc.c:2855
#3  0x00007f0af0dd1e5d in operator new(unsigned long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007f0af0e2c929 in std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007f0af0e2e051 in char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x00007f0af0e2e468 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#7  0x000000000042785a in ?? ()
#8  0x00000000004074dc in ?? ()
#9  <signal handler called>
#10 __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:93
#11 0x00007f0af052f45a in _L_lock_10416 () at malloc.c:5154
#12 0x00007f0af052cc75 in __GI___libc_malloc (bytes=26) at malloc.c:2855
#13 0x00007f0af0dd1e5d in operator new(unsigned long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#14 0x00007f0af0e2c929 in std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#15 0x00007f0af0e2e051 in char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#16 0x00007f0af0e2e468 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#17 0x000000000042785a in ?? ()
#18 0x00000000004074b4 in ?? ()
#19 <signal handler called>
#20 0x00007f0af052ae9d in _int_malloc (av=av@entry=0x7f0af0854620 <main_arena>, bytes=bytes@entry=8192) at malloc.c:3534
#21 0x00007f0af052d60a in __libc_calloc (n=<optimized out>, elem_size=<optimized out>) at malloc.c:3194
#22 0x00007f0af051e4a3 in __GI_open_memstream (bufloc=bufloc@entry=0x7fff6d3dba30, sizeloc=sizeloc@entry=0x7fff6d3dba38) at memstream.c:85
#23 0x00007f0af0591e7d in __GI___vsyslog_chk (pri=29, flag=-1, fmt=0x18b8dc8 "[Notice] Child %d exited\n", ap=0x7fff6d3dbb18) at ../misc/syslog.c:167
#24 0x00000000004278dd in ?? ()
#25 0x0000000000407e74 in ?? ()
#26 0x00000000004042cc in ?? ()
#27 0x00007f0af04d2b45 in __libc_start_main (main=0x403acc, argc=3, argv=0x7fff6d3dc828, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff6d3dc818) at libc-start.c:287
#28 0x00000000004039d9 in ?? ()

So it looks like the orignal malloc() took a mutex, then we got a signal
which ended up calling log()m which does some std::string stuff which ends
up in malloc() again. This time it tries to take the lock and hangs, leaving
us in a deadlocked state.

I could try to make log() not do any malloc() but
that's only one symptom. Who knows where other locks exist in the stdc
library and the syslog library.

Better to just set a flag and get out of the signal handler ASAP.
[daemon-manager.cc] On SIGTERM or SIGQUIT, stop all running daemons then wait for them to die before exiting.
[daemon-manager.cc] Remove copy pasta waitpid() loop and let the main loop deal with dead children.

Now each time through the loop we look for running daemons and stop them--they
may have been started in the other part of the loop via dmctl and we make no
attempt to disable the command socket when we're shutting down (didn't seem
worth it to me).