Bugzilla – Bug 12805
Windows service, Perl code, fails to start with --httpport
Last modified: 2009-09-23 04:04:41 UTC
Odd problem... I believe this began about 6/29 or 6/30. I'm running the perl source code as a Windows service using srvany. The server fails to start, with no log produced and no Windows Event log errors whenever the -httpport command line option is used. When it's removed the service starts up normally; it doesn't matter which port number is set. Here's the command used to start: "C:\Perl5.10\bin\perl.exe" "C:\Program Files\Squeezebox Server 7.4 SQLite\server\slimserver.pl" --playeraddr 192.168.9.11 --cliaddr 192.168.9.11 --streamaddr 192.168.9.11 --httpaddr 192.168.9.11 --httpport 80 --prefsdir "D:\slim\11\prefs" --cachedir "D:\slim\11\cache" --logdir "D:\slim\11\logs" Eliminating the --httpport option from the command shown above allows the service to start up. The two odd things are: 1) the --httport option still works when slimserver.pl is run from the command line as a user process, and 2) you can still set a different http port in either the web interface or by editing server.prefs directly and it works fine. I haven't yet tested the compiled EXE run as a Windows service. I'll try that later to see what happens.
I've verified that the --httpport option works as expected when the compiled EXE is run as a Windows service.
Andy: is this one yours to investigate or Matt Wise?
Probably not a high priority, as I'm only seeing it when running the Perl code, not the EXE.
Does the same thing happen with current 7.4 trunk?
Yes, same thing with the merged 7.4 trunk. What I've done as workaround is just remove the command-line option, since once it's set it persists through the server.prefs file. The command-line options can be finicky when run as a Windows service. Michael has been through troubleshooting some others. Bug 7491 is an old one where --prefsdir doesn't work when the EXE (but not the Perl code) is run as a Windows service.
Jim - I found some pages which say you could redirect stdout to some file using srvany's AppParameters value. Did you ever try that? Lowering priority, as running the perl version on Windows as a service using srvany seems like a one in a few thousands configuration.
One more thing - do you see the same in the current trunk? As most of the sqlite branch changes have been merged to trunk, I would expect this. Please change subject appropriately. Thanks.
(In reply to comment #7) > One more thing - do you see the same in the current trunk? Yes, see comment #5. Subject changed.
Did you try to add output redirection (see comment #6)?
Just tried it and no luck. Tried to redirect stdout to a file, but the file isn't created.
I'm sorry to say that this is too exotic an issue to seriously target for any release soon. Please try to get some log which could help us understand what's going on. Thanks for your understanding.