Websiting

This morning I put some more food out for the birds and washed up the bird tray.

I checked my email, and then did some more work trying to get MySQL working. I tried removing the data directory in the mysql 5.5 installation, then copying across the data directory from the mysql 5.4 installation, removing the innodb log files, then starting MySQL, but I still got the same error I did yesterday about not having the permissions to read my.cnf.

So I thought I'd go back to MySQL 5.4, I renamed the directories, and started up mysql 5.4, but this now wouldn't start, and I was getting the same error about not being ale to read my.cnf! How can renaming a directory and then renaming it back again cause a program to stop working like this?

I looked up how to stop apparmor in Ubuntu: sudo invoke-rc.d apparmor stop


I tried starting MySQL again, but now got errors about the errmsg.sys and InnoDB log files having the wrong size:

100218 10:30:48 mysqld_safe mysqld from pid file /home/djeyewater/webapps/mysql/data/rusty-ubuntu.pid ended
100218 10:36:07 mysqld_safe Starting mysqld daemon with databases from /home/djeyewater/webapps/mysql/data
100218 10:36:07 [ERROR] Error message file '/home/djeyewater/webapps/mysql/share/mysql/english/errmsg.sys' had only 622 error messages,
but it should contain at least 637 error messages.
Check that the above file is the right version for this program!
100218 10:36:07 [Note] Plugin 'FEDERATED' is disabled.
InnoDB: Error: log file ./ib_logfile0 is of different size 0 33554432 bytes
InnoDB: than specified in the .cnf file 0 3145728 bytes!
100218 10:36:07 [ERROR] Plugin 'InnoDB' init function returned error.
100218 10:36:07 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
100218 10:36:07 [ERROR] Aborting

100218 10:36:07 [Warning] Forcing shutdown of 1 plugins
100218 10:36:07 [Note] 
100218 10:36:07 mysqld_safe mysqld from pid file /home/djeyewater/webapps/mysql/data/rusty-ubuntu.pid ended

So I renamed the MySQL 5.4 folder to mysql-old and the MySQL 5.5 folder to mysql and tried starting MySQL 5.5. Amazingly, it actually started.

So it seemed the problem was due to appArmor. Why it was okay before installing MySQL 5.5 but now blocking any changes, I have no idea.

I looked in the syslog and found:

Feb 18 10:30:48 rusty-ubuntu kernel: [ 1970.138194] type=1503 audit(1266489047.998:32): operation="open" pid=3150 parent=3069 profile="/usr/sbin/mysqld" requested_mask="r::" denied_mask="r::" fsuid=1005 ouid=1005 name="/home/djeyewater/webapps/mysql/my.cnf"
Feb 18 10:30:48 rusty-ubuntu kernel: [ 1970.201373] type=1503 audit(1266489048.062:33): operation="open" pid=3150 parent=3069 profile="/usr/sbin/mysqld" requested_mask="r::" denied_mask="r::" fsuid=1005 ouid=1005 name="/home/djeyewater/webapps/mysql/share/mysql/english/errmsg.sys"
Feb 18 10:30:48 rusty-ubuntu kernel: [ 1970.340206] type=1503 audit(1266489048.201:34): operation="open" pid=3150 parent=3069 profile="/usr/sbin/mysqld" requested_mask="r::" denied_mask="r::" fsuid=1005 ouid=1005 name="/home/djeyewater/webapps/mysql/share/mysql/charsets/Index.xml"
Feb 18 10:30:48 rusty-ubuntu kernel: [ 1970.340357] type=1503 audit(1266489048.201:35): operation="mknod" pid=3150 parent=3069 profile="/usr/sbin/mysqld" requested_mask="w::" denied_mask="w::" fsuid=1005 ouid=1005 name="/home/djeyewater/webapps/mysql/data/rusty-ubuntu.lower-test"
Feb 18 10:30:48 rusty-ubuntu kernel: [ 1970.340432] type=1503 audit(1266489048.201:36): operation="mknod" pid=3150 parent=3069 profile="/usr/sbin/mysqld" requested_mask="w::" denied_mask="w::" fsuid=1005 ouid=1005 name="/home/djeyewater/webapps/mysql/data/rusty-ubuntu.lower-test"
Feb 18 10:30:48 rusty-ubuntu kernel: [ 1970.340601] type=1503 audit(1266489048.201:37): operation="open" pid=3150 parent=3069 profile="/usr/sbin/mysqld" requested_mask="rw::" denied_mask="rw::" fsuid=1005 ouid=1005 name="/home/djeyewater/webapps/mysql/data/rusty-ubuntu.err"
Feb 18 10:30:48 rusty-ubuntu kernel: [ 1970.344628] type=1503 audit(1266489048.205:38): operation="open" pid=3150 parent=3069 profile="/usr/sbin/mysqld" requested_mask="r::" denied_mask="r::" fsuid=1005 ouid=1005 name="/home/djeyewater/webapps/mysql/data/mysql/plugin.frm"
Feb 18 10:30:48 rusty-ubuntu kernel: [ 1970.410980] type=1503 audit(1266489048.270:39): operation="open" pid=3150 parent=3069 profile="/usr/sbin/mysqld" requested_mask="rw::" denied_mask="rw::" fsuid=1005 ouid=1005 name="/home/djeyewater/webapps/mysql/data/ibdata1"

