FS#8219 - calling '/etc/rc.d/mpd stop' does not kill the daemon
Attached to Project:
Arch Linux
Opened by Andrea Benazzo (benazzo) - Friday, 05 October 2007, 09:46 GMT
Last edited by Aaron Griffin (phrakture) - Monday, 04 February 2008, 17:26 GMT
Opened by Andrea Benazzo (benazzo) - Friday, 05 October 2007, 09:46 GMT
Last edited by Aaron Griffin (phrakture) - Monday, 04 February 2008, 17:26 GMT
|
Details
The code '/usr/bin/mpd --kill /etc/mpd.conf &>
/dev/null' in /etc/rc.d/mpd in the stop function does not
work.
Instead use this: '/usr/bin/mpd --kill &> /dev/null' Thanks. |
This task depends upon
Closed by Aaron Griffin (phrakture)
Monday, 04 February 2008, 17:26 GMT
Reason for closing: Works for me
Additional comments about closing: Unable to reproduce. Upstream bug
Monday, 04 February 2008, 17:26 GMT
Reason for closing: Works for me
Additional comments about closing: Unable to reproduce. Upstream bug
1) after a clean start, the pid file is correctly created and contains the correct pid of the new running mpd daemon.
2) with my little modification in the stop function in /etc/rc.d/mpd, the pid file is correctly deleted
uhm..I've just tried to stop the daemon with the standard rc.d/mpd script, and the daemon correctly closes down, and the pid file gets deleted as well.
I don't understand why this works now, but I do remember that this morning I tried a couple of times before posting this bug, and I could start the daemon, but I could only close it via `killall mpd` or my modificated rc.d/mpd. It failed whenever I used the standard rc.d/mpd script.
Mpd logs show nothing unusual.
In that case mpd hanged when I added some files to playlist with gmpc, then it didn't want to start even after kill -9 all mpd processes, removing playlist, regenerating db and making sure no pid/lock/etc. files exist - only after system rebooting it started to work.
So I think that's mpd's mainstream bug.