Hi!
The mpd initscript silently fails to stop mpd (returns with exit
status 0 but mpd is still running):
christoph@mitoraj {3} ~
16:44 0 % sudo service mpd stop
[ ok ] Stopping Music Player Daemon: mpd.
christoph@mitoraj {3} ~
16:44 0 % ps auxf | grep mpd
mpd 1816 0.3 0.1 300796 11468 ? Ss 14:36 0:26 /usr/bin/mpd /etc/mpd.conf
1000 18185 0.0 0.0 9084 1540 ? S+ 16:44 0:00 | \_ grep mpd
christoph@mitoraj {3} ~
16:44 0 % sudo bash -x /etc/init.d/mpd stop
+ . /lib/lsb/init-functions
+++ run-parts --lsbsysinit --list /lib/lsb/init-functions.d
++ for hook in '$(run-parts --lsbsysinit --list /lib/lsb/init-functions.d 2>/dev/null)'
++ '[' -r /lib/lsb/init-functions.d/20-left-info-blocks ']'
++ . /lib/lsb/init-functions.d/20-left-info-blocks
++ FANCYTTY=
++ '[' -e /etc/lsb-base-logging.sh ']'
++ true
+ PATH=/sbin:/bin:/usr/sbin:/usr/bin
+ NAME=mpd
+ DESC='Music Player Daemon'
+ DAEMON=/usr/bin/mpd
+ MPDCONF=/etc/mpd.conf
+ START_MPD=true
+ '[' -x /usr/bin/mpd ']'
+ '[' -r /etc/default/mpd ']'
+ . /etc/default/mpd
++ START_MPD=true
+ '[' -n '' ']'
+ '[' '!' -d /var/run/mpd ']'
++ sed -n 's/^[[:space:]]*db_file[[:space:]]*"\?\([^"]*\)\"\?/\1/p' /etc/mpd.conf
+ DBFILE=/var/lib/mpd/tag_cache
++ sed -n 's/^[[:space:]]*pid_file[[:space:]]*"\?\([^"]*\)\"\?/\1/p' /etc/mpd.conf
+ PIDFILE=/var/run/mpd/pid
+ case "$1" in
+ mpd_stop
+ '[' true '!=' true ']'
+ '[' -z /var/run/mpd/pid ']'
+ log_daemon_msg 'Stopping Music Player Daemon' mpd
+ '[' -z 'Stopping Music Player Daemon' ']'
+ log_daemon_msg_pre 'Stopping Music Player Daemon' mpd
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ '[' -t 1 ']'
+ '[' xrxvt-unicode-256color '!=' x ']'
+ '[' xrxvt-unicode-256color '!=' xdumb ']'
+ '[' -x /usr/bin/tput ']'
+ '[' -x /usr/bin/expr ']'
+ /usr/bin/tput hpa 60
+ /usr/bin/tput setaf 1
+ '[' -z ']'
+ FANCYTTY=1
+ case "$FANCYTTY" in
+ true
+ /bin/echo -n '[....] '
[....] + '[' -z mpd ']'
+ /bin/echo -n 'Stopping Music Player Daemon: mpd'
Stopping Music Player Daemon: mpd+ log_daemon_msg_post 'Stopping Music Player Daemon' mpd
+ :
+ start-stop-daemon --stop --quiet --oknodo --retry 5 --pidfile /var/run/mpd/pid --exec /usr/bin/mpd
+ log_end_msg 0
+ '[' -z 0 ']'
+ local retval
+ retval=0
+ log_end_msg_pre 0
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ '[' -t 1 ']'
+ '[' xrxvt-unicode-256color '!=' x ']'
+ '[' xrxvt-unicode-256color '!=' xdumb ']'
+ '[' -x /usr/bin/tput ']'
+ '[' -x /usr/bin/expr ']'
+ /usr/bin/tput hpa 60
+ /usr/bin/tput setaf 1
+ '[' -z 1 ']'
+ true
+ case "$FANCYTTY" in
+ true
++ /usr/bin/tput setaf 1
+ RED=''
++ /usr/bin/tput setaf 2
+ GREEN=''
++ /usr/bin/tput setaf 3
+ YELLOW=''
++ /usr/bin/tput op
+ NORMAL=''
+ /usr/bin/tput civis
+ /usr/bin/tput sc
+ /usr/bin/tput hpa 0
+ '[' 0 -eq 0 ']'
+ /bin/echo -ne '[ ok '
[ ok + /usr/bin/tput rc
+ /usr/bin/tput cnorm
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ '[' -t 1 ']'
+ '[' xrxvt-unicode-256color '!=' x ']'
+ '[' xrxvt-unicode-256color '!=' xdumb ']'
+ '[' -x /usr/bin/tput ']'
+ '[' -x /usr/bin/expr ']'
+ /usr/bin/tput hpa 60
+ /usr/bin/tput setaf 1
+ '[' -z 1 ']'
+ true
+ case "$FANCYTTY" in
+ true
++ /usr/bin/tput setaf 1
+ RED=''
++ /usr/bin/tput setaf 3
+ YELLOW=''
++ /usr/bin/tput op
+ NORMAL=''
+ '[' 0 -eq 0 ']'
+ echo .
.
+ log_end_msg_post 0
+ :
+ return 0
Because the mpd package is missing from the Wheezy archives, I built 0.16.7 today on a fresh Wheezy amd64 install, using the source package and building with debian/rules binary. This problem is not present in 0.16.7 as packaged for Wheezy, so it's a regression in 0.16.8.
Hi Christoph, are you able to reliably reproduce that, even after a reboot? Your trace shows that start-stop-daemon returns with exit status 0, so either it did what it was supposed to do (unlikely), or there was nothing for it to do, e.g. because the pid didn't match the process. Could you please dig a little deeper, and check that the content of /var/run/mpd/pid matches the pid of the running mpd instance? Or run the start-stop-daemon command directly, changing --quiet to --verbose? My suspicion is that something external messed with mpd's pidfile (tmpfs mounted over /var/run after mpd was started?), but this doesn't have anything to do with mpd's initscript, which hasn't changed since 0.16.2-1. Florian
This bug was tagged "moreinfo" without reply for close to three months, and I believe it originated in some mess unrelated to mpd, as explained in my last message in February. Hence, I'm closing it now. Florian
Hi!
Still seeing, th pid file appears to be correct
christoph@mitoraj {1} ~
10:23 0 % ps aux | grep 2200
1000 7219 0.0 0.0 9108 1564 ? S+ 10:23 0:00 grep 2200
mpd 2200 0.0 0.1 233332 11240 ? Ss 10:05 0:00 /usr/bin/mpd /etc/mpd.conf
christoph@mitoraj {1} ~
10:23 0 % cat /run/mpd/pid
2200
christoph@mitoraj {1} ~
10:23 0 % sudo service mpd stop
[ ok ] Stopping Music Player Daemon: mpd.
christoph@mitoraj {1} ~
10:24 0 % ps aux | grep 2200
1000 7344 0.0 0.0 9108 1564 ? S+ 10:24 0:00 grep 2200
mpd 2200 0.0 0.1 233332 11240 ? Ss 10:05 0:00 /usr/bin/mpd /etc/mpd.conf
Christoph
Hi Christoph, could you debug this a little more please? E.g. run 'sudo bash -x /etc/init.d/mpd stop' again. If that contains the correct call to start-stop-daemon, like + start-stop-daemon --stop --quiet --oknodo --retry 5 --pidfile /run/mpd/pid --exec /usr/bin/mpd + log_end_msg 0 then both initscript and pitfile are correct and I have no idea what start-stop-daemon thinks it's doing... Any other ideas what may be special in your case? And I suppose you've upgraded from 0.16.8-1 to 0.17.4-3 in the meantime? Florian
Hi!
Just noticed: stopping mpd works fine *unless* it's during the
upgrade. I'll look into it.
Christoph
Some more information:
--
christoph@mitoraj {1} ~
23:25 0 % sudo start-stop-daemon --stop --oknodo --retry 5 --pidfile /run/mpd/pid --exec /usr/bin/mpd
No /usr/bin/mpd found running; none killed.
christoph@mitoraj {1} ~
23:25 0 % ps auxf | grep mpd
1000 5772 0.0 0.0 9108 1548 ? S+ 23:25 0:00 \_ grep mpd
mpd 4657 0.0 0.1 365148 15628 ? Ss 23:24 0:00 /usr/bin/mpd /etc/mpd.conf
christoph@mitoraj {1} ~
23:25 0 % cat /run/mpd/pid
4657
--
Wild guess:
start-stop-daemon on bsd acting weird iff the actual binary on
/usr/bin/mpd (--exec) is not the same (inode-wise) as the running
one.
Open question:
Why does it work on linux just fine / is only mpd breaking on *kbsd
Hi! Yeah the problem here is on s-s-d. The /proc/<PID>/exe and other native equivalent implementations on BSDs do not give anything meaningful when the inode has been removed, and as it stands s-s-d uses the Linux method on kFreeBSD. We noticed this last year (see #652575, CCed to debian-bsd), and I played with different methods, but there's currently no way to retrieve the exec path from a process whose executable has been removed (not even with sysctl KERN_PROC_PATHNAME, only Linux and HPUX seem to have sane interfaces for this). I'll recheck my notes to make sure though. Handling this was on my TODO for dpkg 1.17.x, and I guess I'll have to switch the --exec option on kFreeBSD to use the KVM method, which is unfortunately based on the process argv... If someone has some other idea, I'm happy to evaluate it and implement it for s-s-d. Thanks, Guillem
It seems like the position of upstream FreeBSD is that, once a file is opened, its name is basically lost or unreliable. Going from a vnode in-kernel to a name is provided on a "best-effort" basis based on what's in the namecache, but is explicitly not a robust/supported interface and is allowed to fail. Whether the file in question is being executed as a process binary is not relevant. If I am reading #699208 and #652575 correctly, the --exec option is approximately the only option.
reassign 699208 dpkg 1.16.10 retitle 699208 start-stop-daemon on kFreeBSD fails to stop mpd on upgrade thanks hence reassigning from mpd to dpkg Florian
kFreeBSD has been removed from Debian ports: https://lists.debian.org/debian-bsd/2023/07/msg00003.html cu Adrian
Control: reopen -1 Control: retitle -1 s-s-d: On kFreeBSD fails to find deleted exec filename This report is still a valid problem on any kFreeBSD system, including stock FreeBSD, which dpkg is intended to be supported on. Regards, Guillem