On 2012-03-22 16:16, Knurpht wrote:
>
> I do see something odd: the files in /var/tmp/my* are owned by bin,
> perms 700. So user mysql cannot write there IMO a “chown mysql
> /var/tmp/my* -R” should do.
They are not files, they are directories. The directories and what is
inside should be owned by mysql:mysql.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
Admitted, I should have phrased much clearer: the folders /var/tmp/my* , and probably their content, are owned by user “bin”. Rush is not (always) a good thing.
On 2012-03-22 23:36, Knurpht wrote:
> Admitted, I should have phrased much clearer: the folders /var/tmp/my*
> , and probably their content, are owned by user “bin”. Rush is not
> (always) a good thing.
I mentioned it because in this case mysql would not be allowed to create
something inside those directories - but who created them?
I think that (normally) mysql creates a new one when it needs to, and
forgets about the old ones. But with the proper permissions.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
That is also my idea. In my case, I just started the system 10 mins ago (at09:25 local time) and the most recent of those directiries is
boven:/var/tmp # l mysql.1ulIcp/
total 8
drwx------ 2 mysql mysql 4096 Mar 23 09:25 ./
drwxrwxrwt 170 root root 4096 Mar 23 09:25 ../
boven:/var/tmp #
which is empty (as are the six other old ones I have).
BTW I do not know why I have those six others, they are all from a few days in November and December last year and the system is booted (and thus MySQL started) every day??? See post#12 above. The one from 22 March is replaced by the one of 23 Mrach. The other six are still there.
The big question here is, why are those of the OP (post #14) owned by bin? They date obviously all from his many trials to start MySQL on 21 ans 22 March.
And when they are owned by bin and have the restrictive access bits they have, the user mysql can of course do not much within them.
And as this stopped working after a crash (a crach of the system or s crash of MySQL, can you anser that @Zeepblok?), how can a process that was earlier run as mysql now run as bin (after a crash of whatever)?
Changing the owner of the existing directories as @Knurpht suggests will not help, because the error comes from the new created directory at every new start.
And in the background we still have the big question of @Zeepblok: even if I can not get MySQL started, I want to get my data oiut of the database. Can anybody help there?
the chown command didnt have effect either 
but thnx for thinking about it
As I said above, it changed only old stuff. We should find out why bin is creating those.
Please explain more about the crash as I asked. What crashed?
Not the entire system, the apache and sql service where in panic mode according to the service status command
Did you do any analyses on that? I mean, you come here and say “it does not start”. But there is some important histoty before that. You can not simply ignore that and go on if nothing happened.
I rebooted the server to be sure and after that It wouldnt start anymore
To be sure of what? To be sure you destroyd evidence of what was going on? Sorry, to be a bit sarcastic. Booting is a last resort when all else fails.
Try to find logings of that incident in log files of that date in /var/log/messages. There may still be something.
Thnx for the help all. the system died good this time. So i have to start over thnx anyway
While I feel with you about the system dying, your description is again not very precise. But I nevertheless would advise you to check the disk thouroughly before using it for a new install or another route of recovery.
To the OP:
Aside from your system issues
With a tiny bit of bemusement I just read this thread and you describe a very common mistake by novist Database Admins… expecting that with little effort the Database App can read a database file created on another machine.
You should know that generally speaking, this cannot be easily done with <any> Database Engine, not just MySQL… Whenever you install a new instance of a Database app, unique security identifiers are created that secures how the application runs, among other things preventing the arbitrary modification and use of database stores created outside that instance.
If there is no alternative, you can look up “Fork Lift” database importing to do exactly what you’re attempting to do, and note the various caveats and warnings when doing it. Repeating, ordinarily this is a method of last resort.
Ordinarily, the database file you’re trying to import should be accessible and usable in its original database application instance… And so ordinarily you should be able to import the data using recognized preferable means… ie creating a new local database file, then replicating or shipping the data from source to destination.
HTH,
TS