At 13:12 -0700 6/12/02, Van wrote:
>Perhaps a bug, even. After about 5 months my mysql log file grew to over
>300MBytes and I figured I'd do something about it as follows:
>tail -n 100000 /mysql/why.log > /tmp/why.log && sudo mv /tmp/why.log
>mysqladmin -u root flush-logs
>Unfortunately, this set the permissions of why.log as a user other than mysql,
So what happened? Did this command:
sudo mv /tmp/why.log /mysql/
replace your old /mysql/why.log file with one owned by root?
If so, I guess I wouldn't be surprised.
>preventing mysqld from logging queries (exactly what I'd hoped to
>avoid), so I:
>sudo chown mysql.mysql /mysql/why.log
>- and -
>Doing a tail -f on /mysql/why.log and issuing queries I didn't see
>writing to the log.
>I tried mysqladmin flush-logs and still no logging.
>Eventually, the only way to get logging to recommence was to do a mysqladmin
>shutdown and rerun my /etc/rc.d/rc.mysql script to start it back up.
>was only down for a second, or two, but I still hate to have to restart things
>when they're otherwise working just fine (it's so windows-ish).
>My guess is the changing of ownership on why.log to a different user
>threw up a
>write block on the file at the OS level (Linux Slackware 7.something-or-other
>kernel 2.2.18) and the refresh and flush-logs doesn't have a function to check
>(re-check?) the permissions in case of something like this happening
>tell the OS to allow the mysqld to allow writes to the file again.
>I could have been more careful with how I archived the log, but the refresh
>should take note of file permissions at the time the command is
>issued; not the
>permissions at the time the mysqld daemon started. Also, there was no message
>issued to the error log.
>I doubt I'll repeat the mistake, but perhaps someone down the road might.
>Perhaps Monty & crew could throw a safety check in place for such events.
>Linux rocks!!! http://www.dedserius.com/