I am running a virtual machine in Google Cloud. I have installed the default Debian OS, and configured the desktop environment for remote connection, as explained here: https://cloud.google.com/solutions/chrome-desktop-remote-on-compute-engine
I have been able to connect to the instance via Chrome Remote Desktop, however periodically I have the problem that the Remote Desktop says the vm instance is online, however if I try to connect to it I get:
Looking at the Google Cloud console, the instance is clearly running. Normally if I restart the instance the problem is solved, however I have processes running on the instance that I do not want to stop.
UPDATE:
Following the advice from Serhii Rohoza I ran
sudo systemctl status chrome-remote-desktop
The status looked normal, listing:
Active: active (exited) since...
I then ran
sudo systemctl restart chrome-remote-desktop
and this solved the problem, I could log into remote desktop again, but it seemed the VM instance had restarted, which is a big problem since I am running processes on it that should not shut down. I guess this is a problem to send to Google Cloud Services support.
UPDATE 2:
I'm still running into this problem. I normally have a Jupyter Notebook running on the VM - this Notebook must keep running. When I saw the message saying that the remote computer is offline, I logged in via ssh and checked if the Jupyter Notebook is running:
jupyter notebook list
This returned:
http://localhost:8888/?token=9110bf40789971b5e252a272e9497039b4f3b45e506348df :: /home/qgenixtech
So the Notebook was running. I then ran:
sudo systemctl restart chrome-remote-desktop
and after that again:
jupyter notebook list
and then it shows no Notebooks running. So the restart command closed down the Notebook (and also all other open windows on the desktop).
UPDATE 3:
I spoke to a support technician at Google. The problem is on the Remote Desktop side, not the virtual machine. According to the technician this is a known problem, by he didn't have a solution for it. He referred me to these two links from Google Support:
https://support.google.com/chrome/thread/10213547?hl=en
https://support.google.com/chrome/thread/3333421?hl=en
The next option for me is to look at something like X2go
To solve your issue you should follow documentation Troubleshooting and check status of the Chrome Remote Desktop service with command:
sudo systemctl status chrome-remote-desktop
and check log messages at /tmp/chrome_remote_desktop_DATE_TIME_*.
To investigate why your VM instance was restarted you should look for some clues at the logs:
Go to Compute Engine -> VM instances -> click on NAME_OF_YOUR_VM -> find section Logs -> click on Stackdriver Logging. More information you can find in the documentation Viewing logs (Classic)
Go to Compute Engine -> VM instances -> click on NAME_OF_YOUR_VM -> find section Logs -> click on Serial port 1 (console). More information in the documentation Viewing Serial Port Output
You can contact with Google Cloud Support as well.
In addition, have a look at the documentation Setting instance availability policies.
same issue. when checking logs i see:
2021-01-05 14:29:38,319:INFO:Starting Xvfb on display :20
xdpyinfo: unable to open display ":20".
2021-01-05 14:29:40,837:INFO:X server is active.
restarting service or even VM doesn't work.
i need to delete connection on "client" and re-auth with /headless link
Related
I'm testing neo4j enterprise 3.3.3 on AWS and trying to run an online backup on a db, which is located on a different server.
I run on my AWS instance:
neo4j-admin backup --backup-dir=~/backup --name=graph.db-backup --from=0.0.0.0:4444
where I change 0.0.0.0 for my open IP for the external neo4j db and 4444 for my port.
But then I get this error:
Failed to load private key: /var/lib/neo4j/certificates/neo4j.key
UPDATE
I fixed that by running the command with sudo (on Amazon AWS).
However, now I'm getting another error:
Failed to run a backup using the available strategies.
The documentation on backups says that you only need to uncomment some settings in neo4j.conf, which is what I've done, both on the server which is being backed up and the one that is actually running backup.
Could it be that the issue is because on AWS you have to run commands with
systemctl
And if so, how do I run neo4-admin with it?
It doesn't work if I use
systemctl neo4j-admin ...
Somebody from Neo4J — can you please help? Backup is one of the main reason to get the Enterprise version but there is not enough documentation on how to use it.
This question seems very basic, but I wasn't able to quickly find an answer at https://cloud.google.com/compute/docs/instances/create-start-instance. I'm running a MicroMDM server on a Google Cloud VM by connecting to is using SSH (from the VM instances page in the Google Cloud Console) and then running the command
> sudo micromdm serve
However, I notice that when I shut down my laptop, the server also stops, which is actually why I wanted to run the server in a VM in the first place.
What would be the recommended way to keep the server running? Should I use systemd or perhaps run the process as a Docker container?
When you run the service from the command line, you "attach" it to your shell process, when you terminate your ssh session, your job gets terminated also.
To make a process run in background, simply append the & at the end of the command, in your case:
sudo micromdm serve &
This way your server is alive even after you quit your session.
I also suggest you to add that line in the instance startup script, if you want that server to always be up, so that you don't have to run the command by hand each time :)
More on Compute Engine startup scripts here.
As the Using MicroMDM with systemd documentation, it suggested to use systemd command to run MicroMDM service on linux.First, on our linux host, we create the micromdm.service file, then we move it to the location ‘/etc/systemd/system/micromdm.service’ . We can start the service. In this way, it will keep the service running, or restart service after the service fails or server restart.
When i run the jupyter notebook it successfully runs it on the command prompt and displays the message that the jupyter notebook is running at
The Jupyter Notebook is running at:
https://(ip-172-31-37-171 or 127.0.0.1):8888/?token=9b00453fd4f9692418873e9d988013f250116bbb94277e74
However when I check web browser I just does not load and the command prompt window displays the following. Any help would highly appreciated
Google chrome displays the below message
I think your are running the Jupiter notebook with SSL enabled. You might also probably using self signed certificate.
You can try to run the server with SSL disabled, and if you want to enable SSL, you could do it easily through a load balancer.
I upgraded my Debian instance from wheezy to jessie. Everything went well. I rebooted the system and couldn't ssh to it anymore from the compute engine instance page. I noticed the system did reboot, with a different external IP address. I'm able to get to a web server I have running on the virtual machine, so I know everything upgraded and rebooted properly. Google assigned a new external IP to it and I can't login anymore.
the fact that sshd is no longer running is very unlikely, so here is my personal debug steps when I can't reach an instance on Google Cloud:
Check twice you ssh parameters (ssh keys, login user, ip address)
Activate ssh debug logs (-v) when you try to connect
Try using Cloud Shell
Check firewall rules in GCP and on your local network
Check the boot logs on the instance serial port
Re-send you SSH key in GCP > Compute > Metadata (bugs occurs sometime with the google user agent on your machine)
After that, you normally know how to connect to your instance or you know what's wrong with sshd server.
You can review the serial-port logs of the affected instance for possible clue on the issue. If you have a snapshot of your instance disk, you can create a new VM. As per the issue, is possible that recent changes may have affected the instance boot sequence and the sshd_config file.
To troubleshoot this, you can enable interactive access, connect to the instance through the serial console and enter the serial port access information to access the disk, review the ssh config files$ sudo vi /etc/ssh/sshd_config and $ sudo vi /etc/ssh/ssh_config.
If you don’t have a root password for the serial console, you could use a startup script to add it to your instance as follows:
Go to the VM instances page in Google Cloud Platform console.
Click on the instance for which you want to add a startup script.
Click the Edit button at the top of the page.
Click on ‘Enable connecting to serial ports’
Under Custom metadata, click Add item.
Set 'Key' to 'startup-script' and set 'Value' to this script:
#! /bin/bash
useradd -G sudo USERNAME
echo 'USERNAME:PASSWORD' | chpasswd
Example:
#! /bin/bash
useradd -G sudo test1
echo 'test1:pass#100' | chpasswd
Click Save and then click RESET at the top of the page. You might need to wait for some time for the instance to reboot.
Click on 'Connect to serial port' on the page.
In the new window, you might need to wait a bit and press the Enter of your keyboard once; then, you should see the login prompt.
10.. Login using the USERNAME and PASSWORD you provided.
Example:
Username: test1 AND Password: pass#100
You can also share a sanitized version of the serial port logs, for more information on what may be happening on the instance. This is not due to a change in IP address, however the serial port logs should give us more insight.
Digital Ocean rebooted all droplets 3 days ago but when they came back, my website was down.
Problem seems to arise because all related services (httpd, mysqld, iptables etc) are inactive and have to activate them again.
First of all did anybody else had the same issue and
secondly how can i run systemctl start/stop/restart <service> through droplet's console (sshd not running so droplet's console it's the only way to get into my system)?
Seems that whenever i perform this action console kicks me off, as it is in emergency mode.
I don't know if it's useful info but system is fedora 21.
Use
sudo systemctl enable service.service
to have a service start automatically when your droplet boots.