You are here: Home » Topic » Unable to stop mt-daapd 0.2.4 with daemontools

Unable to stop mt-daapd 0.2.4 with daemontools

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • #363
    marlowe
    Participant

    All,

    I installed mt-daapd 0.2.4 stable on an iMac running Yellow Dog Linux 4.1. I am able start the service using the RedHat start script with the following modification: added /usr/local/sbin to PATH in /etc/init.d/functions.

    I would like to run mt-daapd out of DJB’s daemontools (http://cr.yp.to/daemontools.html). I have been able to successfully start mt-daapd from daemontools with the following run script

    #!/bin/sh
    exec 2>&1
    mt-daapd -f

    However when I attempt to stop the service with the following command:

    svc -d /service/mt-daapd

    the service does not stop. I have sent the assortment of signals listed here (http://cr.yp.to/daemontools/svc.html) and the service does not stop. I reviewed the Red Hat init.d script and noticed the stop portion says to send an INT signal to mt-daapd to stop it. However, the comments in the script state that this broken.

    Can someone please point me to some material which explains which signals to send to mt-daapd to shut it down?

    Thanks,
    Patrick

    #5078
    rpedde
    Participant

    @marlowe wrote:

    All,

    I installed mt-daapd 0.2.4 stable on an iMac running Yellow Dog Linux 4.1. I am able start the service using the RedHat start script with the following modification: added /usr/local/sbin to PATH in /etc/init.d/functions.

    I would like to run mt-daapd out of DJB’s daemontools (http://cr.yp.to/daemontools.html). I have been able to successfully start mt-daapd from daemontools with the following run script

    #!/bin/sh
    exec 2>&1
    mt-daapd -f

    However when I attempt to stop the service with the following command:

    svc -d /service/mt-daapd

    the service does not stop. I have sent the assortment of signals listed here (http://cr.yp.to/daemontools/svc.html) and the service does not stop. I reviewed the Red Hat init.d script and noticed the stop portion says to send an INT signal to mt-daapd to stop it. However, the comments in the script state that this broken.

    Can someone please point me to some material which explains which signals to send to mt-daapd to shut it down?

    Thanks,
    Patrick

    The problem is that the thread that is the foreground thread isn’t the thread that handles signals. When it runs, the parent thread spawns a web server thread, a signal handling thread, and forks a mdns process. Then it waits for a quit event, which gets handled by the signal thread.

    The problem is that the signals don’t seem to work the way that pthreads *say* they are supposed to on all applications. I’ve got some thoughts on fixing this, but not for 0.2.4, and I don’t really see a way to fix 0.2.4 to work, particularly when we’re thiiiiiis close to a new stable.

    If you want to start working from nightlies, I can try to add the functionality you are looking for.

    — Ron

    #5079
    marlowe
    Participant

    Ron,

    Thanks for your explanation and offer to fix it in the nightlies. I am downloading the latest nightly and will testing it tonight. I will post my findings to the forum and the list.

    Thanks,
    Patrick

    #5080
    marlowe
    Participant

    Ron,

    I tested svn 1281 and am still experiencing the same symptoms. Is there any debug output I can provide you to help facilitate a fix?

    Thanks,
    Patrick

    #5081
    rpedde
    Participant

    @marlowe wrote:

    Ron,

    I tested svn 1281 and am still experiencing the same symptoms. Is there any debug output I can provide you to help facilitate a fix?

    Thanks,
    Patrick

    You just need the parent process to respond to a SIGHALT, right?

    I’ll work on that.

    — Ron

    #5082
    marlowe
    Participant

    Close, I need it to respond to a SIGTERM. If you could get the parent thread to respond to signals, that would be perfect. My understanding is the nightlies respond to SIGTERM now.

    Thanks,
    Patrick

    #5083
    rpedde
    Participant

    @marlowe wrote:

    Close, I need it to respond to a SIGTERM. If you could get the parent thread to respond to signals, that would be perfect. My understanding is the nightlies respond to SIGTERM now.

    They do, but the parent process has signals masked. I though the pthreads spec said that the signal should be delivered to a thread without signals blocked, but apparently that’s wrong, or I don’t understand pthreads correctly. (Wonder which one that is?)

    #5084
    marlowe
    Participant

    I tested svn-1498 with daemontools similar to the setup posted for 0.2.4. The server successfully stops with the following command:

    # svc -d /service/mt-daapd

    However it falls to start successfully with the following error.

    Initializing database
    Starting web server from /usr/local/share/mt-daapd/admin-root on port 3689
    Listen port: Address already in use
    Error starting web server: Address already in use
    Aborting

    The error message continues to repeat as daemontools tries to restart the service.

    A netstat -an confirms the web server does not stop when mt-daapd is stopped. Is there a way to ensure the webserver stops when mt-daapd stops.

    Thanks,
    Patrick

    #5085
    rpedde
    Participant

    @marlowe wrote:

    I tested svn-1498 with daemontools similar to the setup posted for 0.2.4. The server successfully stops with the following command:

    # svc -d /service/mt-daapd

    However it falls to start successfully with the following error.

    Initializing database
    Starting web server from /usr/local/share/mt-daapd/admin-root on port 3689
    Listen port: Address already in use
    Error starting web server: Address already in use
    Aborting

    The error message continues to repeat as daemontools tries to restart the service.

    A netstat -an confirms the web server does not stop when mt-daapd is stopped. Is there a way to ensure the webserver stops when mt-daapd stops.

    Thanks,
    Patrick

    Hrm. thought it would have done it. I’ll re-check it though. Platform? And are you linuxthreads or nptl?

    #5086
    marlowe
    Participant

    My machine uses NPTL 2.3.4 running CentOS 4.3 x86_64. I can test the performance on OS X 10.4 and CentOS 4.3 i386 if needed. Thanks for your help with this.

    #5087
    rpedde
    Participant

    @marlowe wrote:

    My machine uses NPTL 2.3.4 running CentOS 4.3 x86_64. I can test the performance on OS X 10.4 and CentOS 4.3 i386 if needed. Thanks for your help with this.

    I have osx coverd, but the other two would be a help. Thanks.

    — Ron

Viewing 11 posts - 1 through 11 (of 11 total)
  • The forum ‘General Discussion’ is closed to new topics and replies.