Tomasz Korwel
programmer, administrator, engineer – my everyday fights with reality

Recently while working in Zend Studio I had couple of crashes that I finally traced down to it running out of memory. After searching around I found that you can bump up it’s default settings by editing it’s .ini file.

The file is located in /Applications/Zend Studio.app/Contents/MacOS


# cat ZendStudio.ini
--launcher.XXMaxPermSize
256m
--launcher.defaultAction
openFile
-showlocation
-name
Zend Studio
-vmargs
-Xms512M
-Xmx1536M
-XX:MaxPermSize=256m
-DGIT_SSL_NO_VERIFY=true
-Dsvnkit.http.sslProtocols=SSLv3
-Djava.awt.headless=true
-XstartOnFirstThread
-Dorg.eclipse.swt.internal.carbon.smallFonts
-Xdock:icon=../Resources/mac.icns


The settings that you need to bump are Xms and Xmx (in case above they are already bumped up.

My Zend Studie has not crashed since. Happy coding!

I’ve been using Postgres db server for years in my day job. And for all those years I had a third party server installed on my Mac. But since Apple started bundling Postgres in Os X system I was thinking of ways to start using that one. Unfortunately it seems that Apple decided to make using it as hard as it’s possible so getting it to work needed some hacking.

The application I’m working with accesses db via network connection on localhost. So I needed to turn on listening on network interfaces. Postgres keeps it’s config file in /Library/Server/PostgreSQL/Data folder. You can find postgres.conf there. You need to edit this file and change two lines to show this:


port = 5432 # (change requires restart)
listen_addresses = '*' # what IP address(es) to listen on;


quick server restart:


# sudo serveradmin stop postgres
postgres:state = "STOPPED"
# sudo serveradmin start postgres
postgres:state = "RUNNING"


and… no luck. Still no connections are accepted on network interface. Checking settings:


# sudo serveradmin settings postgres
postgres:log_connections = "on"
postgres:unix_socket_directory = "/var/pgsql_socket"
postgres:listen_addresses = ""
postgres:unix_socket_group = "_postgres"
postgres:log_statement = "ddl"
postgres:log_line_prefix = "%t "
postgres:unix_socket_permissions = "0770"
postgres:log_lock_waits = "on"
postgres:logging_collector = "on"
postgres:log_filename = "PostgreSQL.log"
postgres:dataDir = "/Library/Server/PostgreSQL/Data"
postgres:log_directory = "/Library/Logs/PostgreSQL"


Shows that the listen_address parameter got somehow overwritten. It turns out that the server stores some parameters in plist files and those get priority over anything you set in postgres.conf file.


# sudo serveradmin set postgres:listen_addresses="*"
postgres:listen_addresses = "*"


changes that and now my application can access built in Postgres server on localhost.

But how about command line tools? Apple sets things up in a way that Postgres accepts socket connection only from users that belong to _postgres group. Now I needed to add myself to that group using dseditgroup command:


# sudo dseditgroup -o edit -a usertoaddtogroup -t user _postgres


and voila! I’ve gut running instance of Postgres (9.1.5) accepting connection from my application and letting me use all command line tools.

Inspired by an Jinx’s article about building your own Apple fusion drive I’ve decided to take it one step further and brew my own with full Os X installation on it.

Here is how I did it.

First things first, I needed to put two drives in my Mac. I already had Crucial M4 SSD and 500GB HDD so I bought hard drive caddy and put my 500GB Momentus XT in it:

Here you can see both my SSD and HDD installed in late 2010 unibody MacBook Pro:

That was the easy part. Now how to make them work? I Jinx’s article you can read that GUI Disk Util does not offer needed functionality. It’s available only in command line version. But from my previous installation I remembered that there is acces to terminal in Os X recovery mode:

It was downhill from there. Create Logical Volume Group:

get UUID:

Create volume:

As you can see Os X Installation recognized such volume:

and installed nicely. After the whole process was over I’ve done similar to Jinx’s tests and the drive indeed behaves like fusion – more often used files end up on the SSD and less needed are being shuffled to the HDD.

Mission accomplished!

Requires small fix.

Here are details.

Also it seems that upgrade removed zend user:
sudo /usr/local/zend/bin/zendctl.sh restart
id: zend: no such user
id: zend: no such user
id: zend: no such user
id: zend: no such user
id: zend: no such user
id: zend: no such user
id: zend: no such user
id: zend: no such user
id: zend: no such user
id: zend: no such user
zdd is not running

So reinstall is in order anyway :-(

I can’t remember how many times I needed this line recently. I also could never remember it (hm… do you see a pattern here?). So here it is for future reference:

find . -name "*.php" -print | xargs sed -i '.backup' 's/foo/bar/g'

It’s pretty much self explanatory. If I could only make it stick in my brain.