Bugzilla – Bug 4615
Running system mysql finds wrong errmsg.sys
Last modified: 2019-01-25 09:54:10 UTC
This has come up a few times on the forums recently, so I'll try to summarize it here... Slimserver includes a mysql binary for i386. For other architectures, it will usually be able to find the system's mysqld if it is installed. However, it will still look for errmsg.sys in the slimserver MySQL directory. If the system version of mysqld is close enough, it will just work. However, newer versions of mysqld (such as the ones in FC6 or Etch) expect more messages to be there. In this case, an error will be generated and mysqld and slimserver will fail to start. MySQLHelper.pm says: if (Slim::Utils::OSDetect::isDebian() || Slim::Utils::OSDetect::isRHELorFC()) { $config{'language'} = '/usr/share/mysql/english'; Therefore, this is not a problem for the deb package or the not-yet-released fedora package. It is a problem for linux installs using the official RPM or the tarball. This is not a problem on i386 since the slimserver Bin directory is searched first and the slimserver bundled mysqld will always be run. It seems that there needs to be some way for slimserver to detect that the system mysqld will be launched and to also use the system errmsg.sys. The workaround is to copy the system errmsg.sys and replace the slimserver bundled one. I suppose the user could also edit my.tt.
please don't preset targets. those are used internally after a review.
Fletch - do you have a patch for this?
Sorry Dan. I understand the problem, but I don't think I know the code well enough to figure out the best way to fix it. It seems like we need to determine which mysqld will be used and then create my.cnf as appropriate for the proper language dir...
I have just run into this problem on an x86_64 system. Here it's doubly wrong --- even though this is not an i{3,5,6}86 platform, it's able to run the i386 binary, and should do so. In Slim::Utils::Misc, I have added the following line: $arch =~ s/^x86_64-([^-]+).*$/i386-$1/; as line 93. Perhaps this should be a new bug, because the patch is very specific to x86_64.
(In reply to comment #4) > even though this is not an i{3,5,6}86 platform, it's able to run the i386 > binary, and should do so. I kind of have mixed feelings about this part. What should happen on an x86_64 system where the system has it's own x86_64 mysqld installed? I would argue that we should prefer the system x86_64 mysqld over the slimserver i386 one. I think the search order is such that your patch will do the opposite.
If you want to put this into your current RPM project, we're okay with giving it a try. It does seem like many people have peculiar issues with running their own mysql instance, so it might cause some problems, but in general linux users are also more able to figure out the solution to those problems. Would you like this assigned to you, fletch?
Chris, My new RPM currently uses the system copy of mysqld, flac and sox (like the deb does). Therefore, due to the MySQLHelper code cited earlier, this bug will not affect my RPM. However, I think (although I haven't looked at it lately) that this bug still exists on non-i386 linux tarball installations - depending of course on the version of mysqld included with the target linux distribution. As I mentioned to Dan in an earlier comment, I'm not the best person to tackle this...
Unassigned bugs cannot have a priority.