| Bug #2029 | default configure cause permissions problems with mysqld_safe | ||
|---|---|---|---|
| Submitted: | 5 Dec 2003 23:39 | Modified: | 28 Jan 2004 2:15 |
| Reporter: | [ name withheld ] | Email Updates: | |
| Status: | Not a Bug | Impact on me: | |
| Category: | MySQL Server: Compiling | Severity: | S2 (Serious) |
| Version: | 4.0.16 source | OS: | Linux (Linux 2.4.19 i686) |
| Assigned to: | CPU Architecture: | Any | |
[6 Dec 2003 0:05]
Dean Ellis
As with #2028, this is not a bug. If you like, these can be changed to feature requests and will be handled as such. Thank you.
[6 Dec 2003 0:42]
[ name withheld ]
I realize you need to do triage on the bugs, but I'd appreciate if you could mark this one as something other than "Not a Bug". The traditional "configure; make; make install" sequence really should produce something workable, and having spent some time on it I think I'm convinced that it can not work unless one edits either 'configure' or 'safe_mysqld.sh'. So if you could, at least leave it in a state that someone searching for this bug will find it, in hopes that it may one day be fixed. Thanks!
[6 Dec 2003 0:58]
Dean Ellis
I understand (and appreciate) what you want here, but as I noted, unless you want these to be considered feature requests, they truly are not bugs. For example, the steps provided in the "Quick Installation Overview" portion of the "Installing a MySQL Source Distribution" chapter explicitly specify a --prefix option to configure to alter the default. In addition, the "Typical configure Options" chapter calls attention to the default prefix of /usr/local and mentions how to change it. Aside from "Feature Request", there really is no other way to flag something that is very much documented. If you want them considered for possible future enhancements, just let me know.
[6 Dec 2003 4:43]
Alexander Keremidarski
> The traditional "configure; make; make install" sequence really should > produce something workable, Maybe this can be considered "traditional", but this is very bad tradition to run ./configure without choosing your own options. This is true for every software not MySQL only. Much better style which is also "traditional" is to run: ./configure --help # Consider carefully your prefered options ./configure --<list of your options goes here> Please also note that MySQL Manual *don't* suggest running ./configure without any options. All examples contain at least: ./configure --prefix=/usr/local/mysql In Quick Installation Overview chapter one can read: http://www.mysql.com/doc/en/Quick_install.html <quote> 2.3.1 Quick Installation Overview ... Configure the release and compile everything: shell> ./configure --prefix=/usr/local/mysql shell> make When you run configure, you might want to specify some options. Run ./configure --help for a list of options. section 2.3.3 Typical configure Options, discusses some of the more useful options. <end of quote> And there is separate chapter called Typical configure Options http://www.mysql.com/doc/en/configure_options.html With regard of all of the above I believe you should agree with Dean that there is no way to consider what you report as bug. I don't think it could be accepted even as a Feature Request.
[6 Dec 2003 8:41]
Mark Matthews
The issue here seems to be the fact that the _error_message_ is misleading. I'm re-opening this as deferred, and assigning to Heikki, as any error message that refers to a file should _really_ print the entire pathname of the file (if possible), so that a user can figure out what's truly going on. I've been bitten by a variation of this bug on Windows as well, when there was a bug (which has since been fixed) in InnoDB in the 4.1 BK builds where it was picking up incorrect iblogfiles, but not saying _which_ ones it was using in the error message. There was no easy way to determine which files it was using either, as the bug was causing InnoDB to ignore the --datadir and --basedir options.
[27 Jan 2004 10:31]
Heikki Tuuri
Hi! The error message in this report does not come from InnoDB. That is why I am changing the assignment to 'not assigned'. Regards, Heikki
[28 Jan 2004 2:15]
Sergei Golubchik
to the original report: I don't see it as a problem. /usr/local/var is no more standard (FHS - http://www.pathname.com/fhs/) than /usr/local/mysql. Thus it is ok to have it writable for mysql user. If you don't want to use /usr/local/var/mysql instead of /use/local/var as datadir, you can change it with --prefix, as documented. You may need it if your setup is itself breaking the FHS by storing data under /usr/local/var. As for # ./configure # make # make install # scripts/mysql_install_db # /usr/local/bin/mysqld_safe & it doesn't work out-of-the-box because neither make install nor scripts/mysql_install_db change permissions of DATADIR, you have to do it manually, as documented. So - I agree with Dean - it is not a bug.
Description: By default, configure uses "/usr/local" as the prefix. The causes mysqld_safe to use "/usr/local/var" as the data directory. This causes a slough of permissions problems, because usually one does not want "/usr/local/var" to be writeable by a non-root user. For example, here's what I saw at startup: 031205 23:01:13 InnoDB: Started 031205 23:01:13 /usr/local/libexec/mysqld: Can't create/write to file '/usr/local/var/first.pid' (Errcode: 13) Why is this file being written here to "/usr/local/var" rather than to "/usr/local/var/mysql"? For that matter, why is the error log written to "/usr/local/var" as well? Shouldn't both of these be in a MySQL specific directory, so that permissions can be arranged? To show another problem, when I went to create a new database, I got this: mysql> create database testing; ERROR 1006: Can't create database 'testing'. (errno: 13) But since I have no log file (due to permission errors) I'm not sure exactly what I need to change... How to repeat: # ./configure # make # make install # scripts/mysql_install_db # /usr/local/bin/mysqld_safe & Suggested fix: Probably, mysqld_safe should be changed to use "/usr/local/var/mysql" in all cases where it currently uses "/usr/local/var" as a default. It's possible that this is as simple as setting "DATADIR=/usr/local/var/mysql", but there are enough other things happening here that I'm not quite sure what else this might affect. Alternatively, one could change 'configure' to use "/usr/local/mysql" by default, and state categorically that things will not work if configured to use "/usr/local" as the prefix. This doesn't strike me as a very good idea, though.