Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

have been directed here from stackoverflow here, am reposting the question and adding my.cnf at the end of a post.

so far in my 10+ years experience with linux, all the permission problems I've ever encountered, have been successfully solved with chmod -R 777 /path/where/the/problem/has/occured (every lie has a grain of truth in it :)

This time the trick doesn't work, so I'm turning to you for help. I'm compiling mysql server from scratch with zc.buildout (www . buildout . org). I do launch it by executing /home/toinbis/.../parts/mysql/bin/mysqld_safe, this works. The thing is that i'll be launching this from within supervisor (supervisord . org) script, and when used on the deployment server, it'll need it to be launched with root permissions(so that nginx server, launched with the same script, would have access to 80 port). The problem is that sudo /home/toinbis/.../parts/mysql/bin/mysqld_safe, fails, generating the error, posted bellow, in mysql error log (apache and nginx works as expected).

http://lists.mysql.com/mysql/216045 suggests, that "there are two errors: A missing table and a file system that mysqld doesn't have access to". Mysqldatadir and all the mysql server binary files has 777 permissions, talbe mysql.plugin does exist and has 777 permissions (why Can't open the mysql.plugin table?), "sudo touch mysql_datadir/tmp/file" does create file (why Can't create/write to file /home/toinbis/.../runtime/mysql_datadir/tmp/ib4e9Huz?).

chgrp -R mysql mysql_datadir and adding "root, toinbis, mysql" users to mysql group ( cat /etc/group | grep mysql outputs mysql:x:124:root,toinbis,mysql) has no effect - when i launch it as a casual user, it starts, when as a root - it fails. Does mysql server, even started as root, tries to operate as other, let's say, 'mysql' user? but even in that case, adding mysql user to mysql group and making all the mysql_datadirs files belong to mysql group should make things work smoothly.

I do know that it might be a better idea to simply to launch one the nginx as root and mysql - as just a user, but this error irritated me enough so to devote enough energy so not to only "make things work", but to also make things work exactly as i wanted it initially, so to have a proof of concept that it's possible.

and this is the generated error:

091213 20:02:55 mysqld_safe Starting mysqld daemon with databases from /home/toinbis/.../runtime/mysql_datadir
/home/toinbis/.../parts/mysql/libexec/mysqld: Table 'plugin' is read only
091213 20:02:55 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
/home/toinbis/.../parts/mysql/libexec/mysqld: Can't create/write to file '/home/toinbis/.../runtime/mysql_datadir/tmp/ib4e9Huz' (Errcode: 13)
091213 20:02:55  InnoDB: Error: unable to create temporary file; errno: 13
091213 20:02:55 [ERROR] Plugin 'InnoDB' init function returned error.
091213 20:02:55 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
091213 20:02:55 [ERROR] Can't start server : Bind on unix socket: Permission denied
091213 20:02:55 [ERROR] Do you already have another mysqld server running on socket: /home/toinbis/.../runtime/var/pids/mysql.sock ?
091213 20:02:55 [ERROR] Aborting

091213 20:02:55 [Note] /home/toinbis/.../parts/mysql/libexec/mysqld: Shutdown complete

091213 20:02:55 mysqld_safe mysqld from pid file /home/toinbis/.../runtime/var/pids/mysql.pid ended

My my.cnf (the basedir and datadir(including tempdir) have chmod -R 777 permissions) :

[client]
socket          = /home/toinbis/.../runtime/var/pids/mysql.sock
port            = 8002

[mysqld_safe]
socket          = /home/toinbis/.../runtime/var/pids/mysql.sock
nice            = 0

[mysqld]
#
# * Basic Settings
#

socket          = /home/toinbis/.../runtime/var/pids/mysql.sock
port            = 8002
pid-file        = /home/toinbis/.../runtime/var/pids/mysql.pid
basedir         = /home/toinbis/.../parts/mysql
datadir         = /home/toinbis/.../runtime/mysql_datadir
tmpdir          = /home/toinbis/.../runtime/mysql_datadir/tmp
skip-external-locking
bind-address            = 127.0.0.1
log-error =/home/toinbis/.../runtime/logs/mysql_errorlog

