1 |
On Jan 23, 2008 6:45 AM, <reader@×××××××.com> wrote: |
2 |
|
3 |
<snip> |
4 |
|
5 |
> > ls -al /var/lib/mysql |
6 |
> |
7 |
> drwx------ 2 mysql mysql 1752 Jan 22 15:55 mysql |
8 |
> drwx------ 2 mysql mysql 48 Jan 22 15:55 test |
9 |
> |
10 |
> It struck me odd that /var/lib/mysql has another directory inside with |
11 |
> the same name... but that was how the previous install looked as well. |
12 |
> |
13 |
|
14 |
Yeah - the sub-dirs under /var/lib/mysql are the individual named |
15 |
database schemas, and mysql uses the "mysql" schema to store the info |
16 |
about users, databases, privileges, etc., which brings us to the next |
17 |
point: |
18 |
|
19 |
> > Also, what do you get in the MySQL console if you do a: |
20 |
> > show databases; |
21 |
> |
22 |
> mysql> show databases; |
23 |
> +--------------------+ |
24 |
> | Database | |
25 |
> +--------------------+ |
26 |
> | information_schema | |
27 |
> +--------------------+ |
28 |
> 1 row in set (0.03 sec) |
29 |
|
30 |
This is *very* abnormal. You should have *at least* seen 3 items: |
31 |
information_schema, mysql, and test. The fact that nothing but the |
32 |
"meta" database shows up (AFAIK, information_schema isn't actually a |
33 |
DB in MySQL, it's just metadata about the server - kind of like the |
34 |
/proc filesystem in *nix). So, this leads me to think that maybe the |
35 |
MySQL service had not been restarted since the last time you emerged |
36 |
mysql? This would explain why cleaning the log dir and then restarting |
37 |
MySQL fixed it... |
38 |
|
39 |
|
40 |
> |
41 |
> > Also, try doing the create database procedure as previously outlined, |
42 |
> > then do a tail -n100 /var/log/mysql/mysql.err and |
43 |
> > /var/log/mysql/mysqld.err and /var/log/mysql/mysql.log - anything |
44 |
> > relative showing up in there? Maybe post the output of the above |
45 |
> > commands, as well as (tbz2'd, if they're large) attaching the |
46 |
> > /var/log/mysql/* files - might help us track this down... |
47 |
> |
48 |
> My first impulse was to look there as well but strangely nothing was |
49 |
> being written about those errors. So in response to your post I |
50 |
> thought I would clean out those logs with rm -f /var/log/mysql/my* |
51 |
> |
52 |
> Then restart mysql. |
53 |
> |
54 |
> Surprisingly after doing those steps. It now works. |
55 |
> |
56 |
> Apparently you've backhandedly fixed it simply with a request for |
57 |
> information... : ). |
58 |
|
59 |
Heh. Stranger things have happened, but not *too* much stranger... ;) |
60 |
|
61 |
> |
62 |
> Now smooth as silk: |
63 |
|
64 |
Awesome, glad it's working for you! |
65 |
|
66 |
|
67 |
> |
68 |
> Reminds me of a comment a neighbor made yrs ago. |
69 |
> |
70 |
> I was a sort of neighborhood fixit guy. Pretty handy with my hands |
71 |
> from a lifetime of bluecollar work and being raised as a kid in the |
72 |
> country. |
73 |
> |
74 |
> Neighbors would call me when their fixit chores got out of there |
75 |
> league. This one neighbor, on having me come over for an electrical |
76 |
> problem, swore things at his house started just working when he called |
77 |
> me to come over... said they'd see me coming and just know they'd have to |
78 |
> work shortly. |
79 |
> |
80 |
> That appears to be what happened here. |
81 |
|
82 |
Yeah, I've seen that happen quite a bit with computers - someone is |
83 |
having a problem (consistently, too), they call in the computer tech, |
84 |
and it starts working perfectly as soon as the tech is there... :) A |
85 |
hypothesis of mine is that (at least some of the time), as soon as the |
86 |
computer tech is there, and asking to see the problem duplicated, the |
87 |
user focuses more on what they are actually doing, and in doing so, |
88 |
performs the action in the correct manner... Possibly... :) |
89 |
|
90 |
-James |
91 |
-- |
92 |
gentoo-user@l.g.o mailing list |