One of the new features that was introduced in OS X Lion is automatic application termination. This feature stops any applications that haven’t been used for awhile and then when you start the app back up, it fires up using the saved application state
. But some processes shouldn’t be stopped. I’ve recently run into 2 cases where I needed to disable automatic termination. To do so is pretty straight forward:
defaults write -g NSDisableAutomaticTermination -bool TRUE
Once run, read the key back from the global defaults domain to verify it was run correctly:
defaults read -g NSDisableAutomaticTermination
The output should just be a 1. Provided it’s correct, now test that applications no longer automatically terminate. Provided they don’t then the setting can be left, or if your issue persists then you can just delete the key:
defaults delete NSDisableAutomaticTermination
While you shouldn’t have to restart for changes to activate, I do. Basically, at the relaunch of the app the changes should be active. Applications with network sockets should never stop taking resources; however, applications without network sockets that might call on them from time to time could be impacted. You can also look at doing per-application, as an example with Terminal:
defaults write com.apple.terminal NSDisableAutomaticTermination -bool true
Or Apple Configurator:
defaults write com.apple.terminal NSDisableAutomaticTermination -bool true
krypted June 3rd, 2012
Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment
apple configuration, disable automatic termination, Finder, nsdisableautomatictermination, RAM, saved application state, terminal, utilization, zombie processes
I can’t remember where I picked up how to get a RAM Disk mounted in OS X, but it’s a great way to get some unbelievable speeds on your Mac for those minor IO intensive processes that don’t need persistent data. It should be mentioned that the contents of RAM disks are erased, once ejected, but the speed of processes while they’re running can be pretty phenomenal on systems with fast RAM. The best example is a MacBook Air, where the memory is surface-mounted QFP and so really fast.
Let’s say you have 4GB of memory and you want to run a process that isn’t going to take more than a gig of memory. You have 3GB of memory you can then use as a RAM Disk. To mount up the RAM disk, I usually create a .command file with the following contents:
diskutil erasevolume HFS+ "rdisk" `hdiutil attach -nomount ram://6144000`
I usually call that file mountrdisk.command
Then I create another .command file called unmountrdisk.command with the following:
hdiutil detach /dev/disk1
These allow me to mount and unmount the RAM disk, quickly. I then add a line at the top of the second command file to backup the contents to a folder on my local computer, since anything in there doesn’t get saved once detached:
cp -R /Volumes/rdisk ~/rdiskbackup
Running the first .command file will create the rdisk with the following output:
Started erase on disk1
Initialized /dev/rdisk1 as a 3 GB HFS Plus volume
Finished erase on disk1 rdisk
You can then cd into it and treat it as you would any other volume. Once you’re done, run the backup command file and then the unmount command file to back it up and trash it. Speed tests show anywhere from 325 MB/s to well over a thousand according to what you are doing. The performance can degrade quickly in some cases, but when used properly it’s a great little tool.
krypted July 13th, 2011
Posted In: Mac OS X, Mac OS X Server
10.6, 10.8, diskutil erasevolume HFS+, hdiutil attach, hdiutil detach, Leopard, Lion, Mac OS X, os x, RAM, RAM Disk, Snow Leopard
Portable Homes allow a user to disconnect their system from the network and continue working. But Mobility, Portable Home Directories and other network sync accounts have a major shortcoming: they have to communicate with a server. Mostly because they rely heavily on directory services and the data that moves with a user needs to synchronize between computers that the user moves to. In the event that users have large home directories or a lot of multi-media content, this can create a lot of network saturation. In large environments where there are no limits on how big these directories can get, this can also be cumbersome to storage.
Apple recently released external accounts. An external account can live anywhere (ie – a flash drive or a Firewire drive) and keep all of the data for a user (account information and home directories) in a centralized location, without the need of a directory service. This means that you could theoretically issue all of your users a 32GB jump drive, give them more space than you likely could have otherwise given them and allow them to take their data home or move it between computers without being on a network or communicating with a directory server.
In many environments, moving data between multiple computers can cause an issue with applications. You see, in many environments, not all applications are installed on all computers. Which is where OS X Portable Application
comes into play. OS X Portable Application is an open source product that allows you to put an application on a jump drive and move it between computers, much as you would do leveraging an automount in a directory services environment. The application does not need to be installed on any given computer but instead runs directly off of the portable media. I’ve only looked at open source applications running on top of OS X Portable Application, but given that the open source alternatives to all the common Mac OS X software is available it doesn’t seem like a stretch to think that it is feasible that you could do a mass deployment leveraging external accounts + OS X Portable Application and supply users with jump drives, creating a fully consumerized and streamlined network environment. In our testing though, it might not be wise to expect kindergartners to keep up with jump drives… And you might expect that those provided to preschoolers will end up with teeth marks!
Applications that can currently be made portable:
- Address Book
- X-Chat Aqua
krypted December 21st, 2009
Posted In: Mac OS X, Mass Deployment
external accounts OS X Portable Application, FOSS, jump drive, RAM
I am releasing the Xsan Monitor that I’ve mentioned as alpha code. There are still some updates I may do but for now I’m putting it out there for those who feel this is the kind of thing they can take use of. Basically, it’s a Dashboard Widget that can run on an Xsan client or metadata controller. When running it will display the CPU and RAM statistics of the Xsan processes. If it’s the kind of thing you could use then please feel free to give it a test drive and let me know what you think at email@example.com or firstname.lastname@example.org.
Xsan Monitor is available on the Apps page of krypted.com
krypted February 2nd, 2009
Posted In: Xsan
CPU, Dashboard Widget, Final Cut Server, Java, Mac OS X Server, RAM, Xsan, Xsan Monitor
Banging your head against the keyboard trying to figure out why you can’t get this install to complete… It’s a headless server, but that shouldn’t matter… Hmmmm… Well, before trying to install a system remotely, be sure the server includes 1 GB or more of memory, a G5 processor or 867 MHz or faster G4 processor (or an Intel of course). But what was killing me on this server upgrade? The 20GB hard drive requirement. OMG – is it really possible that the server had previously blown out the drive that came with it and gotten one of those old Quantum Fireballs from back in the day? Really? Who’d a thunk…
krypted April 25th, 2008
Posted In: Mac OS X Server
Mac OS X Server, minimum installation requirements, processor, RAM