Permalink
Commits on Jun 29, 2015
  1. [dmctl.cc] Handle the case where daemon-manager closed the socket bef…

    caldwell committed Jun 29, 2015
    …ore we even wrote our command out.
    
    This is happening consistently on Raspberry Pi (raspbian linux).
    
    Fixes: dm-9
    Fixes: c5bf7ab5b05c63410d144158adb6c6ddc70bb341
  2. [dmctl.cc] Ignore ECONNRESET on 2nd read when we've already gotten a …

    caldwell committed Jun 29, 2015
    …response.
    
    This happens for me intermittently (90% of the time) on x86-64 Debian
    Linux. I believe the daemon-manager side it correct and that this is just a
    POSIX race.
    
    Re: dm-9
    Re: c5bf7ab5b05c63410d144158adb6c6ddc70bb341
  3. [dmctl.cc] Ignore SIGPIPE (we check for errors instead)

    caldwell committed Jun 29, 2015
    On a Raspberry Pi install, daemon-manager is responding to the dmctl connect
    so quickly that the first write never even gets out (it always does on my
    Mac and x86-64 debian machines). This is the first step to getting the real
    error message to print instead of nothing.
    
    Re: dm-9
    Re: c5bf7ab5b05c63410d144158adb6c6ddc70bb341
Commits on Jun 28, 2015
  1. [user.cc] Also create ~/.daemon-manager directory.

    caldwell committed Jun 28, 2015
    Fixes dm-8
    Fixes 304724a2ea469b366011e1fdcb4cfa69445f1c37
Commits on Jun 20, 2015
Commits on Dec 6, 2014
Commits on May 17, 2014
Commits on Apr 10, 2014
  1. [daemon-manager.cc] Remove copy pasta waitpid() loop and let the main…

    caldwell committed Apr 10, 2014
    … 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).
  2. [daemon-manager.cc] On SIGTERM or SIGQUIT, stop all running daemons t…

    caldwell committed Apr 10, 2014
    …hen wait for them to die before exiting.
  3. [daemon-manager.cc] Don't log in signal handlers.

    caldwell committed Apr 10, 2014
    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.
Commits on Mar 9, 2014
  1. [daemon-manager-completion.bash] Fix regression in last commit.

    caldwell committed Mar 9, 2014
    2nd awk needs to substitute pipes to spaces, not commas, since it doesn't
    set IFS.
    
    Remove the function and inline the gsub(). It's (slightly) shorter and not
    hard to understand.
  2. [daemon-manager-completion.bash] Use only POSIX awk functions. Sigh.

    caldwell committed Mar 9, 2014
    Debian/Ubuntu only have "mawk" installed by default, which doesn't have gensub().
  3. [daemon-manager-completion.bash] Include both prefixed and non-prefix…

    caldwell committed Mar 9, 2014
    …ed versions in the completion list.
    
    This mirrors how dmctl works (it matches a non-prefixed name iff the name is
    unique).
  4. [Makefile] Version 0.99

    caldwell committed Mar 9, 2014
  5. Add "export var=value" syntax to daemon config for adding environment…

    caldwell committed Mar 9, 2014
    … variables.
    
    You could do it previosuly by just sticking it on the "start" line like:
    
        start=DAVID=david RULES=rules exec echo $DAVID $RULES
    
    ...but that got real ugly when the environment variables started piling
    up. The new syntax looks much better:
    
        export DAVID=david
        export RULES=rules
        start=exec echo $DAVID $RULES
    
    Closes: #158357055b
Commits on Mar 8, 2014
  1. [daemon-manager.cc] Add support for linux's SO_PEERCRED

    caldwell committed Mar 8, 2014
    Which of course is different from OS X/BSD's for some stupid reason.
  2. Use a single command socket for all users.

    caldwell committed Mar 8, 2014
    We now authorize users by using the LOCAL_PEERCRED socket option. This
    should be equivalent (security-wise) to the old method of using file system
    permissions.
    
    This moves all the socket serving/connecting code out of user.cc and into
    daemon-manager.cc (for the server), dmctl.cc (for the client), and
    command-sock.cc (for the shared sock_addr stuff).
    
    Closes #2