6 ms·
Yet it still swaps to disk ALL THE TIME and a new Terminal.app window can take up to 5 seconds to open. That's not swapping. That delay is /usr/bin/login sear
by thought_alarm 15y ago
Yet it still swaps to disk ALL THE TIME and a new Terminal.app window can take up to 5 seconds to open.
That's not swapping. That delay is /usr/bin/login searching the system logs so that it can display the date and time of your last login.
Create a .hushlogin file in your home directory to prevent that.
- carguy1983 15y agoHALLELUJAH. Thanks.
- mistercow 15y agoWow, I'm really surprised this isn't default behavior. Knowing when you last logged in isn't nearly useful enough to justify the delay it so routinely causes.
- dustingetz 15y agoIt's worth it when you realize someone else has been logging on as you over the weekend.
- jmcnevin 15y agoWow, thank you for this. The delay caused by this behavior has been driving me crazy for a really long time.
- js2 15y agoWow, I'd forgotten how long ago I'd done this: kore:~$ ls -l .hushlogin -rw-r--r-- 1 jay staff 0 Aug 15 2002 .hushlogin
- fields 15y agoFantastic. Thanks for that.
- b3b0p 15y agoThanks a ton! This has been really bothering me lately. I could not figure out what was causing such a delay.
- netnichols 15y agoIt's painful guessing how many hours of my life I could have back if only I had known about this before. Thanks for the pain, thought_alarm.
- albertzeyer 15y agoWhen the logs are read once, they should stay in the VFS cache as long as there is enough RAM, shouldn't they? Anyway, instead of running /usr/bin/login, I just use /bin/zsh as my Terminal.app startup command which is much faster. However, every time I access the file system, even some tab for autocompletion, it takes a few seconds. Even cd'ing into some directory can sometimes take a few seconds. Sometimes ~= it's more than 1h ago that I accessed that dir or so. Edit: Maybe it's Time Machine or Spotlight or so which destroys the effectiveness of the VFS cache?
- nirvana 15y agoChanging directory is instant for me. (no SSD here, all spinning rust.) Tab completion is instant too. Run Time Machine every hour, never made a change to the spotlight config.
- spooneybarger 15y agoanything that hits the disk heavily, including time machine, kills my snow leopard machine. lack of ui responsiveness, beachballs et al.
- shadytrees 15y agoI want to reach across the internet and hug you right now.
- bsg75 15y agoWow - that does make a difference in launching a terminal!
- burgerbrain 15y ago> "That delay is /usr/bin/login searching the system logs so that it can display the date and time of your last login." Am I missing something? `w` on my linux system takes well below one second: [burgerbrain@eeepc] ~ % time w 14:11:18 up 19:41, 6 users, load average: 0.27, 0.10, 0.14 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT REDACTED w 0.01s user 0.05s system 61% cpu 0.096 total I can't imagine why anything like that would ever take anywhere near 5 seconds.
- CGamesPlay 15y agoThat shows your currently active login, which is of course in main memory. Your most recent login may well no longer be active, and so you have to search the log files.
- burgerbrain 15y agoAh yeah, had a brain fart there. Even so, `last` is similarly fast.
- eklitzke 15y agoHard drives can read read data sequentially very, very quickly. On whatever generic SATA hard drive I have in my workstation, I get: eklitzke@gnut:~ $ time sudo head -c 1073741824 /dev/sda > /dev/null real 0m8.267s user 0m0.220s sys 0m0.810s So I can read 1G off the drive in about 8 seconds. Even if the login command does need to sequentially read through logs to find the last login time (and I'm skeptical of that, because that would be a stupid way to implement login), I don't see how that would explain multiple seconds of waiting.
- 9oliYQjP 15y agoYou sir are a gentleman and scholar. As a laptop user with only 8 GB of RAM and a slow non-SSD hard disk, this one trick just made my day! Thanks.
- ramblex 15y agoOnly 8GB? ha. I have 4GB and having any kind of flash player open in chrome means I have no RAM free.
- napierzaza 15y agoI disabled flash a long time ago. The hard part is trying to download Youtube videos to disk since I had buffering (via flash or html5).
- batista 15y agoReally? Because I have 2GB too and I can have several flash videos open and get along just fine with other programs.
- pooriaazimi 15y agoI know I shouldn't say it (a dozen have already done so), but thank you. Just wonderful. My terminal just got 10 times better. I'd make it 'best comment of the month' if I could.
- telemachos 15y agoTwo other things that can make OSX terminal launching slow: 1. The default use of /usr/libexec/path_helper to manage your $PATH.[1] 2. An accumulation of log files in /var/log/asl.[2] For (1), I just edit /etc/profile and disable path_helper altogether. I set the PATH manually. (This also allows me to put /usr/local/bin before /usr/bin, which is my preference. I've never understood Apple's default settings for $PATH. They put /usr/local/bin later - which defeats the whole point of installing, say, a newer vim in there.) For (2), a cron or launchd job can take care of it. [1]: http://mjtsai.com/blog/2009/04/01/slow-opening-terminal-windows/ http://mjtsai.com/blog/2009/04/01/slow-opening-terminal-wind... [2]: http://osxdaily.com/2010/05/06/speed-up-a-slow-terminal-by-clearing-log-files/ http://osxdaily.com/2010/05/06/speed-up-a-slow-terminal-by-c...
- st3fan 15y agotime /usr/libexec/path_helper PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/local/share/python:/usr/local/sbin:/Users/stefan/bin"; export PATH; real 0m0.004s user 0m0.001s sys 0m0.002s Really? Are you sure path_helper slows things down?
- telemachos 15y ago> Are you sure path_helper slows things down? I'm sure that it did, but not sure that it does. The code you ran isn't quite what /etc/profile does. Here's a run of that on an older machine where I work (see below on versions): $ time eval `/usr/libexec/path_helper -s` real 0m0.106s user 0m0.084s sys 0m0.021s However, looking at my current machine, I realize that /usr/libexec/path_helper is no longer a shell script at all. It's compiled. Running that same test on a newer machine, I get this: $ time eval `/usr/libexec/path_helper -s` real 0m0.004s user 0m0.001s sys 0m0.003s So, in a nutshell, I think you're right for current machines: The path_helper advice looks to be out of date. I can't edit my original answer any more, but thanks for making me rethink this (I've been annoyed by slow-opening terminals in OSX for years. Apparently, they worked on this part of the problem.)
- 15y ago
- rhizome 15y agoDoesn't OSX rotate logs? Seems weird that it should take so long.
- huhtenberg 15y agoSo it takes 5 seconds to search the system logs for the date of the last login? How is this any less broken?
- dspillett 15y agoIt isn't broken from a memory management point of view, which is what the post being discussed is talking about, I think is the point.
- zurn 15y ago> That delay is /usr/bin/login searching the system logs > so that it can display the date and time of your last login. Normally Unixes (Linux included) use a pretty efficient binary file called wtmp for that, I'm surprised if OS X doesn't. Reading the last disk block of that file would contain the last login with overwhelming probability. There has to be a lot of seeks even on a slow laptop rotating hd to get a 5 second delay, with 15 ms seek time you get 333 seeks in 5 secs.
- saurik 15y agoOS X does: /var/run/utmpx.
- st3fan 15y agoIf you are interested what happens when you open a new terminal window, run 'sudo opensnoop' in one window and then open a new window. Here the majority of files being opened are in /var/log or Homebrew related. Also interesting ... creating a .hushlogin did not change much. It still opens about 50 files in /var/log/asl/
- xer0x 15y agoAwesome! Thanks for pointing out opensnoop!
- adavies42 15y agorelatedly, i call "`eval resize`" in my .zshrc--any idea why that takes ~5s if it's more than a minute or two since i last did it, but is instantaneous otherwise? (yes, i'm certain that it's that line that's taking time--if i start typing during the delay before the prompt shows up, i get a resize error about unrecognized characters and then a couple bits of random ANSI on my input.)
- polynomial 15y agoDoes this apply to iTerm as well?
- mlreed328 15y agoThanks for this. I love learning something simple, new, useful, and that I probably should have already known after decades writing software.
- dogweather 15y agoI'd send you a dollar if I could for this post. Awesome.
- saurik 15y agoNo. The sequence of events concerning this in login: 0) `login -pf` 1) quietlog = 0 2) if ("-q" in argv) quietlog = 1 3) if (!quietlog) getlastlogxbyname(&lastlog) 4) if (!quietlog) quietlog = access(".hushlogin") == 0 5) dolastlog(quietlog) -> 6) if (!quietlog) printf(lastlog) You can see from this that the "searching the system logs" (which, to be clear, is going to be really really fast: /var/run/utmpx is a small file with fixed length fields) happens in step #3, before .hushlogin is checked in step #4. If you wish to verify, you can read the code at the following URL. Note that __APPLE__ and USE_PAM are defined for the OS X distribution of this code, while LOGIN_CAP is not. http://opensource.apple.com/source/system_cmds/system_cmds-541/login.tproj/login.c http://opensource.apple.com/source/system_cmds/system_cmds-5...
- ricardobeat 15y agoBut why does .hushlogin makes Terminal.app come alive faster?
- saurik 15y agoAs I cannot replicate this behavior, I am not certain. On my OS X 10.6.8 11" Air, terminal sessions are only being delayed by my 2.5MB .bash_history; if I clear that file ( something I sadly wouldn't want to always do ;P) terminals come up with almost no delay. However, assuming that is the case for some people, we have to look elsewhere than the last login lookup. There are only a few other usages of quietlog: motd (open file, read it), mail (check environment, stat file), and pam_silent. The first two are not going to cause any kind of performance issue, so we have to look at pam_silent. This variable is particularly interesting, as it is only set to 0 if -q is not passed (and it is not) and there is no .hushlogin (it is not directly controlled by quietlog). If it is not 0, then it is left at a default value, which is PAM_SILENT, and is passed to almost every single PAM function. It could very well be that there is some crazy-slow logic in PAM that is activated if you do not set PAM_SILENT. Given this, someone experiencing this issue might look through the code for PAM to see if anything looks juicy (and this is something that will best be done by someone with this problem, as it could be that they have some shared trait, such as "is using LDAP authentication"). (edit: FWIW, I looked through OpenPAM, and I am not certain I see any actual checks against PAM_SILENT at all; the only mentions of it are for parameter verification: the library makes certain you don't pass unknown flag bits to anything.)