34

I have a strange issue on my new MacBook Pro (late-2016, touch bar).

It works fine and then, after using it for a while, opening new Terminal windows doesn't work because login hangs. Rebooting fixes the problem.

This seems to be an issue some other people have had so I tried all of their solutions already (from 1 and [2]):

  1. Removing ~/Library/Preferences/com.apple.Terminal.plist
  2. Setting my default shell to another shell (from /bin/zsh to /bin/sh or /bin/bash)
  3. Removing or cleaning my .profile, .zprofile, ... This does not work and I can validate that the issue occurs before the shell is even invoked, because if I echo HEY as the first line of my .zshenv this is not even reached. It must be login causing the troubles. Editing /etc/profile to add an echo at the top also shows up nothing
  4. Changing the Run command: setting in my Terminal config to something like echo foo also does not work (leaving Run inside shell checked or unchecked doesn't change anything).

Other notes:

  • Like [2], ssh-add -K does not persist keys between reboots, something I never had troubles with before.
  • The console does not show any suspicious errors or warnings.
  • Opening a new Terminal window does seem to create tty file (/dev/ttys<number>).
  • When this occurs, it does not matter if I use Terminal.app or iTerm.app
  • I have a pretty clean install (just got my laptop, didn't restore any backups, just installed some apps with brew install and brew cask install).

This is really hard to debug because I cannot reproduce it and often I can't open a new terminal to even try to find out what's going on.

Does anyone have any tips?

Update:

Using iTerm, I was able to get a shell by setting the start command to /bin/bash. In this shell, however, sudo does not work. It hangs (without showing the prompt) and ctrl-C and ctrl-D do no work when it hangs.

Using some other programs also does not work in this shell: node or /usr/local/bin/node both hang. As far as I can tell, it's programs that are in/usr/local/bin.

Update 2:

brew list --full-name results in these packages:

autoconf
automake
blueutil
boost
cabal-install
cairo
cfssl
cmake
coreutils
doxygen
editorconfig
erlang
ffind
ffmpeg
flow
fontconfig
fontforge
freetype
gdbm
gettext
ghc
git
glib
go
gobject-introspection
graphicsmagick
harfbuzz
haskell-stack
highlight
icu4c
influxdb
jemalloc
jpeg
keybase
lame
libevent
libffi
libpng
libtermkey
libtiff
libtool
libuv
libvterm
libxml2
lua
mongodb
msgpack
nginx
node
openssl
[email protected]
pango
pcre
pixman
pkg-config
postgresql
protobuf
python
python3
rabbitmq
readline
reattach-to-user-namespace
redis
sqlite
the_silver_searcher
thefuck
tmux
unibilium
unixodbc
wxmac
x264
xvid
xz
yarn
z
zsh
josegonzalez/php/php54
neovim/neovim/neovim

Update 3:

These points are in correspondence with @Monomeeth's answer:

  1. When it happens, a login item does show up in activity monitor. (Force) Quitting it also closes the Terminal window that was hanging. Closing the window manually does not make the login process go away in the Activity Monitor.

  2. The terminal title is Terminal — login — term big — ttys001 — 89x18 — ⌘1, where term big is the settings name.

  3. There's no sudo process showing up in the Activity Monitor. I can create a sudo process by opening iTerm.app (which uses bash) and running sudo echo ok there. It can not be Quit, but Force Quit works and kills it:

    bash-3.2$ sudo echo ok Killed: 9

Update 4:

When it happens, running login from a shell that's still available does work, while the login in newer shells seems to hang.

Update 5:

I recently got a new laptop (MacBook Pro 2017, no Touch Bar) and the problem persists.

I've switched shells as well: I'm now using fish with a pretty vanilla config. I think that rules out the shell as the culprit.

The OS has also been updated to 10.13.3 (17D47) High Sierra.

I've tried to install as little as possible on this machine:

brew list —-full-names

coreutils 8.29
dnsmasq 2.78
faac 1.29.9.2
fdk-aac 0.1.5
ffmpeg 3.4.1
fish 2.7.1
freetype 2.9
gdbm 1.14.1_1
gettext 0.19.8.1
git 2.16.1
highlight 3.42
htop 2.0.2_2
icu4c 60.2
imagemagick 7.0.7-22
jemalloc 5.0.1
jpeg 9b
lame 3.100
libav 12.2
libogg 1.3.3
libpng 1.6.34
libtermkey 0.20
libtiff 4.0.9_1
libtool 2.4.6_1
libuv 1.19.1
libvorbis 1.3.5_1
libvpx 1.7.0
libvterm 681
libyaml 0.1.7
lua 5.3.4_2
luajit 2.0.5
mongodb 3.6.2
msgpack 2.1.5
neovim 0.2.2
node 9.5.0
openssl 1.0.2n
opus 1.2.1
parallel 20180122
pcre 8.41
pcre2 10.30
postgresql 10.2
python 2.7.14_3
python3 3.6.4_2
readline 7.0.3_1
ripgrep 0.7.1
ruby 2.5.0
sqlite 3.22.0
the_silver_searcher 2.1.0
thefuck 3.25_1
unibilium 1.2.1
x264 r2795
xvid 1.3.5
xz 5.2.3
youtube-dl 2018.02.08

Not sure what this can be now. The only apps which I can think of are Divvy or Apptivate since they both seem outdated. This is the intersection of what was installed on the old vs the new machine:

coreutils
ffmpeg
freetype
gdbm
gettext
git
highlight
icu4c
jemalloc
jpeg
lame
libpng
libtermkey
libtiff
libtool
libuv
libvterm
lua
mongodb
msgpack
node
openssl
pcre
postgresql
python
python3
readline
sqlite
the_silver_searcher
thefuck
unibilium
x264
xvid
xz

Update 6:

Also, here's a screenshot: screenshot

Update 7:

My env typically looks like this:

Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.k60Nf5UBfq/Render
DISPLAY=/private/tmp/com.apple.launchd.6FMoWPSlJI/org.macosforge.xquartz:0
EDITOR=env VIRTUAL_ENV= nvim -u /Users/john-doe/.config/vim/vimrc -p
GNUTERM=X11
HOME=/Users/romeo
HOMEBREW_NO_EMOJI=1
HOMEBREW_PREFIX=/usr/local
LANG=en_GB.UTF-8
LESS=-RI
LESSHISTFILE=-
LOGNAME=romeo
LS_COLORS=di=00;31:ex=00;37:mi=00;41;30:tw=00;33
MANPATH=/usr/local/opt/coreutils/libexec/gnuman
PAGER=less
PATH=/Users/john-doe/.config/fisherman/re-search:/usr/local/opt/python/libexec/bin:/usr/local/opt/ruby/bin:/usr/local/opt/coreutils/libexec/gnubin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/local/MacGPG2/bin
PWD=/Users/romeo
SECURITYSESSIONID=186a8
SHELL=/usr/local/bin/fish
SHLVL=1
SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.fQn5sHMuZP/Listeners
TERM=xterm-256color
TERM_PROGRAM=Apple_Terminal
TERM_PROGRAM_VERSION=400
TERM_SESSION_ID=D2AF7A50-8B41-4793-9201-8304A02C9B29
TMPDIR=/var/folders/15/zcyyfw_x7638z7vfg5zd85z40000gn/T/
USER=romeo
XDG_CACHE_HOME=/Users/john-doe/.cache
XDG_CONFIG_HOME=/Users/john-doe/.config
XPC_FLAGS=0x0
XPC_SERVICE_NAME=0
12
  • 2
    This might be a lame suggestion, but have you tried contacting Apple Customer Support? Your question hasn't gotten much attention since you posted it, and their support staff may have heard about this problem. My only other suggestion would be to reinstall MacOS. However, since your Mac is so new, I don't know if this would work.
    – NoahL
    Commented Jan 18, 2017 at 2:28
  • 1
    @klanomath done!
    – romeovs
    Commented Jan 18, 2017 at 10:12
  • To figure out what login is doing, select it in Activity Monitor and choose Sample Process. The same goes for other processes that are hung. However, this level of debugging may not be appropriate for a StackExchange Q&A. It may be better to either file a bug report with Apple including the sample file, or to find someone who can offer support for diagnosing the issue at this level. See developer.apple.com/bug-reporting
    – Chris Page
    Commented Jan 20, 2017 at 19:52
  • How long does it hang? Have you tried leaving it running for ten minutes? Is your machine bound to an Open Directory network? In particular, login has to fetch your user information, and if you're on an OD network with a busy/unresponsive directory server, it could take a couple of minutes to respond; other programs also fetch user information and could suffer from this issue.
    – Chris Page
    Commented Jan 20, 2017 at 19:57
  • 1
    Haven't tried waiting longer, will try it next time. I'm not bound to an Open Directory network, these errors occur also when I'm not on any network.
    – romeovs
    Commented Jan 23, 2017 at 9:44

12 Answers 12

14
+75

As I'm sure you know, troubleshooting is a process of elimination and often requires a fair bit of patience. I'd like to try a few things to try and get to the bottom of this for you.

1. Confirm it hangs during login

If the process it's hanging at is really during login, this implies that the process is still waiting to create a login session. Assuming this is the case, then it wouldn't have tried to start the shell yet.

To confirm this, the next time you experience this issue launch Activity Monitor to check if the shell is running or whether you only see a login process.

Once you've had a chance to do this, report back with what you found.

NOTE:- If you happen to have other terminals open, make sure you're checking the corresponding process. My guess is that the hanging process is the one with the highest Process ID (PID) number.

2. What is the Terminal title?

The next time you have this issue can you take a note of what the title of the Terminal window is and report back?

3. Kill sudo

You state that rebooting your MBP always resolves this issue.

However, the next time you have this issue (maybe after doing what I described at 1 above), I'd like you to try killing sudo from Activity Monitor.

Once you've tried this, let us know what happens.

4. Try moving your .bash* files

It is possible (for various reasons) you may have a .bash_profile file in your user directory and this is causing intermittent problems. This is something you may not even be aware of, but you can use Automator to run a script that finds and moves any .bash files.

Here is an example script for doing this:

cd ~

mkdir moved
for F in .bash*
do
    mv $F moved
done

This script moves all files starting with .bash in your home folder to a newly created moved subfolder.

After running the script, check this folder and let us know if in fact you have any files in it.

NOTE:- You can label the new subfolder anything you want. To do so, just change the two occurrences of moved in the script to whatever label you'd like to use.

[UPDATE]

Some more things to try.

5. Try clearing the *.asl files

If you haven't already, try clearing out the *.asl files. To do this use the following:

sudo rm -rf /private/var/log/asl/*.asl

NOTE:- This may take some time as it creates a new shell. When complete, make sure you fully quit the Terminal for the changes to take affect.

6. Safe Mode

Do you notice any difference in behaviour when you start your MBP in Safe Mode? To boot into Safe Mode:

  1. Fully shut down your Mac
  2. Restart your Mac
  3. Immediately press the Shift key and keep it down
  4. Let go of the Shift key when you see the login window (NOTE: If you have FileVault enabled you may need to log in twice).
  5. Once your MBP starts up try using Terminal and see if you can still replicate the issue?
  6. When finished, you can exit Safe Mode by restarting your MBP as normal

7. Open Directory

This probably doesn't apply in your case since you don't mention it, but if you're connected to an Open Directory network this could also be causing you problems. Usually this would only entail waiting for about 10 - 15 seconds, but I have seen reports of terminal logins taking five or more minutes to complete in this situation.

7
  • Thanks! I'm using zsh, and even with an empty .zshrc, .zprofile, .profile, etc id does not occur, plus that does not explain why other programs in /usr/local/bin also hang, so I think 4. is out of the picture. I'll get back with the answer to the other questions once I get them.
    – romeovs
    Commented Jan 18, 2017 at 10:11
  • Added an update with the answers to these questions. login seems to be the culprit, but it still does not explain why it does work in iTerm with bash.
    – romeovs
    Commented Jan 19, 2017 at 10:30
  • I've updated my answer. However, I just realised that you haven't indicated how long you've tried waiting for the Terminal login to complete? It would be good to know if it does eventually log in, or whether it just hangs indefinitely.
    – Monomeeth
    Commented Jan 24, 2017 at 4:32
  • @romeovs Just wondering, did you ever resolve this issue?
    – Monomeeth
    Commented Jan 30, 2017 at 23:49
  • nope :( still working on it. It has started to occur a lot less though.
    – romeovs
    Commented Jan 31, 2017 at 12:34
6

This seems like a perfect fit for you exceeding the maximum processes per user (or possibly max processes).

On a stock macOS installation you get 709 per user (ulimit -u) and 1064 max processes (sysctl -a | grep maxp)

An easy way to bump these up is to install Server.app from the App Store and then reboot. You can also set performance mode for higher limits.

Since you didn't describe your setup (OS version and build), here are some tips - be sure to check for SIP restricting your ability to change files if you read some of the older articles on changing the limits without resorting to installing server.app:

4
  • Excellent point! I hadn't even considered this. :)
    – Monomeeth
    Commented Jan 24, 2017 at 23:20
  • @Monomeeth your answer is awesome. Lots of great things in it.
    – bmike
    Commented Jan 25, 2017 at 3:51
  • @bmike Is there a way I can check the total number of processes to check that this is the case? Maybe I can even reproduce it by creating 709 processes then?
    – romeovs
    Commented Jan 26, 2017 at 18:32
  • Based on an instance I saw of something that appears to be the same problem, I don't think this is it. Launching new processes (from an existing shell) would work fine... but stat'ing (via ls -l) files matching /dev/ttys??? would (apparently) hang... Of course, there may be multiple causes for similar symptoms, so this may still be a useful answer, just thought I'd point out what I saw.
    – lindes
    Commented Feb 7, 2020 at 17:40
5

I have also been seeing this for several months now. Extremely frustrating. Only thing that fixes it is reboot.

  • Mid 2015 MBP (no touch bar)
  • MacOS 10.12.6 beta

Sometimes the login hangs happen after interacting with tmux.

I have unsuccessfully tried all the recommended approaches.

Not sure if it's related, but a lsof -p LOGIN_PID shows a pretty massive file /private/var/db/dyld/dyld_shared_cache_x86_64h for the hung login process.

8/29/2017 Update:

Still having the issue. Sometimes when the machine gets in the bad state, I have open terminal windows that are already logged in successfully that I can use to debug.

Many commands do not run properly, but they all show a pattern of having trouble writing (to stdout, I am thinking). For example, when I run ls -al, I see ls: write error emitted to stderr. When I run ls -al > /dev/null, nothing is printed to stderr.

3
  • Any luck on figuring this out?
    – romeovs
    Commented Feb 14, 2018 at 11:49
  • The issue is resolved for me since updating my OS. It has been fixed for a few minor versions, and I am currently running 10.13.3 (17D47).
    – Zack
    Commented Feb 15, 2018 at 16:22
  • Im running 10.13.3 (17D47) as well! It has become les frequent, but still occurs sometimes.
    – romeovs
    Commented Feb 15, 2018 at 17:05
4

It's important to treat the real issue and not just the symptom. So try out the following suggestions and update so based on that can suggest further remedies as well.

  1. Which user owns the terminal?:
    My first hunch is that this can be related to how your account is set up. If terminal is trying to access the resources or directories that only the admin user can (if your's is a non admin account), then that can lead to freezing state - not allowing you to access the terminal. So go ahead and ensure when you begin a terminal session, it is local to your user and not another user. The fact that you cannot create a sudo process, is pointing me to this direction.

  2. Type Control-Z or Command-Z:
    This control key sequence suspends a program that may be running and gives you a shell prompt. Now you can enter the jobs command to find the program’s name, then restart the program with fg or terminate it with kill.

  3. Press Command-C:
    This will interrupt if the terminal is trying to run a program in the background. Try it a couple of times. Note if you see any output

  4. Type Control-Q:
    If output has been stopped with Control-S, this will restart it.

  5. Get an Alternative shell:
    If you want to try out a different shell for a few days, their behaviors may sometimes help you understand the problem with Terminal given if they act in a certain way. Check these links below for alternatives

https://git-scm.com/downloads/guis
https://computers.tutsplus.com/tutorials/beyond-terminal-4-os-x-terminal-alternatives--mac-56217

Will help to know the following, if not mentioned already:

  • How are you initiating the terminal session? Is this via spotlight or a desktop icon or some other way?

  • What is the terminal doing when it hangs? Is it in the middle of executing a command (Same command each time before it hangs) or it just hangs from the moment you start a terminal session/ windows.

  • What do you usually use your terminal for? If a majority of your use is for git related commands only, I would suggest using Something like Github for Mac as you can usually do most of the things from there.

3
  • Ctrl-Z and Ctrl-C both just show up on the screen as ^Z and ^C, Ctrl-Q does nothing. I usually open the shell using Command-N in Terminal. I'm a full-time programmer, so I use the terminal for everything basically. The terminal hangs before anything is executed (on login).
    – romeovs
    Commented Jan 24, 2017 at 13:48
  • @romeovs What about Pointer 1 about what is your user type? A screenshot with the issue would help as well. Thanks
    – pal4life
    Commented Jan 24, 2017 at 16:53
  • I'm the default user and admin on my macbook.
    – romeovs
    Commented Jan 26, 2017 at 18:26
4

I would try to do disable SIP and dtrace login to find the root cause (To disable and re-enable SIP, see http://osxdaily.com/2015/10/05/disable-rootless-system-integrity-protection-mac-os-x/)

$ csrutil status
System Integrity Protection status: disabled.
$ cp /usr/bin/login /tmp
$ sudo dtruss /tmp/login

Trying to give you an example output, i just found out that things are much simpler than i thought. No need to disable SIP, just copy login.

dtuss will return the system calls and it might give a hint at where things go wrong.

cp /usr/bin/login .
sudo ls

give your password. Then do

sudo dtruss -d -e ./login 2> dtruss_login.txt

enter your username, press enter

enter your password, press enter

enter 'exit', press enter

and finally upload dtruss_login.txt to e.g. https://gist.github.com/

You can copy the contents of the file to the clipboard like this

cat dtruss_login.txt | pbcopy

You can find an example login here : https://gist.github.com/wolframteetz/49c5188c9dfe68a3841fa18496679579

The second integer in each line is the time the call took.

Of course, it would be great if you could run this when the login hangs, but if I get you right, this is impossible.... maybe you or someone else has an idea on how to 'dtruss login' when the terminal hangs?

8
  • Ouch. This seems like a lot of pain for something that happens hours or days after the log in starts. Can you narrow down what dtruss might capture and show?
    – bmike
    Commented Jan 25, 2017 at 3:52
  • If login hangs in a system call, which is quite probable, it will show you. If it hangs between system calls, it will show you between which, and give you a hint on what's actually going on. e.g. if it hangs after it reads a certain configuration file by a system call, the error most probably occurs during parsing that configuration. You need to take a close look at it then. Might also be network related... who knows until you debug it ;) Commented Jan 25, 2017 at 12:31
  • The problem is I can not manually reproduce the problem until it is too late.
    – romeovs
    Commented Jan 26, 2017 at 18:30
  • Then execute the command in a loop "forever" and do ">> dtruss_login.txt 2>&1" instead of "2> dtruss_login.txt". Once the error appears, you will see in in the end of the output. Commented Jan 28, 2017 at 18:12
  • I finally was able to get a dtruss log: gist.github.com/romeovs/6661ae0db77e57281b531676cc5dc007 Since login hangs, this never exits, so I ctrl-C'ed after about 10s.
    – romeovs
    Commented Feb 14, 2017 at 14:33
1

The login command source code has been published by Apple. The website is macOS 10.13.3 Source. The only required download is system_cmds-790.30.1. Once downloaded, the project can be easily modified to only build the login command. The modified project and logincommand have been place in GitHub at davidanderson61/system_cmds-10.13.3.

The idea here is to modify login to write debug information to the Console. This would help determine why the login command hangs. The modifications could be made anyone wishing to participate. I assumed this would have been me.

Install Debug login Command.

  1. Select the latest release from the website davidanderson61/system_cmds-10.13.3/releases.

  2. Download debug login command to your Downloads folder. Under "Assets", right click login and select "Download Linked File As", then select "Save".

  3. Partially, disable System Integrity Protection (SIP). The command is given below. Before entering the command, you will need to boot to a macOS Recover, then a Terminal window.

    csrutil  enable  --without  fs
    
  4. Enter the command given below to save original login command. If login.orignal already exists, you can omit this step.

    sudo  mv  /usr/bin/login  /usr/bin/login.original
    
  5. Enter the commands given below to copy the debug login command and set the proper permissions.

    sudo  cp  ~/Downloads/login  /usr/bin/login
    sudo  chmod  104555  /usr/bin/login
    
  6. Enable System Integrity Protection (SIP). Enter the following command. Afterwards, you should restart.

    sudo  csrutil  clear
    

Configure the Console Application

Below are the steps to configure the Console application to show only messages from the login command.

  1. Open the Console application.
  2. Add a PID column, as shown below.

    g2

  3. Enter login in the Search field.

    g3

    While the the Search field has focus, press the return key. The Search field should change to what is shown below.

    g8

  4. Change Any to Process, as shown below.

    g4

  5. List Change Contains to Equals, as shown below.

    g5

  6. Select the Save button. When prompted for "Save Search As:", enter Login, then select Save.

    g6

The results should appear as shown below. Next time you open the Console application, you will only have to select the "Login" button.

g7

Appendix

How the GitHub Repository Was Created.

  1. Click on the system_cmds.xcodeproj file open in Xcode.
  2. From the menu bar, select Source Control->Create Git Repositories....
  3. From the menu bar, select Product->Scheme->New Scheme.... Next, Select login as Target and Name.
  4. From the menu bar, select Project->Build.
  5. Quit Xcode.
  6. Login at GitHub and create a new repository.
  7. At the top of your GitHub repository's Quick Setup page, click g1 to copy the remote repository URL.
  8. For a Terminal application window, enter the following command. Replace <remote repository URL> with URL copied in the previous step.

    git  remote  add  origin  <remote repository URL>
    
  9. Open the project in Xcode and from the menu bar, select Source Control->Push....

How the First Release Was Created

  1. From a Terminal application window, enter the following commands.

    git  tag  -a  v1.0  -m  "Original source code"
    git  push  origin  v1.0
    
  2. Copy the built login command to your Downloads folder.

  3. From your GitHub account, create a new release as v1.0. Attach ~/Downloads/login as a binary.

1

I had this problem also while running sbt console in emacs. Whenever I exited out of sbt console by just killing the window instead of exiting out of sbt console "nicely" first, it caused a java process to hang even after the window was closed, and somehow prevented new terminal sessions from being created. I force-killed the java process from activity monitor, and the hanging terminal actually started, from within emacs as well as in a new tab.

Now, I just make sure to quit nicely using the command exit or ctrl-d (or ctrl-c ctrl-d in emacs term/multi-term), then kill the window.

0
  1. Check if your process hangs really during login
  2. Have a look on to the Activity Monitor and watch out for root processes (i.e. nano, emacs, vim) you might have initiated and not quit properly (crash, just killed the terminal, etc.) and which are still running.
  3. Kill this process(es) and the login should work immediately.
0

Just my two cents.

I've installed the Terminus Package for Sublime Text, which allows me to run terminal within my text editor.

Closing Sublime Text immediately allowed my terminal to start working again.

2
  • I don't think this helps to answer the question. Does this prevent the terminal from hanging by running it inside of Terminus? Even if it does, it appears you're solving another problem here. Commented Apr 5, 2019 at 22:02
  • My normal terminal wouldn't work due to some issues with Sublime Text
    – Abundance
    Commented Apr 6, 2019 at 17:53
0

FWIW, I had this same problem. It would resolve after reboot, but I wanted to save the time of doing that multiple times a day. It started after using a particular nodeJS environment, so I went into activity monitor and noticed a node process ongoing. Killing that instance solved the problem for me, so if anyone experiencing this has recently started working with node or npm locally, that could be your problem.

1
  • Was a stray "java" process in my case but killing it in Activity Monitor stopped the terminal hanging!
    – Adam B
    Commented Oct 14, 2019 at 17:54
0

Killing a stray nvim instance fixed this for me. I assume this isn't specific to nvim but something nvim in my case was doing that caused problems. I would look for an out of place orphaned terminal app in activity monitor and kill that if you find one.

0

In my case, the new terminal window hung after displaying Last login: Tue Nov 24 18:31:39 on ttys001,and the title of the terminal window showed manpath.

Turns out that this happened because I had upgraded my Xcode from 11.7 to 12.2 but hadn't yet installed the new commandline tools. After starting Xcode and doing so, the terminal opened without problems or delays.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .