I am trying to do some stuff every time mysqld (version 5.1.4) is started/restarted on Fedora14.
I put the following line in my.cnf:
init-file=/etc/mysqlinit.sql
I've tried various queries in the file, even leaving the file empty.
MySQL will not start ... I get Timeout error occurred trying to start MySQL Daemon.
I've tried enclosing the path in quotes and have ensured file permissions are same as my.cnf.
I've tried moving the file around.
Nothing in the mysqld or messages logs to help.
I wonder if selinux has to be turned off.
Did I miss something?
change the ownership and group of the /etc/mysqlinit.sql file (and dirs) to match the one mysqld (the deamon not the config file) is running under and try again, enable the error_log to see the output of the error.
Related
Starting on PHP/MySQL Development and as the title states, downloaded MySQL 8.0.15 DMG. Installed. However, when I attempt to run the terminal command:
"sudo /usr/local/mysql/support-files/mysql.server.start"
I get:
"Starting MysQl .......... "
which finally ends in:
ERROR! The server quit without updating PID file (/usr/local/mysql/data/Macbook.hsd.comcast.net.pid)
So far I have tried:
Tried to remove the "Macbook.hsd.comcast.net.pid" file located in the data directory but all i keep getting a "No Such file or directory"
To look for default "my.cnf" file to mod or to add the default values, HOWEVER I read that: "By default the OS X installation does not use a my.cnf, and My SQL just uses the default values. To set up your own my.cnf, you could just create a file straight in /etc.
An "auto.cnf" exists in the data folder, i'm not sure if MySQL uses that or would respect a "my.cnf" created in the /usr/local/sql/data/ folder.
I'm not sure of the proper location to create a "my.cnf" (see, all I want to do is set the proper value for the "pid-file" such as pid-file = /var/run/mysqld/mysqld.pid and then create the directory and give it the proper permissions. SEE UPDATE AT BOTTOM:
I'm cannot access the "data" folder in MySQL folder (which is alias of): "/usr/local/mysql-8.0.15-macos10.14-x86_64/". It keeps telling me I don't have permission. There is a little red dot
I have set checked the permissions in "/user/local/mysql/" and did a
"sudo chown -RL root:mysql /user/local/mysql"
"sudo chown -RL _mysql:mysql /usr/local/mysql/data"
In the /mysql/ directory now everything reads:
Stumped and not sure where to move on from here.
Is the fact that I can't access the data folder a result because I haven't made one/specified one? Can't seem to find an answer for getting MySQL working with HighSierra/Mojave. I can't believe that it's just dead.
I would appreciate any/all help.
UPDATE/EDIT:
Was able to add my user permissions to the "/user/local/mysql/data" folder and was finally able to access the error file ("Macbook.hsd.comcast.net.err") and a "auto.cnf".
The "auto.cnf" file is empty besides a single line: [auto] server-uuid=e7986494-331d-11e9-9691-bec9b3249da6 (not sure if I need to modify the auto.cnf and add PID entries). See error BELOW which seems to indicate otherwise.
The Error file had repeated Errors (occurred several Times):
When I try to start my SQL server, a message pops up saying that it starts but then stops. This happened after a restart on my server.
Does anyone know how I can fix this?
Make sure that the data directory has full permissions set for users "Network Service" and Administrator and that you have quotes around the name of the directory if there are spaces in it. Make sure that basedir is set / not commented out.
I tested these things by changing the data directory, which re-caused the error you describe above exactly, then fixed the permissions of the newly created data directory to eliminate the error. I can switch back and forth now my changing which data directory I comment out. (only as a test, otherwise that's kind of nuts).
C:\ProgramData\MySQL\MySQL Server 5.7\my.ini Should be something like this, using Windows 2012 R2 server to test:
# Path to installation directory. All paths are usually resolved relative to
this.
basedir="C:/Program Files/MySQL/MySQL Server 5.7/"
# Path to the database root
# datadir="C:/ProgramData/MySQL/MySQL Server 5.7/Data"
datadir="d:/ProgramData/Data"
Please try the following steps:
run 'cmd' as administrator,
cd to your SQL folder,
run 'mysqld --initialize --user=mysql --console' to reset and
run 'net start mysql' to start the service.
Nothing worked for me except for uninstalling the current 5.7.35 and then installing the 5.7.31. Try downgrading. Might help!
add to config file my.inf on C:\ProgramData\MySQL\MySQL Server 5.7
[mysqld]
tmpdir=C:/temp
and everything will work fine .
I am in a serious problem while installing mysql on ubuntu 12.04 32 bit. when i start mysql with command ''./mysql.server start'' I got this error Manager of pid file quit without updating pid file. I installed ''mysql-5.1.39-linux-i686-glibc23''.
I thoroughly search for the solution to fix this error but cannot resolve it yet. I copied my-medium.cnf file to the /etc directory and rename it by my.cnf also edited this file in the section ''The mysql Server'' and add these lines ''datadir = /exports/disk0/data'' but could fix this problem. Can any one help on this.
The message bout the pid file is kind of a red herring. It just means that the init script /etc/init.d/mysql did not return success. The root cause could be a variety of things, for example file permissions problems in your datadir, or the config file contained an invalid line, or dozens of other possible problems.
When you get the error about the pid file, the first thing you should do is to go read the MySQL error log file. Usually this is in the data directory, and it may be called hostname.err (where "hostname" is the name of the server you installed MySQL).
Search the file for any lines reporting "ERROR" and then use Google to research the error.
UPDATE: The sysadmin in my company deleted the /tmp directory and created a
symbolic link to a mounted drive (e.g. ln -s /mnt/somewhere /tmp).
MySQL apparently didn't like this symbolic link.
Once a real /tmp directory on the local filesystem was created the problem went away.
I'm running a process (rake db:migrate) which causes MySQL to try to create a temp file.
However, the following error is appearing:
Mysql::Error: Can't create/write to file '/tmp/#sql_196_0.MYI' (Errcode: 13):
SHOW FIELDS FROM `user_rules`
Errcode 13 apparently is a file permission issue.
The user that is running the process has write permissions to the /tmp directory.
I also searched the web, and someone mentioned that the issue could be the file be prefixed with a pound sign (e.g. '#").
I went to the /tmp directory and tried to create the file and noticed that in certain cases I can't create the file. So I'm wondering if indeed the pound sign is causing the problem. And if it is, how can use MySQL or Rails to fix the problem:
cd /tmp
echo "Hello" > #sql_123
touch #sql_123
echo "Hello" > "#sql_123"
touch "#sql_123"
The 2nd and 3rd commands (without quotes) are failing. The 4th and 5th lines (with quotes) are working. So maybe the failure is because of the pound sign not being in quotes or escaped with a backslash. But again, even if that is the cause, I'm not sure how to tell MySQL or Rails how to deal with it.
Any ideas?
In a shell you need quotes because # introduces a comment, unless escaped by a backslash or quotes. Those #sql_123 files with a prefix of a pound-sign are temporary files owned by mysql, they are normal. You cannot move them however and whenever they are present you cannot move your database using the binary files, you either need to shutdown and move; or do a mysqldump to SQL.
Now for your sysadmin, did he delete /tmp while mysql was running? Mysql opens files in /tmp and then deletes them from the directory leaving the file-handle open. You would see differences in disk space while the server is up or down. MySQL creates all temporary files as hidden files. This ensures that the temporary files are removed if mysqld is terminated. The disadvantage of using hidden files is that you do not see a big temporary file that fills up the file system in which the temporary file directory is located.
So if you would like to keep the symlink (i.e. to a larger disk) then you would better shutdown mysql, create the link, and then start mysql to find it has no problem with symlinks.
I'm trying make a copy of a MySQL database on another server. I stop the server, tar up the mysql directory, copy it to the other server and untar it. I set all the permissions to match to the working server, and copied the my.cnf file so everything is the same except for server specific changes.
However, when I try to startup the server, I get the following InnoDB error:
InnoDB: Operating system error number 13 in a file operation.
This error means mysql does not have the access rights to
the directory.
File name /var/lib/mysql/ibdata1
File operation call: 'open'.
The owner/group for all the files is mysql. I even tried changing permissions to a+rw. I can su to the mysql user and access the ibdata1 file using head.
SOLUTION:
The problem was selinux was enabled and preventing the new files from being accessed.
A silly question, but people forget: you said you checked that all files have the same permissions; still, even though it said so in the message, might you possibly have forgotten to check the permissions on the containing directory?
UPDATE: Two more suggestions:
You might try inserting --console and --log-warnings flags, for lots of debugging output, something like this (on my Mac):
/usr/libexec/mysqld --console --log-warnings --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-locking --socket=/var/lib/mysql/mysql.sock
If all else fails, you can probably try strace mysqld ... to see what exactly is it failing. The error will be somewhere at the bottom.
UPDATE2: Interesting indeed... I can't see what your OS is. I normally don't use /sbin/service, it's a bit mysterious for me; on a Mac, it's deprecated in favour of launchctl with config file in /System/Library/LaunchDaemons/mysqld.plist, and on most Linux boxes you have /etc/init.d/mysqld. So you could insert strace there.
Or (untested, but manpage suggests it's possible) you could try stracing the service call:
strace -ff -o straces /sbin/service start mysqld
This should produce files straces.pid, one of which should be mysqld's, and hopefully you'll find your error there.
This isn't a direct answer to your question, but I would recommend trying one of these programs for your backup / restore needs.
Percona Xtrabackup: https://launchpad.net/percona-xtrabackup
Mydumper: http://www.mydumper.org/
Both are great tools, are free and open source, and will help you avoid that problem entirely.
Hope that helps.