FireFly Media Server › Firefly Media Server Forums › Firefly Media Server › General Discussion › Unable to stop mt-daapd 0.2.4 with daemontools
- This topic has 10 replies, 2 voices, and was last updated 17 years, 9 months ago by rpedde.
-
AuthorPosts
-
17/06/2006 at 3:24 PM #363marloweParticipant
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 -fHowever 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,
Patrick21/06/2006 at 4:55 AM #5078rpeddeParticipant@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 -fHowever 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,
PatrickThe 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
21/06/2006 at 12:12 PM #5079marloweParticipantRon,
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,
Patrick06/07/2006 at 12:58 PM #5080marloweParticipantRon,
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,
Patrick07/07/2006 at 9:05 AM #5081rpeddeParticipant@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,
PatrickYou just need the parent process to respond to a SIGHALT, right?
I’ll work on that.
— Ron
07/07/2006 at 12:19 PM #5082marloweParticipantClose, 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,
Patrick07/07/2006 at 9:19 PM #5083rpeddeParticipant@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?)
21/02/2007 at 4:45 PM #5084marloweParticipantI 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
AbortingThe 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,
Patrick22/02/2007 at 1:21 AM #5085rpeddeParticipant@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
AbortingThe 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,
PatrickHrm. thought it would have done it. I’ll re-check it though. Platform? And are you linuxthreads or nptl?
22/02/2007 at 2:26 AM #5086marloweParticipantMy 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.
-
AuthorPosts
- The forum ‘General Discussion’ is closed to new topics and replies.