Bugzilla – Bug 4688
MySQLHelper.pm gives permission problems in 6.5.1
Last modified: 2011-03-16 04:39:18 UTC
Although I have a 100% working 6.5.0 installation, installing 6.5.1 (either fresh, or an overlay over 6.5.0) produced the following error: mkdir /MySQL: Permission denied at /usr/local/slimserver/Slim/Utils/MySQLHelper.pm line 156 2007-01-19 20:05:19.3749 Use of uninitialized value in sprintf at /usr/local/slimserver/Slim/Utils/MySQLHelper.pm line 470. This error prevents slimserver from starting properly using the /etc/init.d/slimserver start command. Permissions are set appropriately to slimserver:slimserver in all the applicable slimserver software and utility directories. Additionally, the slimserver init.d script is started as root but specifies the --group slimserver and --user slimserver parameters. As a workaround/temporary fix, I discovered that simply copying the 6.5.0 version of MySQLHelper.pm over the 6.5.1 version of the script in the 6.5.1 installation eliminates the permissions problems and allows slimserver 6.5.1 to startup/run normally without any permissions issues. Please check out what MySQLHelper.pm is doing differently between versions to eliminate this problem/issue. Thank you, *Bradley
Bradly, please attach the requested log info as a reference. thank you.
Did some further research based on the prodding from KDF. I looked at the log information and noticed that perhaps the real problem seemed to stem from the startup not being able to find the correct pref file. By supplying the correct path to the pref file as kdf suggested, I was able to start up slimserver using either 6.5.0 or 6.5.1 version of the MySQLHelper. Thus, the permissions issue seems to be tied to something not available from the prefs file from the previous version. It also does not make sense to me why the path to the prefs file had to be specified in this new version. It might be helpful for changes such as this to be noted in the release notes.
Bradley, please provide the log info requested. Please try to avoid second guessing why it is needed, as coming up wiht your own conclusions that there is something done on the slimserver side in order to make things not work. Something is wrong on your system. This isn't an accusation, it is a simple, blameless fact. If you can provide the info requested, we can have some hope of perhaps finding a way to prevent the problem from being created in the future. If you refuse, then there is little to be done. The prefs file should not have to be specified on a proper install.
Created attachment 1779 [details] SS651 Startup Log (console capture) Without Specifying Prefs Location
Created attachment 1780 [details] SS651 Startup Log (console capture) Specifying Prefs Location
Attached are two log (console captures) files when running ./slimserver.pl --d_mysql --d_startup. One reproduces the error (by not specifying the location of the prefs file) The second includes an extra parm --prefs /etc/slimserver.prefs which allows slimserver to startup correctly.
when you run ./slimserver.pl manually, not specifying the prefs file will try to create a prefs file in ~, thus the reference to /root/slimserver.pref I'll reiterate that slimserver is NOT intended to run as root, and other processes will fail. The default location when running the system service init.d startup script is /etc/slimserver.pref, which as you know works when specified. From the details of the log, it appears that the /etc/slimserver.pref is set to use an existing mysqld, while the /root/slimserver.pref is trying to create a new instance. This, of course, fails as it does not have proper access to /root for it's config files. Is there a reason you are not running the server using /etc/init.d/slimserver start?
I always run via /etc/init.d/slimserver start. When I upgraded from 6.5.0 to 6.5.1. The init.d script wasn't starting slimserver. So I went to run it from ./slimserver.pl to see the errors on the console. That's also where I did the capture from. My init.d script is run as root by specifies --user and --group as "slimserver". As of the 6.5.0 version, that script did not need to specify a prefs file path, because the prefs file was in the default /etc/slimserver.pref location. As of 6.5.1, apparently an explicit path is necessary. I was able to prove this because my 6.5.0 version ran fine even alongside the 6.5.1 version whereas 6.5.1 would fail with the output you've seen.
Even if I did an su slimserver, the 6.5.1 version would not run. It would produce the same output. Only when I specified a prefs file explicitly (even though it was in the default location), could I get slimserver to run.
su won't help. as I said, silmserver is specifically set up NOT to be run as root. It sounds to me, that for your setup, the right action IS to include the prefs file in the command line. If, however, you want to use a startup script in init.d (you haven't answered my questions as to why you can't/won't/rather not) it should work without adding it. Most platforms have the prefs file included in the init.d startup too.
another note on the su/root issue: what IS odd here is that there are blocks that are supposed to give an error "cannot run as root" or similar. odd that those arent the first and last errors you get. that is, perhaps, what needs to be fixed.
Bradley, I don't suppose you have tried this with 7?
Alan speculates that this is due to
It is not clear why using the 6.5.0 version of MySQLHelper.pm with 6.5.1 should solve the problem. The OS version is not stated. It is clear that 6.5.1 included proper recognition of RH and Fedora Linux variants and dealt with the Prefs directory for these. This is almost-certainly the cause of the problem and, in general with a clean installation, this problem does not arise. If this reoccurs with 7.0 or further information is available then this should be reopened.