Ask Different is a question and answer site for power users of Apple hardware and software. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

10 Answers 10

If you're facing this issue as a Zsh Iterm2 user do this:

Preferences >Profiles >General >Command: /bin/zsh -il

share|improve this answer

Short Answer:

The problem is caused by a (potentially) expensive ASL system log lookup. To see this in action, run sudo opensnoop | grep login in a Terminal window, then open a new Terminal window.

To solve the problem, configure Terminal to launch a non-standard shell:

  1. Create a symlink to your preferred shell. E.g.: sudo ln -s /bin/bash /usr/local/bin/bash
  2. Open Terminal Preferences and select the "General" tab.
  3. Select "Shells open with: Command" and enter the symlink you created in step 1. E.g. "/usr/local/bin/bash".

Note 1: You may also need to add bash and -bash to the process list at "Terminal Preferences > Profiles > Shell > Ask before closing".

Note 2: /usr/local/bin is writable in OS X 10.11 (El Capitan) Rootless mode.

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.

You can also use sudo opensnoop | grep login to verify that /var/log/asl is not accessed when opening a new Terminal window.


There are a number of bugs at play here.

The actual cause of the slowness is /usr/bin/login, which by default 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. (Bug 1)

The only way to suppress the ASL search for last login is to pass the -q parameter to /usr/bin/login. The .hushlogin file will also suppress the "Last Login" display, but it does not suppress the expensive ASL search. (Bug 2)

Terminal always uses /usr/bin/login to launch each new window/shell. There is no option to launch a shell directly nor is there a way to directly control the parameters passed to /usr/bin/login (Bug 3).

As it turns out, Terminal will pass the -q parameter to /usr/bin/login when it is configured to use a non-standard shell. (Bug 4)

The -q parameter is what we need to avoid the problem, hence the symlink to /usr/local/bin/bash.

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? – user495470 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
@Darren have you reported this suspected bug to Apple? If not, please could you do so through: – 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
Unfortunate, this results in a promt about bash running every time you close the terminal on Yosemite. So not a nice fix :( – Claus Jørgensen Dec 13 '14 at 1:55

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 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

and run it using sudo (sample command requires it)

$ sudo ./

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 a greater percentage 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.

UPDATE: seems that coresymbolication_load_image can still take tons of time, even when login -pfql is invoked (presumably some pam authentication module or other is having to "dial out" to a central login server or some odd, so has to wait for a response from a 3rd party). So the only real workaround I have found is to use iTerm2, which avoids the login command all together, apparently, at startup, though they both call what they call a "login shell" it appears they are different somehow, and the "login shell" for iterm2 appears to not have the delay Terminal does (my guess is it calls bash -l for login, which is apparently different than calling the /usr/bin/login that Terminal forces you to always use seemingly).

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 '15 at 3:38
@ChrisPage Yeah probably some network directory services something or other, good tip. – rogerdpack Mar 20 '15 at 16:56

In my case, after trying the above on my work machine without success, I found that the culprit was Active Directory. The fix was to go into Directory Utility and edit the AD service settings (double-click on "Active Directory") to enable "Create mobile account at login":

screenshot of Directory Utility application w/Active Directory settings open

This apparently causes the AD credentials to be cached locally, so the system no longer has to go out to the server every time it tries to validate your password.

You can get to Directory Utility with Spotlight or via the "Login Options" section of System Preferences / Users & Groups (select the "Edit…" button next to "Network Account Server"):

Users & Groups pane showing "Login Options" and "Edit…"

share|improve this answer

What I needed was changing from login shell to command /bin/bash -il in the preferences=>profiles=>General=>Command settings of iTerm2.

I needed the option -l Make bash act as if it had been invoked as a login shell added in order to set environmental variables from ~/.bash_profile

share|improve this answer
Which stops the login search of ASL as per the accepted question – Mark Jul 11 '15 at 12:25
out of all the solutions, this one worked for me. +50! – Aug 29 '15 at 10:46
Great information all around in this thread! This is the solution I used because it didn't require creating symlinks or anything. My new shell startup times have gone from ~5-10seconds to instant with this solution. – DustinB Nov 22 '15 at 13:30

Open /etc/profile and add the line PATH="" so it looks like this:

if [ -x /usr/libexec/path_helper ]; then
    eval `/usr/libexec/path_helper -s`
share|improve this answer

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

Create an empty file in your home folder called .hushlogin; this will significantly decrease the time it takes for a 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 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
@Darrren: man login tells me: -q This forces quiet logins, as if a .hushlogin is present. The q option is what you say prevents the issue, but it just does the same as with hushlogin. – Christian Oct 13 '15 at 17:15

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

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.