2

I'm trying to install pow on an OS X machine.* Some of pow's components have to run as root, so part of the setup process involves running an installation script with sudo. The problem is, this setup script hangs for about five minutes before failing with an error indicating that it's failing to read a file in /tmp.

I instrumented pow and was able to determine that the hang occurs while it's trying to run a command equivalent to the following (I added some quoting and escaping because it was using a system call that takes an array of arguments):

/usr/bin/env login -qf root /bin/sh -i -c \
    'exec env > \'/tmp/pow.6854.1418720624398.37948\''

The intent seems to be to read the user's environment variables; either node.js (which pow is written in) doesn't provide direct access to environment variables, or they want to see what the environment is supposed to be like with a clean login shell.

Now, when I test this command in a root terminal, the cause of the hang becomes obvious:

Brents-MacBook-Pro:~ root# '/usr/bin/env' 'login' '-qf' 'root' '/bin/sh' '-i' '-c' 'exec env > /tmp/pow.6854.1418720624398.37948'
Login incorrect
login: 
login: Login timed out after 300 seconds

Apparently for some reason, login(1) does not like me trying to re-log in as root, so it prompts for credentials. pow doesn't expect it will need to interact with login, so it just sits there doing nothing until login eventually times out.

What I don't understand about this is the "some reason" part. Why would login -qf root fail when you're already root? The login(1) manpage's coverage of the -f option says:

This option may only be used by the super-user or when an already logged in user is logging in as themselves.

Well, in this case, the super-user is asking to log in as themself, so both parts of that condition are true. Why would this fail?

* I'm posting here instead of on Ask Different because this seems to be a Unix subsystem issue.

  • This looks dicey. If they want to figure out what environment a clean root login runs with, there's probably a better way, especially if they're already running as root in the context of the install script. Have you contacted them? Or do you have any way of determining if this is a widespread issue for their Yosemite users? – alesplin Dec 18 '14 at 0:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.