1

I am connecting to a remote server through 

ssh user@server.com

and run

python script.py

in the appropriate directory. However, I get the error 

ImportError: No module named numpy

even though I know the module is installed and the script runs with no problems when I am physically logged in to that server.

None of the answers I was able to find worked (for example this, and this). Do have any ideas as to how I can run the script using ssh?

The remote server has Python 2.6.6 installed, and 

which python

returns 

/usr/bin/python

The remote serves runs CentOS.

Valentina
  • 123
  • 6
  • There's not enough information given for this question to be answerable right now. That said, a good place to start would be including `type python` and `declare -p PYTHONPATH` as they exist in both the physically-logged-in case and the SSH case. – Charles Duffy Jun 09 '19 at 17:37
  • (The number of reasons it *could* be happening is almost unbounded; there could be an entry in your dotfiles branching on whether `SSH_USER` is set; SSH could be configured to pass through local environment variables, and thus setting an unsuitable PYTHONPATH; there could be an `authorized_keys` file in SSH that sets a completely different shell to be invoked; there could be reliance on PAM modules for environment setup... etc, etc, etc; I could think of 20 more unlikely-but-possible scenarios if I put my mind to it, and chances are the actual causal chain wouldn't match with any of them). – Charles Duffy Jun 09 '19 at 17:43
  • `type python` and `which python` are two different things. I asked for `type` very intentionally; if you have an alias, a shell function, or the like in one scenario but not the other, `which` won't know anything about it. – Charles Duffy Jun 09 '19 at 17:45
  • (Also, please clearly specify whether it's the working/local case or the broken/remote case for which you're showing any diagnostic output, and include both cases). – Charles Duffy Jun 09 '19 at 17:47
  • `type` python returns `type: Command not found.` – Valentina Jun 09 '19 at 17:48
  • Then your shell isn't bash, as `type` is a builtin there. What shell are you using? (Also, do you get that same "command not found" for both cases, or only the remote case? If you have bash in one case and a non-bash shell in the other, that's useful information). – Charles Duffy Jun 09 '19 at 17:48
  • I apologize, but I do not fully understand what you mean. All the output I am providing refers to the remote server, but I'm guessing that is not what you are asking for :/ – Valentina Jun 09 '19 at 17:49
  • The goal is to compare the remote server when it's remote (as in on the other side of a SSH connection), and that same server when you're logged into it locally (being the case where everything works as-intended). – Charles Duffy Jun 09 '19 at 17:50
  • BTW, how was numpy installed? Is it an RPM package, as installed via yum, or was it installed via Python-specific tooling such as pip? (What does `rpm -qa | grep numpy` return?) – Charles Duffy Jun 09 '19 at 17:52
  • I see. Unfortunately, the remote server is actually remote, I cannot log into it right now (it's in my university, which I cannot go to right now I'm afraid) – Valentina Jun 09 '19 at 17:53
  • Unfortunately I have no idea. The remote server is my university's and it was not I who installed python. All I know is that when I run my scripts there, they run perfectly. – Valentina Jun 09 '19 at 17:54
  • Does it let you run `rpm -qa | grep numpy`? What does that command return? – Charles Duffy Jun 09 '19 at 17:54
  • The command `rpm -qa | grep numpy` ran, and it did not return anything. – Valentina Jun 09 '19 at 17:56
  • ...okay, so that tells us that however numpy was installed, it *wasn't* installed via an RPM. – Charles Duffy Jun 09 '19 at 17:57
  • ...unfortunately, what we need to know now is how it *was* installed. We could figure that out trivially if you could observe a working instance, but without one, there's a lot of stumbling around in the dark. – Charles Duffy Jun 09 '19 at 17:58
  • ...that said, just to try something -- does running `bash -l -i` get you into a shell where numpy works? (That runs bash and invokes your `~/.bash_profile`; if that's where a virtualenv is being activated or the like, it might be all that's needed here). – Charles Duffy Jun 09 '19 at 17:59
  • running `bash -l -i` got me into another shell, but numpy still does not work. – Valentina Jun 09 '19 at 18:07
  • Looking at the questions you linked -- you say you followed the existing answers on those questions, but https://stackoverflow.com/a/6851239/14122 would *most certainly* work. (It also requires you to know where the numpy install for the same version of Python is at, so using it isn't trivial, but if you're going to say you already tried everything on the linked questions and nothing worked, it's expected that you... well... *really* have tried everything). – Charles Duffy Jun 09 '19 at 18:08
  • Anyhow, given only the information that's available, I would generally suggest creating a new virtualenv and installing numpy in it. That's going to take a lot of time, but anything else would require knowing more about the specific remote system and how numpy was installed on it than we do. – Charles Duffy Jun 09 '19 at 18:10
  • (That said -- another thing you can try is `locate numpy`; if the system *has* an up-to-date locate database, that might give you some clues about where the numpy installation sits. Still, much less of a sure thing than just setting up a new local installation under your own home directory). – Charles Duffy Jun 09 '19 at 18:12
  • I ran `ssh user@server.com '. ~/.bashrc; python path/to/script.py' ` and still numpy did not run. This is what I tried. – Valentina Jun 09 '19 at 18:15
  • as expected, `locate numpy` returns `locate: Command not found.` – Valentina Jun 09 '19 at 18:17

1 Answers1

0

See similar problem describe here: Why does an SSH remote command get fewer environment variables then when run manually?.

Compare your environment variables in the local (physical) mode to the remote mode by running env in both cases. Move missing variables from your local profile to /etc/profile. Then log out from ssh session and connect again.

Another approach: If you don't want to change anything, then after ssh switch to your user via su - <your user>. This may look weird because you already logged it with this user. The difference is, that after su all your env. variables will set like in a local (physical) mode. Advantage: it is quick. Disadvantage: You will have to do it each time you want to run your Python script. So the first approach with configuring /etc/profile may be better on the long run.

mentallurg
  • 4,967
  • 5
  • 28
  • 36
  • You mean `su - youruser`, right? By default, `su` doesn't act like a login shell. – Charles Duffy Jun 09 '19 at 17:53
  • ...that said, generally speaking, I'd suggest keeping speculative content to comments until there's actually reason to believe a given answer to actually be correct. (Insofar as the OP doesn't currently have physical access, we have no basis on which to reach any conclusions that require a comparison of environment variables, my own impression is that this question too vague to be answerable, and thus closeable until clarified). – Charles Duffy Jun 09 '19 at 17:54
  • (also, I don't know what you mean by "local (physical) mode" -- whether `su` gets the same environment variables as `login` is a question of local dotfile, PAM, and other configuration, not a consequence of there *being* such a thing as "physical mode" that both login and su leverage). – Charles Duffy Jun 09 '19 at 17:56
  • @Charles Duffy: Regarding `su`: Thank you, you are right, I have corrected it. Regarding physical mode: Again, you are right. But I prefer to use the wording from the OP, thus I avoid long explanation until it is really needed. – mentallurg Jun 09 '19 at 18:04