如何在Lion中加快终端启动速度？

我指的不是终端应用程序的启动，而是指启动终端窗口，例如当我打开一个新选项卡时。

我的.bash_profile文件中没有任何内容，并且rm -rf /private/var/log/asl/*.asl每4小时运行一次（这会清除那些通常会使终端运行缓慢的文件）。

目前，当我打开一个新选项卡时，需要3-4秒才能运行某些内容。

简短答案：

该问题是由（可能）昂贵的ASL系统日志查找引起的。要查看实际效果，请sudo fs_usage | grep 'asl.*login'在“终端”窗口中运行，然后打开一个新的“终端”窗口。

要解决此问题，请将终端配置为启动非标准外壳程序：

1. 创建到首选外壳的符号链接。例如：sudo ln -s /bin/bash /usr/local/bin/bash
2. 打开终端首选项，然后选择“常规”选项卡。
3. 选择“ Shells with with：Command”，然后输入在步骤1中创建的符号链接。例如，“ / usr / local / bin / bash”。

注意1：您可能还需要在“终端首选项>配置文件> Shell>关闭前询问”处添加bash和-bash到过程列表。

注意2：/usr/local/bin在OS X 10.11（El Capitan）无根模式下可写。

要验证此修复程序：

• 打开一个新的终端窗口。
• “上次登录：”应该不会在顶部显示
• 打开检查器（Command + I），然后选择“信息”选项卡。
• 该命令应读取login -pfq username /usr/bin/bash或login -pfql username ...

要点：如果login命令不包含-q参数，则您尚未解决问题。

您还可以sudo fs_usage | grep 'asl.*login'用来验证/var/log/asl在打开新的“终端”窗口时未访问该文件。

细节：

这里有许多错误。

速度缓慢的实际原因是/usr/bin/login，默认情况下会显示您上次登录的日期。要获取最后的登录日期，它将在处搜索ASL（Apple系统日志）数据库/var/log/asl/。这些日志文件的碎片可能非常严重，正是这种文件碎片导致了打开新窗口或标签时的延迟。（错误1）

禁止ASL搜索最后一次登录的唯一方法是将-q参数传递给/usr/bin/login。该.hushlogin文件还将禁止显示“上次登录”，但不会禁止进行昂贵的ASL搜索。（错误2）

终端始终用于/usr/bin/login启动每个新窗口/外壳。没有直接启动外壳的选项，也没有直接控制传递给参数的方法/usr/bin/login（错误3）。

事实证明，当配置为使用非标准外壳程序时，终端会将-q参数传递给。（错误4）/usr/bin/login

该-q参数是我们需要避免的问题，因此符号链接/usr/local/bin/bash。

我需要/bin/bash -il 在iTerm的Preferences> Profiles> General> Command中从登录shell更改为Command。

我需要添加选项-l（使bash像被作为登录shell一样被调用）以设置环境变量~/.bash_profile

.hushlogin

在您的主文件夹中创建一个名为的空文件.hushlogin。这将大大减少Terminal.app选项卡出现的时间。

您可以.hushlogin使用以下命令在Terminal.app中创建文件：

touch ~/.hushlogin

该文件将立即生效。

您.hushlogin通常可以在登录手册中了解有关文件和登录过程的更多信息。

减少登录过程

创建新的“终端”选项卡时，您将经历登录过程。该过程涉及获取有关您以前的登录会话的各种信息，当天的消息以及显示系统消息。这可能是严重延迟的根源。尝试隐藏这些消息以查看延迟是否消失。

好的，我的结论与Darren类似，但分析机制略有不同（NB慢速登录仍可能在优胜美地发生）。

这里有一个办法告诉什么是实际运行，当你开始一个新的登录窗口，使用OS X 样本分析器命令。

找出正常登录执行的命令

$ ps -ef | grep login

你会看到类似的东西 login -pfl username /bin/bash -c exec -la bash /bin/bash

profile_login.sh通过添加以下内容来创建具有以下内容的脚本文件名：

-c ""

到发现的命令末尾，要求bash立即返回，内容如下：

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

使它可执行

$ chmod u+x profile_login.sh

并使用sudo运行它（sample命令需要它）

$ sudo ./profile_login.sh

好的，所以继续运行它。例如，purge首先执行命令。在我的盒子上，我有一个很大的输出图。在寻找“编号最大的分支”（通常在顶部）时，我看到了以下两个最大的罪犯：

从一种叫做pam_start打开pam auth lib映像的东西

+   ! 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]

有时又有另一个罪犯 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]

因此，基本上有两个罪犯。一种是pam（某种类型的身份验证系统），另一种是asl“检测您的最新登录信息”。因此，显然仅删除/private/var/log/asl/*.asl文件是不够的。反正[SSD]，在我的机器上，pam加载要昂贵得多。随意运行上面的脚本，看看您的系统是否相同。有趣的是，这些方法调用的源代码似乎也可以在线获得，例如openpam_dynamic

如果我遵循Darren的回答，并且将我的“用...打开shell”首选项替换为/ bin / bash以外的其他内容，那么我将看到以下用于启动新终端选项卡的行：

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

因此，如果我现在sample在新的登录命令上使用相同的技巧

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

生成的堆栈跟踪小得多，最大的违法者是：

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

我认为这是因为现在正在使用登录“ -q”参数。显然，此参数将跳过加载pam模块和查找上次登录时间（两个违规者）的过程。根据login命令的文档，触摸~/.hushlogin文件应该做同样的事情，但是显然这不再起作用了（至少对我来说是10.10）。

因此，总的来说，删除/private/var/log/asl/*.asl是不够的（在我的实验中，它最多仅占实际运行速度的1/3，尽管如果那里有更多文件，它可能会导致我确信百分比更高）。

无论如何，使用类似的脚本，您都应该能够知道导致本地计算机崩溃的原因，并查看上述修复程序是否适用于您。在这里随意发表评论。

更新：coresymbolication_load_image即使login -pfql被调用，似乎仍可能要花费大量时间（大概是某些pam身份验证模块或其他必须“拨出”到中央登录服务器或有些奇怪，因此必须等待第三方的响应）。因此，我发现的唯一真正的解决方法是使用iTerm2，然后将首选项->配置文件->常规->命令/bin/bash改为。

这完全是调查原因。您可以通过输入来查看启动过程的过程，bash -x这将打印出启动Shell的过程。

就个人而言，我只注意到在激活和停用该应用程序之间以及在一段时间的活动后创建的第一个选项卡中存在延迟。总是让我觉得这是关于内存页面的移动。

将历史记录减少到4到1万行之间，然后尝试退出并丢弃所有已保存的窗口。我已经看到两者在速度较慢的计算机上都有所不同-尤其是那些没有SSD存储的计算机。

就我而言，在我的工作机上尝试上述操作失败后，我发现罪魁祸首是Active Directory。解决方法是进入Directory Utility并编辑AD服务设置（双击“ Active Directory”）以启用“在登录时创建移动帐户”：

显然，这会导致AD凭据在本地缓存，因此系统不再需要在每次尝试验证密码时都去服务器。

您可以使用Spotlight或通过“系统偏好设置/用户和组”的“登录选项”部分进入目录实用程序（选择“网络帐户服务器”旁边的“编辑…”按钮）：

赶紧跑：

sudo creatbyproc.d
sudo newproc.d

在单独的终端中打开新的打开以查看在这段时间内正在执行的操作。

如果不明显，请尝试以下操作：

sudo dtruss -an Terminal

这将打印您在选项卡加载时间上发生的所有详细信息。

打开/etc/profile并添加该行PATH=""，使其如下所示：

if [ -x /usr/libexec/path_helper ]; then
    PATH=""
    eval `/usr/libexec/path_helper -s`
fi

对我来说，问题是活动目录域服务器无效。

更改它，然后重新启动mac即可修复它。