#
# * Fine Tuning
#
key_buffer              = 16M
max_allowed_packet      = 32M
thread_stack            = 128K
thread_cache_size       = 8
myisam-recover          = BACKUP
#max_connections        = 100
#table_cache            = 64
#thread_concurrency     = 10

#
# * Query Cache Configuration
#
query_cache_limit       = 1M
query_cache_size        = 16M

#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
#log            = /home/toinbis/.../runtime/logs/mysql_logs/mysql.log
#
# Error logging goes to syslog. This is a Debian improvement :)
#
# Here you can see queries with especially long duration
#log_slow_queries       = /home/toinbis/.../runtime/logs/mysql_logs/mysql-slow.log
#long_query_time = 2
#log-queries-not-using-indexes
#
# The following can be used as easy to replay backup logs or for replication.
#server-id               = 1
#log_bin                 = /home/toinbis/.../runtime/mysql_datadir/mysql-bin.log
#binlog_format           = ROW
#read_only               = 0
#expire_logs_days        = 10
#max_binlog_size         = 100M
#sync_binlog             = 1
#binlog_do_db           = include_database_name
#binlog_ignore_db       = include_database_name

#
# * InnoDB
#
innodb_data_file_path = ibdata1:10M:autoextend
innodb_buffer_pool_size=64M
innodb_log_file_size=16M
innodb_log_buffer_size=8M
innodb_flush_log_at_trx_commit=1
innodb_file_per_table
innodb_locks_unsafe_for_binlog=1


[mysqldump]
quick
quote-names
max_allowed_packet      = 32M

[mysql]
#no-auto-rehash # faster start of mysql but no tab completion

[isamchk]
key_buffer              = 16M

Any ideas much appreciated!

regards,

to

P.S. sorry for messy hyperlinks, it's my first post and anti-spam feature of SF doesn't allow to post them properly :)

share|improve this question

4 Answers 4

First off? Don't use 777 for this. Don't. Daemons don't run as root for a reason (monstrous security problem if any of them have a buffer overflow -- if anybody manages to get into your website via SQL injection or other, they've just rooted your box). Use a wrapper script to drop the privileges after you open the port. Nginx doesn't need to be run as root either.

Secondly, your problem appears to be the paths. Not permissions. Unless you've substituted the actual path with /.../ everywhere in this post, that's your problem. If you did, please update the question with the full path.

share|improve this answer
    
