I am running a python machine learning script on google cloud platform. I have connected through SSH in browser. When I run the code it works, but when I close the browser it seems to stop running.
I believe I can make it run in the background with nohup, but I want to be able to check back in on it as it prints outputs on its progress.
Basically I want to be able to start the script, close the terminal and then reconnect from any machine to check on its progress. Any help would be really appreciated.
I am new to google cloud platform if any of this was unclear please as an ill try providing more detail.
You may use an app called as screen. Just install it using `sudo apt-get install screen`` (if debian, ubuntu).
In some cases it might be already installed in your instance, you may check it.
Once installed enter the following command into the terminal:
screen
and press enter. Now, You may start with your job in terminal.
The moment you need to disconnect you may press Ctrl+A and then d.
The session would be disconnected. You may note the session id that would be displayed (eg. detached from 1498.pts-1.server)
You may now close the terminal.
When you come back, use the following command to get back into the older session.
screen -r *screen_id* (eg. screen -r **1498.pts-1.server**)
This process is checked for google cloud, ssh through browser, it really works.
Check this site for mode details.
It sounds like you're referring to the Google Cloud Shell feature. If so then what you desire is not possible, the cloud shell is not intended for non-interactive operation. From Usage limits:
Cloud Shell is intended for interactive use only. Non-interactive
sessions will be ended automatically after a warning.
The cloud shell operates on a temporary Compute Engine virtual machine, which is running only while the cloud shell session is active in the browser.
Apart from the obvious approach of keeping the browser session active while your application is running, you could also provision yourself a non-temporary Compute Engine instance (a free one is available), to which you can connect and on which you can run non-interactive applications as you desire.
I have a couple of older printers (a Brother and an HP all-in-one) that I want to run as wireless and cloud-based printers. To do so, I bought a Raspberry Pi 2 and set it up as a headless print server following some online tutorials. Both of the printers are accessible wirelessly from my home network, but because my primary computer is a Chromebook and I use Android phones and tablets, the only good way I've found to print to them is using Google Cloud Print.
To do this, I downloaded Chromium onto the Raspberry Pi and signed in using my gmail account. This kind of worked for a few months, but the cloud connection would go down after a few days and I'd have to reboot the Raspberry Pi to get it back (there was probably a better way, but, since it was headless, it just seemed easier to reboot).
Eventually, I got tired of rebooting the Raspberry Pi and I read something on the Internet about upgrading my software to get new versions of the OS and of Chromium. Unfortunately, since doing so, I've been having problems.
Since I'm running headless, my primary means of connecting are via ssh and vnc connections from my Chromebook. ssh is fine, but I can't run Chromium on the Raspberry Pi via ssh (at one time, I found a tutorial on how to do this, but it has since been taken down and I think Google nixed the support for that somewhere along the line).
To start Chromium, I log with a vnc connection. When I log on the first time after a reboot (or after restarting the vnc server), everything works fine. I can use, for instance, the word processor or terminal available through the GUI. All is well. However, if I start Chromium, all of the sudden nothing will accept keyboard input. It is almost as if there is no keyboard connected at all at this point. Mouse input still works fine and I can open and close programs to my heart's content. Closing Chromium doesn't fix the problem. Closing the vnc connection from the client and logging back in doesn't fix the problem. Restarting the vnc server does fix it until I start Chromium again.
I say "almost" above because, even though pressing keys on the keyboard don't appear to do anything, the cursor (especially visible in the terminal window) does flicker with each key press as it would if I were typing actual text.
I've searched for this issue on Google, but my search has turned up very little. There were some lubuntu posts about possibly not using ibus, but, from what I can tell, that is not relevant to my situation. At least, I couldn't find anything ibus in ps and I couldn't find any options in the GUI preferences.
My Raspberry Pi is running what I believe is the latest version of Raspbian (I updated/upgraded again last night to be sure):
pi#raspberrypi:~ $ uname -a
Linux raspberrypi 4.4.21-v7+ #911 SMP Thu Sep 15 14:22:38 BST 2016 armv7l GNU/Linux
pi#raspberrypi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"
NAME="Raspbian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
It's running TightVNC with the following command-line options:
pi#raspberrypi:~ $ ps aux | grep vnc
pi 13537 0.0 2.2 91556 22584 ? S 01:05 0:27 Xtightvnc :1 -desktop X -auth /home/pi/.Xauthority -geometry 1368x768 -depth 24 -rfbwait 120000 -rfbauth /home/pi/.vnc/passwd -rfbport 5901 -fp /usr/share/fonts/X11/misc/,/usr/share/fonts/X11/Type1/,/usr/share/fonts/X11/75dpi/,/usr/share/fonts/X11/100dpi/ -co /etc/X11/rgb
Chromium's chrome://help About section says "Version 51.0.2704.91 Built on Ubuntu 14.04, running on Raspbian 8.0".
Beyond that, I don't know what other software/versions would be relevant, but if anyone can think of anything else that would be helpful, I can update this description.
Through trial and error, I've discovered that the Chromium keyboard/RDP issue seems to be related to particular extensions on my profile.
To verify this, try running Chromium with --disable-extensions.
The particular extensions/apps I've found to be problematic are:
Google Play Music
Plex
As soon as I disable these, keyboard starts working again. Does this help?
I'm running the 4.4.38 version of Raspberry Pi 3, which is the newest, and the newest chromium-browser (v.51). Although I am using a mouse and screen, I'm getting keyboard error messages, and other messages, and browser is hanging in some cases. I pretty quickly see the following errors on console after starting chromium:
[2530:2530:0217/142822:ERROR:sandbox_linux.cc(334)] InitializeSandbox() called with multiple threads in process gpu-process
[75:75:0217/142957:ERROR:PlatformKeyboardEvent.cpp(117)] Not implemented reached in static PlatformEvent::Modifiers blink::PlatformKeyboardEvent::getCurrentModifierState()
After asking on the raspberrypi.org forum, it was suggested that I wait for the next version of Chromium. It looks pretty sure that there is an i/o error between mouse and keyboard controls and chromium, and appears quite similar to your issue.
(I do not have the necessary 50 points, so I cannot comment, only as a solution, which in this case is not true, since I also did not find it yet.)
I have the exact same problem with a Pi 3, but in my case when remotely connected with xrdp (w/ Windows Remote Desktop).
I believe the symptoms appeared after an update-upgrade session. My current version:
pi#raspberrypi:~ $ uname -a
Linux raspberrypi 4.4.38-v7+ #938 SMP Thu Dec 15 15:22:21 GMT 2016 armv7l GNU/Linux
I originally only wanted to change the keyboard-layout to German, and from what I understood until now is that through xrdp it is not possible, unless you define your keyboard layout completely manually, see:
http://forums.fedoraforum.org/showthread.php?t=265100
http://cloclotron.net/xrdp_keyboard_layout_workaround.html
As soon as I open Chromium, I see the same behaviour as you, if I close it, everything is back to normal. If working on a directly connected monitor with kexboard plugged in, I experience no problems.
I am experiencing issues with the Pi, when I try to work on the Pi trough SSH I suddenly get lageness. At the beginning it works fine, but intermittently the auto-complete or commands on the history take a long time to load and that affects the typing.
How can I find out what is doing this?
Reading around I found that could be an issue with network, the SD card R/W speeds or even the SSH configuration itself, nothing that I tried of what I found around worked for me which was quite disappointing.
I don't know which the problem was exactly on my case.
I found a solution for me thanks to that several time my SSH session dropped an this is particularly painful If on the middle of running a command, so i decided to look for a way to keep session alive independently I found tmux. Which no only allowed me to keep session alive but it improved my ssh response, I read that mosh would do the same but I decided to go with tmux which work perfectly for me.
I'm trying to forward an X11 window from a remote server. Usually I can do something like
ssh -X some#address
and then for example run
feh image.jpg
to see the image.jpg picture on my local machine. Is it possible to get that behaviour in Capistrano 3? I'm installing a software and it requires me to do the usual "nextnextnextfinish". I want to do something similar to (inside the config/deploy.rb)
set ssh_option, {:forward_x11 => true} #doesn't work
but it seems that sshkit doesn't have that option. Is there a list of the ssh_option for sshkit somewhere or is there another solution to this?
Capistrano is to automate deployment using some sort of *sh script on the remote computer. Forwarding X11 Windows would make the user having to interact with the window. Therefore I ended up using a Bash script, Sikuli and Xvfb to automate the solution.
I want to be able to launch a VM in headless mode and log the outputs of its tty to the command line.
Basically I have a situation where the VM will be launched remotely (hence the command line requirement), but every once and a while, the VM's bootup sequence freezes, and right now there's no way for me to debug why the VM is not booting up properly unless I go there manually and view it in a non-headless mode.
The VM itself does not have a GUI, it just boots into TTY mode.
So is there anyway I can get some debugging output from the TTY while it's headless?
One crazy idea would be using non-headless mode and taking screenshots of the window that opens, but there must be a better way!
You can use the following command to output a PNG file of the current screen, even in headless mode:
vboxmanage controlvm [vmname] screenshotpng screen.png
I am trying to get some integration testing for bootstrapped virtualboxes up and running and ran into the exact same problem. After finding out that VRDP is a dead end, because RDP cannot send text but only bitmaps, I remembered that some cloud providers require grub to output to ttyS0.
What is ttyS0 you ask? It's the serial console of course :-)
Here's how to configure Debian to output to serial console
VirtualBox allows you to redirect the serial port into either a file or a pipe, meaning you should be able to get all the information you desire by simply reading the specified filepath.