MySQL wont start after linode reboot

have you tried

/etc/init.d/mysqld start

have you turn mysqld's chkconfig levels 235 on?

Thanks for the reply. In answer to your questions, yes and no.

Turn even sure what the second question means? Any pointers?

Thanks :)

Check your mysql error log. It's probably located in either /var/log or /.err

I have done, unfortunately it's empty :(

Then I'd bet it's a permissions problem, mysql logs start up info to your mysql log if it's empty this suggests mysql cant write to it, make sure whatever user mysql runs has has permissions to your database directory and log file.

Hi Obs,

Got this fixed in the end. Turns out I had run out of disk space due to one log file ballooning to 15Gb! Finally tracked it down and deleted it and all has gone back to normal.

Thanks for replies - most appreciated :)

Cheers,

Terry

I've been there… :P

Someone once edited a main script of a high-traffic site, causing it to spam two E_NOTICEs on each hit… >.<

The semi-cool thing is that MySQL apparently halts processing queries when it notices being out of disk space, keeps the data in memory until it can write it, and resumes operations like nothing happened afterwards.

@rsk:

The semi-cool thing is that MySQL apparently halts processing queries when it notices being out of disk space, keeps the data in memory until it can write it, and resumes operations like nothing happened afterwards.

I just threw up in my mouth a bit.

@hoopycat:

I just threw up in my mouth a bit.
Er, care to explain?

To me, logging an error message with "waiting for X kb of disk space" and queuing all new requests seems better than crashing and leaving a damaged table…

It's the "keeps the data in memory until it can write it" more than the "halts processing." It likely depends on how the storage engine is configured, though, and I expect it errs to the side of caution by default. (My distaste still stands if it considers the data committed prior to it being written to disk.)

(As an aside: normally, filesystems reserve a percentage (5% or so?) of the disk for root. In other words, a normal user will get no-space-left-on-device at 95%, while root can cram it all the way up to 100%. I wonder if it might not be a bad idea for logs to be owned/written to by a non-root user.)

Well, technically, it halts BEFORE returning any kind of response to the client. So it's like you sending an INSERT, and your query() call just hanging there (and possibly timing out). Oh, and it happened on MyISAM, not InnoDB… I never had InnoDB OOD on me yetm no idea what happens. >.>;

For the root-reserved area… well, that was the case here, it was free… which's quite good, as I'm not sure if I could log in otherwise… keep in mind, tho, that MySQL runs as non-root too, so it also can't touch that space.