I feel like there is something fundamental I'm missing here, and because of that googling the error has been very difficult.
I've set up an SSH connection to my home computer using the instructions I found here:
https://winscp.net/eng/docs/guide_windows_openssh_server
I'm able to access ipython interactively by entering ipython but the prompt is not behaving at all like I expect. Please see the following interaction:
The session isn't immediately responsive and seems to be running the commands in some type of batch mode, and still not all of them. I don't receive any output until I exit the program. Running python and not ipython behaves similarly. I'm hoping to have a somewhat more standard interactive python experience, and have no idea how to go about debugging this.
Information on my system:
OS - Windows 10, both machines
SSH - OpenSSH set up through link above
Python - 2.7.11, Anaconda install 2.5.0
Remote access application - Putty
Thanks for any help-
Related
I have installed Anaconda under Windows and Ubuntu under WSL. I have not used this Ubuntu installation for a long time. When I tried to run Ubuntu now, I saw the following:
That is, WSL starts a Jupyter Notebook server, which I have to kill by hitting Ctrl-C to get the Ubuntu prompt. What could be causing this behavior?
There are several ways for something to "autostart" when running WSL:
First, you (or an application) may have modified your startup scripts to start the Jupyter Notebook server. To see if this is the case, try starting WSL from PowerShell by running:
wsl -e bash --noprofile --norc
This will run bash without the startup scripts. If this brings you to the prompt without running the notebook sesrver, then the problem is in your ~/.bashrc or ~/.bash_profile (assuming bash is your default shell).
Given the symptoms you are seeing, this is the most likely cause. If that's the case, look in those files to see if you can find the line that is starting the server, and comment it out.
Second, and related to the first, do you recall trying to enable Systemd at any point using something like Genie or WSL2Hacks? If so, then I believe they modify your start scripts to run Systemd, which can be used to start other services. However, I would expect those Systemd-executed services to start daemonized, in the background, and not interrupt your shell's startup.
Under Windows 11, services can also be autostarted via /etc/wsl.conf, but again, they would be started by the root user in this case, and in the background. I can't think of a non-pathological way that this could be used to interrupt the user's startup shell experience.
I can't open the GUI of Stata running on local macOS machine from remote Ubuntu server.
I have installed stata-se on my local machine, I can open X11 apps like xclock and xeyes. I'm using the following command to connect to the server:
ssh -X username#servername -p XXXX
Is there any to resolve this issue?
Since the distinction is a little unclear in the question:
According to the documentation the command to launch the Stata SE GUI is:
xstata-se
while
stata-se
launches the console version.
Since these are not working you can confirm the syntax diagram with:
stata -h
which will tell you the correct syntax, if Stata is actually installed.
If you are seeing something like:
$ command not found: Stata
then you may, similar to this, need to make sure that the path to Stata is properly set in your path file. Exactly how you do this depends on your terminal and operating system.
I am in the process of installing jupyterhub. I successfully install jupyterhub using:
python3 -m pip install jupyterhub
npm install -g configurable-http-proxy
However, when I run jupyterhub -h in the Windows command prompt it gives:
"jupyterhub" is not recognized as an internal or external command, operable
program or batch file.
I added C:\Users\User\AppData\Local\Continuum\Anaconda3\Lib\site-packages\jupyterhub\ to my user environment variable, however still receive the message. What path should I be using?
Please note that according to this, Jupyterhub is not officially supported for Windows yet.
That aside, you could dockerize it to make your life easier. For this error, please check if you can see the executable in C:\Program Files\Continuum Analytics\Anaconda3\scripts. The lib directory you're specifying contains python source files and not the executables.
I had this same issue, and I saw this occurred because jupyterhub is a python script rather than an executable. So to run this on Windows I needed to execute it like python C:\Program Files\Continuum Analytics\Anaconda3\scripts\jupyterhub.
However, I still was unable to run jupyterhub on Windows because it depends on the pwd module, which is a Unix/Linux only module.
As others have said, Windows is not a supported platform. JupyterHub is best used on Linux-like platforms where you have Docker or something similar to conatainerize each user's session.
A good alternative is to install Oracle VirtualBox and run a local VM. I run a 64-bit Ubuntu and it's quite good performance. It makes things much easier to run JupyterHub on. Asides depending on pwd, there are also assumptions around user-creation and other activities that Windows isn't going to handle well.
In short, if you want to run on native Windows, you're going to become the first JupyterHub Windows contributor. I looked at doing it but it looked like too much effort.
The upside of running a VM is that behaviour in the VM is going to more closely resemble what you have running on the server anyway. If you don't plan running on a server, then just "jupyter notebook", as this is all JupyterHub ends up running...
I am running a python script on say machine A. Is there any way to know if the python script is running or not from another machine B from command line? I tried getting the process list from the task manager. But it does not show any information regarding this script though it is running( it only showed cmd through which the script is executing ).
This will be a three step process. Step 1 is only required because you are Windows. If you're Mac or Linux, they already come with Step 1 completed for you. Otherwise, this is completely cross-platform capable.
1) You need to remotely connect from Machine A to Machine B. One extremely popular way of doing this is SSH, which can be installed on Machine A and Machine B. The recommended way to do this is with FreeSSHd, which has been very well documented here: https://serverfault.com/questions/8411/what-is-a-good-ssh-server-to-use-on-windows
2) Install the paramiko SSH library for Python. This will allow you to connect to another machine, and execute any arbitrary command line command. On windows, you just need to install the binaries for paramiko and pycrypto/openssl. This also is well documented on SO here: installing paramiko on Windows
3) Decide how you want to harvest the process list. There are several ways which are well documented here: https://stackoverflow.com/questions/53489/how-do-you-list-all-processes-on-the-command-line-in-windows
My shell provisioner is a small bash script that apt-gets a few things, installs a few Perl modules through cpan, sets up Apache and MySQL, echos some text, and exists.
Except that after printing its final message, it seems not to exit, but hangs forever.
Am I forgetting to do something? How can I begin to debug this?
If I use the VirtualBox manager to close the VM, I get a stack trace whose head reads,
/Applications/Vagrant/embedded/gems/gems/net-ssh-2.6.7/lib/net/ssh/ruby_compat.rb:30:in `select': closed stream (IOError)
Host OS: OS X Snow Leopard
Guest OS: Ubunut via precise32
TIA
This is really a comment but I don't have enough reputation to post it as a comment.
I would suggest two techniques to debug this problem.
1) Enable debugging in Vagrant like so:
VAGRANT_LOG=info vagrant up
2) Define set -x at the top of your shell script to link one line of your shell script to the output it creates when run. This should allow you to see which line of your shell script is hanging.
Updating your question with the Vagrantfile will also help us guide you in the right direction.
This issue should be resolved in a Vagrant release 1.2.4 or newer, which includes a fix which closes the ssh channel when the shell provisioner exits.