So it looked like /usr/sbin/mysqld (the default mysql instance) was being called instead of my 5.5 installation.

Previously I was trying to start MySQL with the command

mysqld_safe --defaults-file=$HOME/webapps/mysql/my.cnf  &

And this had always worked with no problems with MySQL 5.4. But now that there were problems with MySQL 5.5 and 5.4, I decided to try (after re-enabling apparmor)

$HOME/webapps/mysql/bin/mysqld_safe --defaults-file=$HOME/webapps/mysql/my.cnf  &

And mySQL started okay.

I'm pretty sure that $HOME/webapps/mysql/bin was in my $PATH previously (otherwise how would MySQL have started okay before?), but now examining my PATH, I found that $HOME/webapps/mysql/bin wasn't listed. So it seems that by renaming the mysql folder to mysql-old, it had removed the mysql folder from PATH or something?

I asked about this on the Ubuntu forums, then it was lunch time, despite me thinking it must only be about 11.00am.

After lunch I checked my email, then after googling and not finding anything relevant, I posted a question to TWS about How often/when to update site software?

I don't actually need to upgrade to MySQL 5.5 so I can use SIGNAL as I had originally thought. Reason being, I was wanting to use SIGNAL for something that should really be in the application logic, not in the database logic.

I tried writing a procedure to clear up the duplicate records in my location table. The problem was that I also needed to update the two tables that reference the location table, so that any record in those two tables referring to duplicates in the location table are updated as well.

After dinner I watched a couple of episodes of Power Rangers with L, then tried installing XCache. Unfortunately the settings needed for xcache to work well, and what each setting does weren't that clear, so I spent quite a while trying figure out what settings to use.

After that I looked into server side caching (rather than just opcode caching), and found this tutorial, which explains the process of caching page content with PHP quite well: Quick and Dirty PHP Caching. Some comments on the article suggested using XCache or APC for caching. I tried to find out how they would be used for caching page content instead of just opcode caching, but didn't have much luck.

Then I looked at the XCache API, and I think that this, along with setting the variable settings for xcache in php.ini, would be how you do content caching with XCache.

The weather started off overcast but bright, then later in the morning it started snowing, reasonably heavily, with quite large flakes. At lunch time the snow eased off for a bit, and the little that had settled melted away. Then after lunch it started snowing more again, and started to settle again. It snowed for the rest of the day, though considering how much it snowed, there wasn't much to show for it - just a few cm.

Food
Breakfast: Orange Marmalade Toast Sandwich; Cup o' Tea.
Lunch: Ham with Crunchy Salad Sandwich; Gregg's Choc Chunk Chocolate Muffin; Cup o' tea.
Dinner: ⅓ Pepperoni Pizza; ⅛ Cheese & Tomato Pizza; Chips; Salad. Pudding was a slice of Chocolate Fudge Cake. Coffee; Piece of Sainsbury's Caramel Chocolate; 3x pieces of Sainsbury's Mint Creme Chocolate.
Supper: 2x Wafer Biscuits.