Ask Different is a question and answer site for power users of Apple hardware and software. Join them; it only takes a minute:

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

So, I've done some searching.. and still haven't found a solution for this. I'm not even sure what has caused it. There are no DYLD_ or LD_ flags being set at all, but I always see this when I open the terminal up.

dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/login) is setuid or setgid

Would definitely appreciate help with this.

share|improve this question

marked as duplicate by bmike Jul 18 '13 at 10:51

This question was marked as an exact duplicate of an existing question.

1. Were one of the answers on another question 'repair disk permissions' from disk utility? 2. Open Terminal (Applications > Utilities) and run: ls -laFh /usr/bin/login, paste the output into a comment. For reference, mine is: -r-sr-xr-x 1 root wheel 67K Sep 19 17:01 /usr/bin/login* – Jason Salaz Dec 20 '12 at 15:27
Yeah. I ran the disk permissions repair earlier, but to no avail. Permissions are exactly the same as your's. – Sly Dec 20 '12 at 15:49
Why not list what you tried that didn't work? – GEdgar Dec 20 '12 at 16:53
Can't we continue the discussion in and close this one? It doesn't add additional value and just confuses everybody. – patrix Dec 20 '12 at 17:20
NOTE: Repairing disk permissions is highly unlikely to help. The message occurs because /usr/bin/login is necessarily setuid root. Barring a bug, this really does indicate that some DYLD_* environment variable is set somewhere that's causing it to be set before /usr/bin/login is invoked by Terminal to create a new terminal session. – Chris Page Jan 16 '13 at 13:14

So, apparently it was the new Umbrella client by OpenDNS causing this error. I uninstalled it and continued to get this error until I restarted, which was making me think that it was something other than this client. However, after some testing.. it's confirmed that it's this client that's causing it.

So, yeah.. This definitely wasn't a duplicate or related to any of the duplicates that have been posted in the comments in the question.

share|improve this answer
The usual reason in a situation like this is an application setting DYLD_FRAMEWORK_PATH or DYLD_LIBRARY_PATH (or DYLD_FALLBACK_FRAMEWORK_PATH or DYLD_FALLBACK_LIBRARY_PATH) in order to find frameworks/libraries that are stored in the application's bundle, or installed in a custom location for its use. See the dyld(1) man page for information about the environment variables it supports and what they do:… – Chris Page Jan 16 '13 at 13:19

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