Phresus, cheers. Yes, i've changed the path, which is similar to "/home/toinbis/Desktop/programming/pamella-anderson-photo-galery-project-name/bu‌​ildout/runtime/" with what you can see:) As the folder of the path contains my not-yet-realeased project's name, i've prefered not to unveil it. So i feel it's not the path problem(as it's all working flawlessly with a casual user). Agree with your opinion, the 777 is just an extreme way of trying to trace the root of a problem... Will try to refresh my bash knowledge and write decent wrapper script... cheers once again! –  toinbis Dec 16 '09 at 15:48
    
Well, that clears that up. It may be helpful to update the question with ls -l /path/to/your/mysql/root (make that ls -lZ if you have SElinux enabled). If it's 777, SElinux seems like the obvious culprit (/var/log/audit/audit.log). –  phresus Dec 16 '09 at 21:11

Silly question first. Are you sure there isn't another mysql running? Read-only errors despite sane permissions (and despite 777) are almost always a sign that files are locked by another process. You can use lsof to find out if something else is messing with your files:

$ lsof /home/toinbis/.../runtime/var/pids/mysql.sock

or

$ sudo lsof | grep mysqld

If you are still getting the error try the above and if their are any matches they are what is to blame.

Failing that, do a fresh build and never ever start as a non-root user. Does that make any difference?

If you want to cheat, create a wrapper script using buildout_script (http://pypi.python.org/pypi/buildout_script/0.2a1)

It takes a template Something like:

#! /bin/sh
sudo -u mysql_or_your_username_here {buildout[bin-directory]}/mysqld_safe $@

That way mysqld_safe never runs as root, and you avoid this error. I find this distasteful, but your entire setup is already something i'd never ever do so I think it would be in good company! :)

I believe Gentoo and a system-level config tool like puppet, chef-solo, or kokki would suit you better though.

share|improve this answer

Is your home directory mounted across NFS, mounted with config which is squashing root privileges down to "nobody"? If so, start as another user, or don't store the data in NFS, or export the NFS share without root_squash.

share|improve this answer
    
Phill, thanks for replying! No, it's the same partition, all files in one subdirectory, on good not-so-old ext4 filesystem;) –  toinbis Dec 15 '09 at 19:52
    
Just read the Q more thoroughly: yes, mysqld_safe drops privileges to the mysql user (unless overriden with -o/--user); generally, running commands as root needlessly is dangerous, so the start-up wrapper script drops privileges. This lets you have one startup script run as root for all the tools, but still drop privileges very easily. –  Phil P Dec 15 '09 at 20:24

I'm compiling mysql server from scratch with zc.buildout (www . buildout . org).

It looks like you've got into a mess! :)

Is there a specific reason why you are compiling MySQL server from source? I found this MySQL "buildout" script, which may be related to what you're doing: It seems to download MySQL server and a package to give MySQL support to Python, then compile and install these in non standard locations.

In any case, MySQL specifically recommend against compiling from source, as they provide their own optimised binary packages for various different platforms.

If you are deploying to a nice package managed system, then your "buildout" script need only invoke the package manager of the target system. This will give you a vendor recommended and approved installation (no chmod -R 777 necessary!) in a couple of commands. For a RHEL/CentOS system, the procedure is roughly:

yum install mysql-server (MySQL-python?)
[edit /etc/my.cnf]
chkconfig mysqld on && service mysqld start
[lock down the server by adjusting the grants]

See how easy, repeatable that is :). Unless you have a very good reason, using your system's built in package management is definitely preferable, compared to non-standard install locations and chmod -R 777 games.

share|improve this answer
    
Lockie, cheers for devoting your time! I compile it from source for couple reasons. First, feelings-based,I honestly feel power doing that. I guess that's hacker's way to do it, and i like it:) Second, pragmatical reasons based, i do want to have latest innodb plugin installed and try out tokudb plugin. Thirdly, i guess that's the real loosly-coupling, when you lamp stack is linux-distribution-independent. I'll update my post with zc.buildout config i use;) –  toinbis Dec 15 '09 at 19:43
    
BTW, i was honestly thinking myself "this will get me into mess", but now i've almost made it all work, except the problem being discussed, it's a really nice LAMP setup ("custom" mysql, php, apache, nginx, supervisor, phpmyadmin, wordpress, django, djangosphinx..., all the system being built with one command. Whenever i finish setting it up, i'll share all the buildout.cfg... –  toinbis Dec 15 '09 at 19:50
    
No, it's not a very nice setup - since you solve all your permission issues by giving the world write access to any file or folder. I suggest that you use packages from your operating system, and then modify config files to make it work for you. –  pauska Dec 16 '09 at 13:11
    
Using 777 permission is just a debugging tool, which says nothing about the beauty of the system. The discussion of what is more valuable - increased flexibility, which you get by having all the lamp stack "customly" compiled, or increased security, which you get by using OS packages, is worth the separate discussion, not to be performed in comments. The answer is probably "if you know what you are doing, go for customized setup, otherwise stick to OS packages". But i personally prefer "don't know something? learn it", not "don't know something? don't do that" attitude... –  toinbis Dec 16 '09 at 16:13

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.