Interesting issue with 6.5.2/nightly

[AubreyCTurnerJr]

I had a weird situation where whenever a friend of mine accessed my Slimserver remotely using iTunes and his browser it would for some reason turn the Squeezebox2 in my bedroom on and play the same thing as he was hearing. I was also seeing odd errors about missing strings in the log, so I decided to wipe everything and do a scratch install from the nightly build. I haven't always been careful to delete all the old plugins before upgrades, so I suspected the errors might be from old plugins.

Anyhow, after removing the previous installation of 6.5.1 and all the files in /usr/local/slimserver, I installed SlimServer_6.5_v2007-01-28.noarch.rpm.

Invoking the init.d startup script gave me the infamous permissions error that others have seen before:
mkdir /MySQL: Permission denied at /usr/local/slimserver/Slim/Utils/MySQLHelper.pm line 156

What caught my eye was the absolute path ("/MySQL"), which didn't seem right to me. I took a look at that code and determined that the code's intent is to create a "MySQL" subdirectory under the cache directory. However, the cache directory was set to "~" in the default version of /etc/slimserver.conf.

I'd purposely decided not to copy back my old slimserver.conf file and start from scratch, thinking that it would have sufficient defaults to get started.

I edited the file and set the cache directory to "/usr/local/slimserver/Cache" and Slimserver started and I was able to initialize it (i.e. get it to index my music collection and see all my Squeezeboxes).

Did I miss a step in the installation instructions where we were supposed to manually edit this file? Or is this an oversight in the default version of the file? FYI--I was using the Linux instructions in the Wiki.

Anyhow... it's working now so I can start adding back all my plugins and see if I can duplicate the weird remote streaming behavior.

[AubreyCTurnerJr]

After I wrote the above I got curious as to where that "~" was coming from. It appears to be coming from the default cache setting that is determined in Prefs.pm. It concatenates $ENV{'HOME'} and "Cache" to come up with a default value, and then does some checks to see if it exists, and if not, whether the parent is writeable. If the parent isn't writeable, it undef's the variable.

So it appeared to me that it wasn't properly picking up the value of the HOME variable. I created a simple two-line Perl script to determine what $ENV{'HOME'} evaluates to when invoked through the "startproc" command used on SuSE (the second line spits out the output of the "id" command for reference). Here's the output:



dominion:~ # /tmp/test.pl
HOME = /root
User = uid=0(root) gid=0(root) groups=0(root)

dominion:~ # startproc -u slimserver /tmp/test.pl
HOME = /root
User = uid=1008(slimserver) gid=1002(slimserver) groups=14(uucp),16(dialout),17(audio),33(video),10 02(slimserver)


So, for some reason it's not picking up the right HOME variable when invoked through startproc. Of course, I'm using an ancient version of SuSE (9.1 Professional) with Perl 5.8.3. I'm in the process of building a new server and will put openSuSE 10.2 on it. I'll watch to see if it makes a difference.

[AubreyCTurnerJr]

I did some more testing with this on an openSuSE 10.1 system and found that it has the same problem. It seems that startproc forks the new process using the caller's environment, even if it is starting as a new user (I confirmed this in the source for startproc as well).

So this means that under SuSE, invoking the init script from root will always cause HOME to be the HOME of root. This probably explains why I found a number of forum entries where people were having problems getting Slimserver to start after installation, since the SuSE init scripts all use startproc to invoke Slimserver under the Slimserver user.

So I began looking for a way to find the user's home directory without relying on the environment. The following code should work on Unix, but not on Windows (but I see that Prefs.pm checks for Unix, so it should be OK).

It uses getpwuid() (http://perldoc.perl.org/functions/getpwuid.html) to retreive the user's home directory, based on the UID ("$<") of the currently running user.



@uvals = getpwuid($<);
$dir = $uvals[7];
print ("Retreived home directory = ".$dir."\n");


Running the above in a Perl script invoked via startproc correctly gives the user's home directory based on the userid that startproc is told to use (i.e. if used with "-u slimserver" the output shows "/usr/local/slimserver" instead of "/root").

[AubreyCTurnerJr]

I filed bug report 4718 (http://bugs.slimdevices.com/show_bug.cgi?id=4718) just to get this documented as a possible issue for SuSE users.

[jackoo]

Thanks for the good debug job. The new Slimserver software works fine now on my server :-)

Greetz,
happy Jackoo

[AubreyCTurnerJr]

I'm glad that it was helpful. I posted it here in the hopes that someone would see it if they searched the forums for problems with SuSE.