Take the 2-minute tour ×
Ask Different is a question and answer site for power users of Apple hardware and software. It's 100% free, no registration required.

How can i speed up the terminal startup in Lion?

I'm not referring to the startup of the Terminal application, but to the startup terminal windows, like when i open a new tab.

I don't have anything in my .bash_profile file and i run rm -rf /private/var/log/asl/*.asl every 4 hours (which clear those files that usually make terminal slow ).

Currently, when i open a new tab, it takes 3-4 seconds until i can run something.

share|improve this question
Perhaps there is something else wrong with your system? It shouldn't be that slow. Sometimes it takes a second or two for me, but usually it's only a split second. And I have a fair bit in .bash_profile (also check ~/.profile by the way). Also: note you can start typing while bash is loading, and usually what you type will be copied to the command prompt once it's ready. –  Abhi Beckert Feb 26 '12 at 0:44
Are you using a network account or a network home directory? Is Terminal responsive to user input while it's creating the terminal? Does it display the spinning busy cursor? –  Chris Page Feb 26 '12 at 11:56
To find out where Terminal is spending the time, open Activity Monitor, select Terminal and click the Sample Process toolbar button, then immediately go to Terminal and create a new window/tab. The sample may provide a clue as to where the time is going. Also, watch the process list in Activity Monitor: if "login" or "bash" (or whatever shell you're using) appear in the list during the delay, that means the delay is likely occurring in one of those two programs and not Terminal. –  Chris Page Feb 26 '12 at 11:58
Have you checked your PATH variable? I noticed that mine was absurdly long with many repeats due to some confusing .bashrc going-ons. I removed the repeats and everything sped up! –  190290000 Ruble Man Mar 27 '14 at 22:47

6 Answers 6

Short Answer:

  • Open Terminal Preferences
  • Select the Startup tab
  • Select "Shells open with: Command", and use "/usr/bin/bash" as the command.

Important: Do not use "/bin/bash" as the startup command (apparently it still does last login lookup functionality if you leave it as the default). If "/usr/bin/bash" does not exist on your system, create a symbol link like this: sudo ln -s /bin/bash /usr/bin/bash

To verify the fix:

  • Open a new Terminal window.
  • "Last Login:" should not be displayed at the top
  • Open the inspector (Command + I) and select the Info tab.
  • The command should read login -pfq username /usr/bin/bash or login -pfql username ...

Important: If the login command does not include the -q parameter, then you have not fixed the problem.


Terminal uses /usr/bin/login to launch each new window/shell. By default, /usr/bin/login will display the date of your last login. To get this last login date, it searches the ASL (Apple System Log) database at /var/log/asl/. These log files can be very heavily fragmented and it's this file fragmentation that causes the delay when opening a new window or tab.

To see this in action, run sudo opensnoop | grep login in a Terminal window, then open a new Terminal window.

To prevent /usr/bin/login from doing this ASL search, you must pass the -q parameter. The only way Terminal will pass the -q parameter is when you specify a custom shell command in the Preferences.

Note: .hushlogin does not prevent /usr/bin/login from doing the ASL search. This can be confirmed by using the opensnoop command above.

share|improve this answer
Do you know why -q is added if the command is a symlink to /bin/bash but not if it's /bin/bash? –  ؘؘؘؘ Nov 18 '12 at 15:16
@LauriRanta It seems to be a bug in the 10.7 and 10.8 Terminal. When the startup command is set to /bin/bash it behaves as if the Default Login Shell was selected. Any command other than /bin/bash will work correctly, so using /usr/bin/bash is just a workaround. This bug is not present in Snow Leopard. –  Darren Nov 18 '12 at 15:34
This is really great and helpfull answer. For me, I was having the same issue on my MacBook Pro. I just changed the settings jast as above and the terminal start up fixed again. What is surprising me that : I then rechanged it back to the original settings. And it is still very fast. Weird bug needs to be solved by Apple. ( OS X 10.8.2 ) –  Olgun Kaya Dec 28 '12 at 5:53
@Darren have you reported this suspected bug to Apple? If not, please could you do so through: bugreport.apple.com –  Graham Miln Dec 31 '12 at 16:55
Whats exactly the trick for bash to run from /usr/bin/bash ? –  Ansd Oct 22 '13 at 22:40

Create an empty file in your home folder called .hushlogin; this will significantly decrease the time it takes for a Terminal.app tab to appear.

When you create a new Terminal tab, you are going through the login process. The process involves fetching various information about your previous login session, message of the day, and displaying system messages. This can be the source of significant delays. Try hushing these messages to see if the delay disappears.

You can create the .hushlogin file in Terminal.app using the following command:

touch ~/.hushlogin

The file will take effect immediately.

You can learn more about the .hushlogin file and the login process in general in the login manual.

share|improve this answer
.hushlogin does not actually solve the problem. This can be confirmed by using opensnoop. See my answer below. –  Darren Nov 18 '12 at 11:47

Reduce your history to something between 4 and 10 thousand lines and perhaps try quitting and discarding all saved windows. I have seen both make a difference on slower machines - especially ones without SSD for storage.

share|improve this answer

It is all about investigating the cause. You can see what's being done while the process starts by inputing bash -x which will print out the process of starting up the shell.

Personally, I only notice the delay between activation and de-activation of the app and in the first tab created after a period of activity. It always makes me think that it is about memory pages being moved around.

share|improve this answer

OK I have a similar conclusion to Darren, though slightly different profiling mechanism (NB slow login can still occur in Yosemite).

Here's a way to tell what is actually running when you start a new login window, using the OS X sample profiler command.

Find out what command a normal login executs

$ ps -ef | grep login

You'll seee something like login -pfl username /bin/bash -c exec -la bash /bin/bash

Create a script file name profile_login.sh with the following contents by adding a

-c ""

to the end of the discovered command to request that bash return immediately, with contents like this:

login -pfl username /bin/bash -c exec -la bash /bin/bash -c "" &
sudo sample $! -mayDie # sample the above command

Make it executable

$ chmod u+x profile_login.sh

and run it using sudo (sample command requires it)

$ sudo ./profile_login.sh

OK so go ahead and run it. For instance by executing the purge command first. On my box, I got a large output graph. Looking for the "biggest numbered branches" (typically at the top) I saw the following two biggest offenders:

One from something called pam_start which appears to opening pam auth lib images

+   ! 1068 pam_start  (in libpam.2.dylib) + 132  [0x7fff97295ab0]
+   !    :   1066 openpam_dynamic  (in libpam.2.dylib) + 120  [0x7fff97293d14]
+   !    :   |   +   !   1042 coresymbolication_load_image(CSCppDyldSharedMemoryPage*, ImageLoader const*, unsigned long long)  (in dyld) + 143  [0x7fff66725411]
+   !    :   |   +   !   :     1042 mach_msg_trap  (in dyld) + 10  [0x7fff6674a472]

and that is sometimes followed by another offender getlastlogxbyname

+   ! 583 getlastlogxbyname  (in libsystem_c.dylib) + 212  [0x7fff92b3ef7a]
+   !       : 566 asl_file_open_read  (in libsystem_asl.dylib) + 143  [0x7fff8c27030d]
+   !       : | 566 __open_nocancel  (in libsystem_kernel.dylib) + 10  [0x7fff97b39012]    +   !       : | 566 __open_nocancel  (in libsystem_kernel.dylib) + 10  [0x7fff97b39012]

So basically, there are two offenders. One is pam (some type of authentication system) and the other it the asl "detect your latest login" stuff. So apparently just deleting your /private/var/log/asl/*.asl files is not enough. The pam loading is much more expensive on my machine, anyway [SSD]. Feel free to run the above script and see if your system is the same. Interestingly, the source code for these method calls seems to also be available online, for instance openpam_dynamic

If I follow Darren's answer, and replace my "shells open with" preference to something other than /bin/bash, I then see the following lines used to start new terminal tabs:

 $ ps -ef | grep login
  ... login -pfql packrd /bin/bash -c exec -la bash /usr/bin/bash

So if I now use the same sample trick on the new login command

login -pfql username /bin/bash -c exec -la bash /usr/bin/bash -c "" &
sudo sample $! -mayDie

a much smaller stacktrace is generated, the biggest offender being:

+         8 pam_end  (in libpam.2.dylib) + 190  [0x7fff97294ebb]
+             !           6 coresymbolication_unload_image(CSCppDyldSharedMemoryPage*, ImageLoader const*)  (in dyld) + 143  [0x7fff6e0f634f]

I think this is because the login "-q" parameter is now being used. Apparently this parameter skips both loading the pam modules and looking up the last login time (both offenders). According to the docs of the login command, touching the ~/.hushlogin file should do the same thing, but apparently this no longer works [at least for me with 10.10].

So, in summary, removing /private/var/log/asl/*.asl is not enough (in my experiment, it only accounted for at most 1/3 of the actual slowdown, though if you had mores files there it could account for more I'm sure).

Anyway using similar scripts, you should be able to tell what's causing your local machine to bog down, and see if the above fix applies to you. Feel free to comment here.

share|improve this answer
Apart from the ASL lookup, delays in login are most-often caused by being on a network with a directory server that is responding slowly when asked for your user info. If you're not on a network with directory services enabled, then I don't know what else would take significant time, other than general system congestion (CPU usage, memory pressure, I/O congestion). –  Chris Page Mar 20 at 3:38
@ChrisPage Yeah probably some network directory services something or other, good tip. –  rogerdpack Mar 20 at 16:56

Just run:

sudo creatbyproc.d
sudo newproc.d

in separate terminals and open the new open to see what is being executed during that time.

If nothing obvious, try the following:

sudo dtruss -an Terminal

This will print all your details which are happening on tab loading time.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.