Bugzilla – Bug 14451
New install of Squeezebox Server 7.4 on ReadyNAS NV+ creates 2 instances of SBS
Last modified: 2009-10-13 17:36:29 UTC
A fresh install (i.e. removed old version, cleaned database) of final release 7.4 of Squeezebox SErver creates 2 instances of Squeezebox Server running on my ReadyNAS NV+ (RAIDiator 4.1.6 + 1GB RAM). Excerpt from error log: [09-09-30 12:49:14.5904] main::init (320) Starting Squeezebox Server (v7.4.0, r28672, Mon Sep 28 17:51:03 PDT 2009) perl 5.008008 [09-09-30 12:49:22.1474] Slim::Networking::UDP::init (39) FATAL: There is already another copy of the Squeezebox Server running on this machine. (Address already in use) [09-09-30 12:49:22.1567] Log::Log4perl::Logger::and_die (868) Warning: FATAL: There is already another copy of the Squeezebox Server running on this machine. (Address already in use) at /usr/share/squeezeboxserver/lib/Log/Log4perl/Logger.pm line 900 2009-09-30 12:49:22 Squeezebox Server died. Restarting. [09-09-30 12:49:57.5653] main::init (320) Starting Squeezebox Server (v7.4.0, r28672, Mon Sep 28 17:51:03 PDT 2009) perl 5.008008 [09-09-30 12:50:07.3429] Slim::Networking::UDP::init (39) FATAL: There is already another copy of the Squeezebox Server running on this machine. (Address already in use) .. etc. My temporary solution (taken from another user in the forum) was to rename /etc/rc3.d/S20squeezeboxserver to /etc/rc3.d/s20squeezeboxserver
Simon: did you reboot the NAS between the remove commands?
(In reply to comment #1) > Simon: did you reboot the NAS between the remove commands? Yes, I ran mv /etc/rc3.d/S20squeezeboxserver /etc/rc3.d/s20squeezeboxserver and then rebooted.
Can you verify the instructions here function http://wiki.slimdevices.com/index.php/Upgrading_to_7.4 or are these broken as well
(In reply to comment #3) > Can you verify the instructions here function > > http://wiki.slimdevices.com/index.php/Upgrading_to_7.4 > > or are these broken as well No they didn't function .. in my case. I followed them exactly (removed 7.3.3, cleaned database, installed 7.4) and, after a reboot, there were 2 instances of the server running. Other users have experienced this too .. see forum topic: http://forums.slimdevices.com/showthread.php?t=68524
Michael, Sam tells me that Justin at ReadyNAS is in the office today and perhaps can lend us a hand.
== Auto-comment from SVN commit #28710 to the slim repo by michael == == https://svn.slimdevices.com/slim?view=revision&revision=28710 == Fixed Bug: 14451 Description: don't restart squeezeboxserver_safe if it's already running
This isn't really fixed. It does work in some cases, but not always. Justin - is there any documentation or could you briefly explain to me how services are started on the ReadyNAS? How come it would launch the /etc/init.d/squeezeboxserver twice?
Justin - as discussed in your forums (and mentioned in ours too) there's a /etc/rc3/S20squeezeboxserver, of which nobody knows how it got there. But it is indeed responsible for the double start. Do you have an idea what could have created it? I waded through all our changes since before the product name change (squeezeboxserver used to be squeezecenter until July/August). But I couldn't find anything which might have created that link.
== Auto-comment from SVN commit #28757 to the slim repo by michael == == https://svn.slimdevices.com/slim?view=revision&revision=28757 == Bug: 14451 Description: remove /etc/rc3/S20squeezeboxserver, remove my previous attempt to prevent double startup. The entry in /etc/rc3 caused SBS to be started too early. The frontview initialization would ignore it and start another instance.
== Auto-comment from SVN commit #28758 to the slim repo by michael == == https://svn.slimdevices.com/slim?view=revision&revision=28758 == Bug: 14451 Description: fix typo
It would have to be the .deb package installation that put the startup link there. We start addons once the network is up. The startup script to run is specified in /etc/frontview/addons/addons.conf. BTW, I don't think the startup script should restart SBS when you issue a start. Normal behavior would be to start if it isn't already running. I'll attach a startup script that, at least on my box, won't start duplicate SBS instances.
Created attachment 5987 [details] Init script
To me, it looks like the problem comes from the squeezeboxserver.postinst script, which calls "update-rc.d squeezeboxserver defaults >/dev/null". The update-rc.d command manual says that using the "defaults" keyword will create S20* scripts for runlevels 2,3,4 and 5, and K20* scripts for runlevels 0,1 and 6. Given ReadyNAS plugins don't get started/stopped the standard Debian way, but through Frontview's own mechanism, I suggest removing the call to the "dh_installinit" command in the Debian's "rules" file when building the Debian package for the ReadyNAS.
Created attachment 5989 [details] Patch for the rules file Here's a proposed patch.
Created attachment 5991 [details] Patch for the squeezeboxserver.postrm file This patch to the postrm file should ensure the older rcX.d links get removed.
Created attachment 5992 [details] Patch for the squeezeboxserver.postinst file Should have been targeted to postinst rather than postrm, so that the RC links get removed even when we're just upgrading...
output from command on my nas showing old squeezecenter directories lying around: home_nas:~# find /etc /usr /sbin /var -name '*squeezecenter*' /etc/default/squeezecenter /etc/init.d/squeezecenter /etc/init.d/squeezecenter.dpkg-dist /etc/squeezecenter /usr/share/doc/squeezecenter-readynas /usr/share/doc/squeezecenter /usr/share/squeezeboxserver/HTML/Default/html/images/squeezecenter.gif /usr/share/squeezeboxserver/HTML/EN/html/images/ServiceProviders/squeezecenter.p ng /usr/share/squeezecenter /usr/share/squeezecenter/HTML/Default/html/images/squeezecenter.gif /usr/share/squeezecenter/HTML/EN/html/images/ServiceProviders/squeezecenter.png /var/lib/dpkg/info/squeezecenter-readynas.conffiles /var/lib/dpkg/info/squeezecenter-readynas.list /var/lib/dpkg/info/squeezecenter-readynas.md5sums i think i removed the dir under /var/log earlier...
Okay, I understand the issue, so I'll try to make it as clear as possible: Squeezebox Server comes as a Frontview plugin for the ReadyNAS units. Frontview uses its own scripts (namely /etc/rc3.d/S99rc3, /etc/rc0.d/K99powerdown and /etc/rc6.d/S99reboot) to start and stop services related to plugins, and is as such normally responsible for starting up and shutting down Squeezebox Server. The problem is that the SBS 7.4.0 addon also installs - by the mean of the squeezeboxserver debian archive it comes with - its own initialization scripts on the system. One of them, causing most of the hassle, is /etc/rc3.d/S20squeezeboxserver. The way UNIX systems work at boot time, the S20squeezeboxserver script is called before the S99rc3 one, and launches a first instance of Squeezebox Server. But, since the MySQL database server is not already started at this time (it will be launched later by the S99rc3 script), this first instance of Squeezebox Server may not be working properly (in my very own case, SBS was running, but didn't give me access to my local library). I think unavailability of the database made 7.3.3 dying, but I'm not sure anymore. Later, when the S99rc3 is called by the system, the MySQL database server is started and another instance of Squeezebox Server is launched. But this second SBS instance detects that another process is using the network ports normally used by the service (indeed, the first SBS instance is using them), and aborts (because it requires these ports to operate correctly). Because SBS is started through a "watchdog"-like script, the second SBS instance is restarted immediately, dies again because the network port are still used by the first instance, is restarted, dies ... over and over. This is what happens if you reboot your ReadyNAS. Now, deleting the S20squeezeboxserver (or renaming it to s20squeezeboxserver) prevents the first SBS instance to be started, and let the one started by Frontview bind the network ports. It's not clear to me whether/why some people had problems when no reboot was involved. As said in another post, upgrade from 7.3.3 to beta 7.4.0 went fine for me, and SBS worked like a charm... until I rebooted my ReadyNAS. What's next? I attached 2 patches to the bug report: - the first one should prevent future SBS addon builds from installing its own initialization scripts (the S20squeezeboxserver thingies) - the second one should, when the newer release of the addon (that doesn't come with these initialization scripts) is installed, take care of removing the ones that may have been installed previously Testing is needed (I don't have all the tools required to roll my own ReadyNAS build and try it on my NV+), but I'm quite confident these patches should help (or at least give good clues for) solving the problems. Other oddities would also need to be understood/corrected, like the fact that - although the SBS debian package declares it replaces and conflicts with SC - some SqueezeCenter file are still present after the SBS addon installation.
(In reply to comment #11) > BTW, I don't think the startup script should restart SBS when you issue a > start. Normal behavior would be to start if it isn't already running. I'll > attach a startup script that, at least on my box, won't start duplicate SBS > instances. By the use of Debian's start-stop-daemon, the legacy /etc/init.d/squeezeboxserver script already takes care of that: the PID of the SBS process is stored in the /var/run/squeezeboxserver.pid file, and the start-stop-daemon command wouldn't start another instance if the PID referenced in this file referred to a running process. But Netgear's S99rc3 init script ashamedly* removes any file in /var/run when it's launched, ruining the start-stop-daemon's controls. * I say "ashamedly" because Netgear's script is probably the last script called in the boot process, and such cleaning up should only be done at the very beginning of it. IMHO, the squeezeboxserver shouldn't be changed, it already does well its job. You probably won't make Netgear change their mind on how a UNIX system is supposed to work, so don't count on them for moving the /var/run directory cleaning code somewhere it won't hurt other processes. So, you're only left with ensuring SBS won't start on the ReadyNAS before it's supposed to (ie through the S99rc3 addon initialization scripts).
Created attachment 6001 [details] Patch for the postrm file Added a patch for the package's postrm file: on the ReadyNAS systems, SBS runs as root.
Created attachment 6002 [details] Patch for the control file Sorry, last patch was not for the postrm file, but for the control file. It's needed to also replace/conflict with the squeezecenter-readynas package, otherwise the older SC package is left behind: barney:~# dpkg -l 'squeeze* 'Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-================================-================================-=========================== ii squeezeboxserver 7.4.0 Streaming Audio Server un squeezecenter <none> (no description available) ii squeezecenter-readynas 7.3.3 Streaming Audio Server
Created attachment 6003 [details] Patch for the postrm file And here is the patch for the postrm file. It wouldn't hurt to try to delete the squeezeboxserver user, but it's not necessary.
While I'm thinking about it, it may be necessary to kill SBS remaining processes (the one that had been called by the S20squeezeboxserver script) at update time. Could be done either in the install.sh or the postinst files. Sorry, I won't be able to offer any more help this week, as I'm away from my NV+ and beloved Squeezebox. Good luck, chaps!
== Auto-comment from SVN commit #28775 to the slim repo by michael == == https://svn.slimdevices.com/slim?view=revision&revision=28775 == Bug: 14451 Description: apply a series of patches by S?\195?\169bastien Ph?\195?\169lep to clean up the ReadyNAS installation. Thanks a lot for your work on this topic!
Thanks to S�bastien's effort this seems to be fixed now. Brought my system in a badly broken state by installing 7.3.x, then a few of the early SC/SBS 7.4 builds until it wouldn't start any more or start two instances. Then I installed the latest 7.4.1 build, rebooted the machine - running fine.
Tested 7.4.1 on all platforms and it seems to run smoothly. Marking bug as verified. Please re open if you see this issue against 7.4.1