You are viewing lathiat

Lathiat's Journal [entries|archive|friends|userinfo]
Trent 'Lathiat' Lloyd (トレント)

[ website | lathiat dot net ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Round-up of options for disabling Mac OS X Lion's feature of auto-restoring windows [Nov. 9th, 2011|11:40 am]

As part of the "Back to the Mac" theme in OS X Lion (10.7) by Apple, they have taken what they have learnt from user interfaces and experience on iOS devices such as the iPhone and iPad, and tried to bring some of those concepts home to the full fledged Mac experience.



There are many changes in relation to this but one of those most noticeable, and sometimes annoying, features -- is that applications will now often restore the documents and windows you had open when you last closed them. Not only that, your entire desktop will re-open to every application and document you were last using.



While this is sometimes useful, it can also be very annoying. For myself, the most common application this bugs me with is Preview. I am quite used to building up a pile of documents in preview, only to quit it to clear them out so that next time I start them, the build-up is gone. This is also happening with Google Chrome and TextEdit.



Fortunately, there are some solutions at hand! There are two main options;



Close all windows in an application once-off


If you use the option key when selecting the application menu, you will note most applications gain a "and Close all windows" suffix on the quit item. This will quit the application and not remember the open windows.


Additionally you can simple use Apple-Option-Q as a single keyboard shortcut to close an application including all of it's windows.



Disable the feature entirely


You can wholesale disable the feature, so that no application will re-open windows and so that your desktop won't re-open applications. This is a fairly simple toggle.




  1. Select the Apple menu, then move halfway down to "System Preferences" and select it.

  2. Select the "Show All" button from the top menu bar

  3. Select the very first icon under the "Personal" category, "General"

  4. Look towards the bottom and select the option "Restore windows when quitting and re-opening apps"




Disable the behaviour on a per application basis.


It can be done manually with "defaults write" in many cases, however a free application RestoreMeNot has been developed and released which automates this behavior.


It's a free download and allows you to exclude specific applications from this behavior, in my case Preview was first cab off the rank.

LinkLeave a comment

Watch out for hostname changes when using replication! [Aug. 25th, 2009|05:40 pm]
Cross-post from my blog at sun

For one reason or another, many times we find ourselves changing the hostname of a machine. It's been repurposed or moved - or perhaps the original installer didn't know what name it should have. To achieve this on most modern Linux distributions there are 2 key files you need to update.


  1. /etc/hostname needs to be updated with correct hostname to be set on boot, and

  2. /etc/hosts needs to be updated for DNS lookups of the local hostname. This is more important than you might think and will break many applications if not updated.



Some people also take the third step of updating the hostname on the fly with the 'hostname' tool, which if you do that means the gotcha I'm about to describe take you completely unaware in some weeks or months.

If you are using MySQL replication, there are two key options which depend on the hostname. These are the 'log-bin' and 'relay-log' for the binary log and binary log replication log paths respectively. The problem is not only do the logs themselves depend on the hostname, so does the index which tells you where to find them. So if you restart the server, it will look for a new index file and won't find it - causing errors such as:

090825 17:17:15 [ERROR] Failed to open the relay log './mellie-relay-bin.000002' (relay_log_pos 339)
090825 17:17:15 [ERROR] Could not find target log during relay log initialization


There are several possible solutions to this, one involves combining the old and new files (which you can find documented here - but that's a more pro-active approach. The second is to completely restart the replication process - which in my opinion, is cleaner. So I will detail that approach.

First we need to stop the slave process, just to make sure.

mysql> STOP SLAVE;


Then we can get the slave status, to see what position the master is currently. You can see what that looks like here. The important values to note are the following two:

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Master_Host: localhost
Master_User: root
Master_Port: 3306
Relay_Master_Log_File: gbichot-bin.005
Exec_Master_Log_Pos: 79


These values tell us what the current position in the master's binary logs the slave has executed up to as well as the basic master details. The reason this is important is we are going to tell the slave to completely forget about it's current replication information and fetch the data fresh.

While normally you could just change the master log file and position, since it can't open the relay log at all - the slave replication does not start and we must completely reset and specify all of the details again. The above information contains everything you need except the password for the replication user. You can find that by reading either the 'master.info' file or by prior knowledge.

ERROR 1201 (HY000): Could not initialize master info structure; more error messages can be found in the MySQL error log


To reset that, we run RESET SLAVE like so:

mysql> RESET SLAVE;


Then we run we need to construct a CHANGE MASTER statement with the above information.

In our case the statement is
mysql> RESET SLAVE;
mysql> CHANGE MASTER TO MASTER_HOST="localhost", MASTER_USER="root", MASTER_PASSWORD="test", MASTER_LOG_FILE="gbichot-bin.005", MASTER_LOG_POS=79;

... but be sure to use your own values from the SLAVE STATUS and make sure the log and position are from Relay_Master_Log_File and Exec_Master_Log_Pos - there are other values that look similar so don't confuse them. Once this is done we can start the slave, and check the status to make sure it is replicating correctly.

mysql> START SLAVE;
*wait a few moments*
mysql> SHOW SLAVE STATUS\G


When the slave status is displayed, make sure that both the IO and SQL threads are running and there are no errors.


mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 8


Also keep an eye on the Seconds_Behind_Master value and make sure that it is reducing to 0.


That's this weeks situation. If you do change your hostname, it pays to reboot your machine to make sure everything has worked and that issues will not pop up down the track when your machine is unexpectedly rebooted by a crash or some other circumstance. You don't need unexpected changes causing problems!

This applies to any situation where you might change a configuration file, but making it's effects current are done separately. This is very common in MySQL, where you might want to change a dynamic variable and also edit the my.cnf file. If you make a syntax error, you won't know until your server reboots. So it helps to be very careful and preferably do the actual MySQL or server reboot.
Link7 comments|Leave a comment

Checking ldirectord is alive [Jul. 24th, 2009|01:20 pm]
[Tags|, , ]
[Current Mood |accomplishedaccomplished]

This week's blog post is not strictly to do with MySQL, but a little more to do with highly available clusters using heartbeat and ldirectord

While many people use heartbeat with MySQL, ldirectord usage is less common in these scenarios and more often using in clustered web and mail servers. It is however sometimes used with a selection of MySQL slave servers.

ldirectord is a tool that manages IPVS in the kernel. Essentially you give it a list of servers that act as a "cluster" for a service, for example, 2 web servers. It will then setup the linux load balancer IPVS to direct to these 2 machines. However, what it does is keeps monitoring the servers, and if one of them goes away, it removes them from the cluster pool.

The problem I have run into a number of times, is that ldirectord gets stuck and stops monitoring services. However when it does this, then services stop getting updated, and if a service goes down, it won't be removed from the cluster. On top of that, I have had it get stuck on START UP, after a failover, in this case not many of the services had a chance to come up yet, and you are stuck with a cluster often with 0 nodes available to service some requests - which causes downtime.

So last night, Shane Short and myself wrote a patch to ldirectord and a nagios plugin, in order to make sure that ldirectord is doing it's job and hasn't got stuck. It works by hooking into ldirectord's '_check_real' function, which is called whenever a server is checked. It will then adjust the timestamp on a 'pulse' file, which we later check with our nagios script.

Here is the patch to ldirectord: http://lathiat.net/files/ldirectord.patch

So now, in the default configuration we will end up with a file at /var/run/ldirector.ldirectord.pulse (this file is actually in the same location as your ldirectord PID file, so if you have moved that, it will be with it) which has it's timestamp updated with each service check.

Now, we make a plugin for nagios, which I have here:

http://lathiat.net/files/check_ldirectord_pulse

And you can configure this plugin into Nagios or Nagios NRPE as normal. You can test it is working by running the plugin manually, you should have a result like this;


OK: ldirectord pulse is regular (4 seconds since last beat)


The default timeout is 120 seconds (2 minutes) for a warning, and 300 seconds (5 minutes) for a critical alert.

Hope this helps some people using ldirectord! Personally this has caused downtime for ourselves a few times when ldirectord got stuck. I would love to hear any feedback or if you are successfully (or unsuccesfully) using this, you can contact me here:
http://lathiat.net/contact
Link1 comment|Leave a comment

At Linux.conf.au 2009 and starting on Planet MySQL [Jan. 19th, 2009|12:11 pm]
[Tags|]
[Current Location |Hobart, Tasmania]
[Current Mood |excitedexcited]

Greetings Planet MySQL readers,

I am new to Planet MySQL.. so I thought I should introduce myself.

I am Trent Lloyd (some may know me online as 'lathiat'), based in Perth, Western Australia and presently working for Sun Microsystems as a MySQL Support Engineer providing support to Sun's MySQL customers. I have been with Sun for 12 months, and previous to that was working for MySQL AB before it was acquired for 8 months. My background before that is in the ISP industry working for HostAway in a combination System/Network administration and support role.

I have also given a number of papers, often related to either Avahi or IPv6 at a few conferences.. mainly Linux.conf.au - you can view them on my web-site www.lathiat.net.

I have an open-source/free-software community background.. I co-authored Avahi (a mDNS/DNS-SD/Link-Local IP stack for Linux and other *nixes) with Lennart Poeterring and dabbled my hand in the likes of the Ubuntu MOTU and GNOME communities.

Working in the MySQL Support Team, and having a very large customer base to source problems from, we run into many problems and gotcha's on our customer systems which people don't hit every day but are very difficult to track down when you do. I hope that by sharing some of these experiences


With that introduction out of the way, I have just landed in Hobart, Tasmania, Australia to attend linux.conf.au (which was a very last minute arrangement). I have attended this conference every year since 2003 (thats 7 of them!), it's always great and I am glad I am able to attend again.

I am sitting at the "Open Source Databases" mini-conference which has a strong MySQL presence. There are quite a few Sun folk here, which is fantastic - unfortunately a few others were unable to make it but it should be great never the less.

I will be bringing you more Linux.conf.au updates throughout the week and MySQL tips into the future!
Link6 comments|Leave a comment

Avahi is now 3 years old... [Aug. 25th, 2008|03:07 pm]
[Tags|]
[Current Location |sYra]
[Current Mood |accomplishedaccomplished]
[Current Music |Linkin Park - No More Sorrow]

I just noticed that as of a few days ago (22nd August) - Avahi is now 3 years old.

Heres my original release announcement:
http://lists.freedesktop.org/archives/avahi/2005-August/000227.html

That's a crazy amount of time, since then I presented at Linux.conf.au 2006 and GUADEC 2007 (Birmingham) as well as some presentations at GNOME mini-confs and the like.

Fun and games... also for anyone following this blog, I regularly twitter as lathiat
http://twitter.com/lathiat

Feel free to follow me, but it tends to be more personal stuff rather than Tech/Open-Source related
LinkLeave a comment

navigation
[ viewing | most recent entries ]
[ go | earlier ]