Bug 15523 - Fedora & like OSs, SBS 7.4.1 and above: squeezeboxserver service cannot be stopped or restarted after a 'internal' restart
: Fedora & like OSs, SBS 7.4.1 and above: squeezeboxserver service cannot be st...
Status: RESOLVED DUPLICATE of bug 17729
Product: Logitech Media Server
Classification: Unclassified
Component: Misc
: 7.4.1
: PC Fedora
: -- minor with 1 vote (vote)
: Investigating
Assigned To: Unassigned bug - please assign me!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-01-23 15:22 UTC by Gordon Harris
Modified: 2011-11-16 22:05 UTC (History)
1 user (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gordon Harris 2010-01-23 15:22:13 UTC
After a normal squeezeboxserver service start, ps ax shows the process as:

/usr/bin/perl -w /usr/libexec/squeezeboxserver --daemon ..etc.

A 'service squeezeboxserver restart' succeeds.

However, if one restarts the service 'internally', i.e. from the extension downloader or via a [restartserver] cli request, ps ax now shows the running process as:

/usr/bin/perl /usr/libexec/squeezeboxserver --daemon ..etc.

..in other words, the "-w" parameter is now missing.  Without the "-w", /etc/init.d/squeezeboxserver can't stop or restart the service, giving a "[FAILED]" error message.
Comment 1 Gordon Harris 2010-01-23 15:43:47 UTC
Looking at the 7.5 embedded svn code, in server/slimserver.pl, line 1048:

sub stopServer {
	my $restart = shift;

	logger('')->info( 'Squeezebox Server ' . ($restart ? 'restarting...' : 'shutting down.') );
	
	$::stop = 1;
	
	cleanup();
	
	if ($restart 
		&& Slim::Utils::OSDetect->getOS()->canRestartServer() 
		&& !main::ISWINDOWS)
	{
		exec($^X, $0, @argv);
	}

	exit();
}

I'm not sure what effect adding a '-w' argument to that exec call would have on other OSs, e.g. OSX, etc.  On the other hand, the /etc/init.d/squeezeboxserver script doesn't explicitly call 'perl -w', but rather 'daemon' which apparently defaults to 'perl -w' for any .pl script, so this can't really be fixed in the service script.
Comment 2 Gordon Harris 2010-01-26 22:02:44 UTC
Duh.  Look at the top of the file and think before you speak next time, Gordon.
Comment 3 Chris Owens 2010-03-04 18:09:05 UTC
I'm not linuxy enough to interpret your last comment, Gordon.  Is the fix clear, or not needed?
Comment 4 Gordon Harris 2010-03-05 08:28:29 UTC
I assume that Andy fixed this in the 'ssvn r29923 -- Don't run with -w warning flag' change, though I haven't tested this to see if it solves the problem.  On the face of it, it ought to.  

I asked if svn 29923 was made in response to this bug, but never got an answer.  See: http://forums.slimdevices.com/showthread.php?t=74552
Comment 5 Chris Owens 2010-03-05 16:21:17 UTC
Since you're the only one interested in this bug (apparently) I'll just leave it to you for now.  :)
Comment 6 Gordon Harris 2010-03-05 16:44:30 UTC
OK.  I'll test and, if svn r29923 has fixed it, I'll close the bug.
Comment 7 Alan Young 2011-11-06 23:24:49 UTC
Unassigned bugs cannot have a priority.
Comment 8 Gordon Harris 2011-11-08 22:03:49 UTC
I don't know how long it will take for other rpm-based distros to transition to using systemd for service control, but with Fedora 15 (& 16) this bug's problem can be solved by using a service unit file, rather than a startup script.

e.g. /lib/systemd/system/lms.service:
=================================================================
[Unit]
Description=Logitech Media Server Daemon
After=local-fs.target network.target

[Service]

ExecStart=/usr/share/lms/server/slimserver.pl --daemon --pidfile=/run/lms.pid --user=lms --group=lms --prefsdir=/var/lib/lms/prefs --logdir=/var/log/lms --cachedir=/var/lib/lms/cache --charset=utf8

Type=simple

PIDFile=/run/lms.pid

RestartSec=5

Restart=on-failure


[Install]
WantedBy=multi-user.target
Alias=logitechmediaserver
=================================================================
Comment 9 Michael Herger 2011-11-16 22:05:14 UTC
bug 17729 has a good analysis of this issue

*** This bug has been marked as a duplicate of bug 17729 ***