When `/etc/init.d/squeezeboxserver restart' is issued when the service is running the following output is displayed: * Stopping Squeezebox Server ... * Starting Squeezebox Server ... /usr/bin/perl already running. * Failed to start Squeezebox Server This appears that the init script is trying to restart the service before it has been fully stopped leading to it failing to restart properly. A simple fix for the issue is to insert the line `sleep 1' after the start-stop-daemon command in the stop function of the init script, but there may be a better way to solve the problem.
I'd prefer a more deterministic method than using sleep, if we can do it.
(In reply to comment #1) > I'd prefer a more deterministic method than using sleep, if we can do it. Yeah, I would too. That's what I meant when I said there may be a better way. :)
Created attachment 245013 [details] Proposed replacement init script Yep - I think there's a bug in the init script as I can reproduce that with my ~x86 test system. Could you try the attached replacement for /etc/init.d/squeezeboxserver and see if that helps? If that's OK I'll need to test with a stable system to make sure that script works with both.
(In reply to comment #3) > Created an attachment (id=245013) [details] > Proposed replacement init script > > Yep - I think there's a bug in the init script as I can reproduce that with my > ~x86 test system. Could you try the attached replacement for > /etc/init.d/squeezeboxserver and see if that helps? Doesn't work for me. Now getting something similar to the following output: * Stopping Squeezebox Server ... [ ok ] * Starting Squeezebox Server ... * start-stop-daemon: /usr/bin/perl is already running * Failed to start Squeezebox Server [ !! ] * ERROR: squeezeboxserver failed to start
(In reply to comment #4) > (In reply to comment #3) > > Created an attachment (id=245013) [details] [details] > > Proposed replacement init script > > > > Yep - I think there's a bug in the init script as I can reproduce that with my > > ~x86 test system. Could you try the attached replacement for > > /etc/init.d/squeezeboxserver and see if that helps? > > Doesn't work for me. Now getting something similar to the following output: > > * Stopping Squeezebox Server ... [ ok ] > * Starting Squeezebox Server ... > * start-stop-daemon: /usr/bin/perl is already running > * Failed to start Squeezebox Server [ !! ] > * ERROR: squeezeboxserver failed to start > Sorry that's not helping - it made a difference on my test system. Could you post the output of "emerge --info" and I'll see if I can reproduce that in a similar setup?
Here's my emerge --info. Portage 2.1.8.3 (default/linux/x86/10.0, gcc-4.4.3, glibc-2.11.2-r0, 2.6.34-gentoo-r1 i686) ================================================================= System uname: Linux-2.6.34-gentoo-r1-i686-AMD_Athlon-tm-_Processor-with-gentoo-1.12.13 Timestamp of tree: Fri, 20 Aug 2010 03:20:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 4.0_p37 dev-lang/python: 2.6.5-r3, 3.1.2-r4 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 1.12.13 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.65 sys-devel/automake: 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.3-r2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b sys-devel/make: 3.81-r2 virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="x86" ACCEPT_LICENSE="* -@EULA" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -march=athlon -pipe" DISTDIR="/var/gentoo/distfiles" FEATURES="assume-digests ccache distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch userpriv usersandbox" GENTOO_MIRRORS="http://gentoo.osuosl.org/ http://gentoo.mirrors.tds.net/gentoo" LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="en en_US" MAKEOPTS="-j2" PKGDIR="/var/gentoo/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/var/gentoo/repositories/gentoo" PORTDIR_OVERLAY="/var/gentoo/repositories/radhermit" SYNC="rsync://rsync21.us.gentoo.org/gentoo-portage" USE="3dnow aac acl berkdb bzip2 caps clamav cli cracklib crypt cups cxx dri encode fam ffmpeg flac fortran gdbm gmp iconv imap ipv6 kerberos ldap logrotate mad mmx mmxext modules mudflap ncurses nls nptl nptlonly ogg openmp pam pcre perl pppd python readline reflection sasl session spl ssl sysfs syslog tcpd threads unicode vhosts vim-syntax vorbis x86 xorg zlib zsh-completion" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en en_US" RUBY_TARGETS="ruby18" USERLAND="GNU" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 245558 [details] Another proposed update to init script You're using baselayout-1 - I can't reproduce that problem on my baselayout-1 system (which is also using sys-apps/baselayout-1.12.13), but it may be that your system is much faster than mine because I'm using a virtual machine. I've looked into it a bit, though, and think it might be a problem with the 'stop' action not waiting for the daemon to exit. I've attached an updated init script - could you give this a try and see if it helps? The difference is the 'retry' parameter to start-stop-daemon when stopping, I believe that without that it does't wait at all.
(In reply to comment #7) > I've looked into it a bit, though, and think it might be a problem with the > 'stop' action not waiting for the daemon to exit. I've attached an updated init > script - could you give this a try and see if it helps? The difference is the > 'retry' parameter to start-stop-daemon when stopping, I believe that without > that it doesn't wait at all. It doesn't work for me with the new changes. I get the following output: * Stopping Squeezebox Server ... * Failed to stop Squeezebox Server [ !! ] * ERROR: squeezeboxserver failed to stop At this point, the squeezeboxserver process has exited, but the init.d service status still thinks it's running. Therefore, calling start, stop, or restart all fail. I have to zap the service in order to restart it.
(In reply to comment #8) ... > > At this point, the squeezeboxserver process has exited, but the init.d service > status still thinks it's running. Therefore, calling start, stop, or restart > all fail. I have to zap the service in order to restart it. > It seems like the "start-stop-daemon -o" option is deprecated. This option should have taken care of the situation where the pid-file points to a process no longer existing. Is there maybe a replacement for the -o option that anyone knows about?
> > Is there maybe a replacement for the -o option that anyone knows about? > I simply replaced: start-stop-daemon -o --stop --pidfile ${pidfile} with: start-stop-daemon --stop --pidfile ${pidfile} echo "" The echo part is just something that should return 0 when all is good
All along I thought it was just me/my system! Anyway, I changed the init script to: stop() { ebegin "Stopping Squeezebox Server" start-stop-daemon --stop --retry 10 --pidfile ${pidfile} eend $? "Failed to stop Squeezebox Server" } And stop / start works for me. This has been a long standing issue. I really don't care about a proper restart, but manual kill and "zap" at the daemon are inconvenient.
I just started seeing stop fail after going to openrc. Can those who are having the problem say whether they are using openrc yet? Stuart, if this is openrc-related, we should see if we can come up with a global solution, if possible. I'll be glad to test any proposed solution on openrc if you do not have it.
(In reply to comment #12) > I just started seeing stop fail after going to openrc. Can those who are > having the problem say whether they are using openrc yet? I think I was using openrc when I first reported the bug.
(In reply to comment #13) > (In reply to comment #12) > > I just started seeing stop fail after going to openrc. Can those who are > > having the problem say whether they are using openrc yet? > > I think I was using openrc when I first reported the bug. I'm using openrc as well, and have been since I started using squeezebox.
I'm just looking at releasing an updated ebuild for 7.5.4 (bug#365307). Now that OpenRC has gone stable I should be able to reproduce this and get this one fixed as well.
Joe, I believe I have resolved this in the ebuild for 7.5.4; this is currently in my github: https://github.com/hickinbottoms/squeezecenter-ebuild-for-gentoo/tree/7.5.4 The pertinent changes are in the squeezeboxserver.init.d script - I've only tested this with baselayout-2 and therefore I've added a DEPEND line for baselayout-2.
Committed 7.5.4. Thanks, Stuart! I think it's fine to depend on baselayout-2, especially since it is marked stable now for x86 and amd64. BTW, I do not depend on it for prefix, since they have a different baselayout. I am not sure how the stop process works with prefix, but I have not seen any bugs with it. We'll see if there are complaints on either of these fronts.
