I was able to start the lightdm and manager and greeter in a wsl2 debian in VcXsrv setting. When first starting the debian bash terminal and first starting the VcXsrv instance it appears to work fine. I can login at the greeter and be taken to gnome shell desktop.
/etc/init.d/dbus start
/etc/init.d/lightdm start
However, when I logout, gnome shell doesn't actually quit and the greeter appears as overlayed on top of the gnome shell... it appears gnome shell does not actually quit (the processes are still alive checking with ps).
The only way to start fresh is to exit the VcXsrv instance AND stop the LxssManager instance and restart it.
Why is gnome-shell staying alive after logout?
I would like to switch to xfce desktop. (I was already able to start xfce using xfce4-session).
Settings for /etc/lightdm/lightdm.conf
[Seat:*]
type=xremote
xserver-share=true
xserver-hostname=192.168.0.116
xserver-display-number=0
I'm not sure where 192.168.0.116 came from, but try replacing it with $(awk '/nameserver / {print $2; exit}' /etc/resolv.conf 2>/dev/null) or $(awk '/nameserver / {print $2; exit}' /etc/resolv.conf 2>/dev/null):0
When I try to resume a screen session with
$ screen -r name
I get
WriteMessage: Bad file descriptor
How can I fix that? (Ideally being able to resume the screen, but at least remove it if resuming is not possible)
The problem why it occurs might be that the SSH connection was interrupted.
This worked for me:
Find the process's pid by running screen -R
Use screen -r <pid> instead of screen -r <name>
If the screen didn't detach from previous ssh session, you might also need to kill dead sshd process.
I got this error when trying to detach all screens with screen -D. I had attached the screen with
screen -R screen-name-here
To detach, I needed to specify the screen name:
screen -D screen-name-here
I'm trying to run the "screen" utility on Windows Subsystem for Linux on Windows 10 (Version 1703, OS Build 15063.483).
It seems that I need additional permissions to run it (it works if I "sudo" it), but I don't understand why that is necessary.
What is the recommended way to set this up?
Is there some reason why this isn't the default set up?
$ screen
Cannot make directory '/var/run/screen': Permission denied
From an answer on SuperUser I discovered that you have to run
sudo /etc/init.d/screen-cleanup start
Then screen works fine for me.
EDIT: after installing Ubuntu 20.04 the problem went away (*).
As Krease pointed out, the best solution is the one described in this SuperUser post.
Add the following to your .bashrc:
export SCREENDIR=$HOME/.screen
[ -d $SCREENDIR ] || mkdir -p -m 700 $SCREENDIR
See also issue 1245 on github.
--
(*) now this warning comes up, but seems harmless:
sleep: cannot read realtime clock: Invalid argument
sudo screen # which creates dir /var/run/screen
chmod 777 /var/screen # so that non-root users can create their own screen dir in this dir.
I am used to using linux terminals and nohup over ssh to issue commands that run in the background even when logged out of the ssh session. For some reason nohup seems to be broken in the latest MACOS. For that reason I am trying to executing this small sample script using screen command.
sleep 10
echo "this is my test file" > testfile
This file is saved as tst script. And then I issue the following command.
ssh sohaib#localhost screen -dm sh testscript
However nothing happens. screen just exits quietly without writing to the file testfile.
If I run this without ssh it works as desired. What am I doing wrong here?
The issue is that after your script exits the screen exits. The -dm is for deamons, i.e., scripts that keep running.
Showing the screen exiting after 10 seconds:
On remote host (file is executable):
ttucker#merlin:~$ cat test.sh
#!/bin/bash
echo derp > /tmp/test.txt
sleep 10
Command on local machine:
[ttucker#localhost ~]$ ssh ttucker#merlin 'screen -dmS my_screen ~/test.sh'
After run.
On remote machine, a few seconds after screen is running:
ttucker#merlin:~$ screen -ls
There is a screen on:
23141.my_screen (11/21/2016 07:05:11 PM) (Detached)
1 Socket in /var/run/screen/S-ttucker.
On remote machine, over 10 seconds later:
ttucker#merlin:~$ screen -ls
No Sockets found in /var/run/screen/S-ttucker.
Modifying the script to keep running, and so, keeping the screen up:
If you are really running a script that needs to stay up you can do the following in the script:
#!/bin/bash
while true; do
# Do something
sleep 10
done
This will do something, wait 10 seconds, then loop again.
Or, detaching the screen manually:
You can ssh to the remote machine, run screen, then press Ctrl+A,D, press Ctrl and hold, then hit A then hit D. You can now exit the SSH session and the screen will stay running.
I just upgraded to MacOS Sierra, and I realized that I can't seem to run the "ssh -X" command in the Terminal anymore. It used to launch xterm windows, but now it's like I didn't even put the -X option anymore. It was working absolutely fine right before I updated. Other than going from OS X Yosemite to MacOS Sierra, I didn't change anything else in the setup.
EDIT:
As suggested, this is what I found in the debug logs that might be causing this problem.
debug1: No xauth program.
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
I didn't need to reinstall XQuartz, but, based on Matt Widjaja's answer, I came up with a refinement.
sudo vi /etc/ssh/ssh_config (This is ssh client config, not sshd_config)
Under the Host * entry add (or add where appropriate per-host)
XAuthLocation /usr/X11/bin/xauth (The location of xauth changed in Sierra)
ServerAliveInterval 60 (Pings the server every 60 seconds to keep your ssh connection alive)
ForwardX11Timeout 596h (Allows untrusted X11 connections beyond the 20 minute default)
No need to restart ssh, except, of course, existing ssh client connections.
It sounds like -Y (trusted X11) would be preferable to untrusted. If you switch over to trusted, the ForwardX11Timeout line can probably be removed.
The ServerAliveInterval line is also an optional preference.
It may also be possible to make these changes in ~/.ssh/config (the user's config file) but the permissions have to be correct.
EDIT: I removed ForwardX11 and ForwardX11Trusted. They aren't needed and ForwardX11 is less secure and causes problems for git (or other tools using ssh).
I noticed macOS Sierra resetted my X11 settings so that it disabled my xAuth program. To re-enable xAuth on macOS Sierra:
Reinstall X11/xQuartz to presumably reset any changes macOS Sierra made. I made the following changes below too although it sounds like this might be enough.
Load up a Terminal
sudo <text editor of your choice> /etc/ssh/sshd_config
In that file, uncomment the following lines, and set it to these values:
X11Forwarding yes
X11DisplayOffset 10
[Update on 10/07/2017] When you reinstall X11/XQuartz, above all else, it should add an: XAuthLocation <path_to_your_xauth> where mine was in /opt/X11/bin/xauth. This was probably the golden step that explained why reinstalling worked.
Restart ssh via the terminal. I did this by running:
sudo launchctl unload /System/Library/LaunchDaemons/ssh.plist
sudo launchctl load -w /System/Library/LaunchDaemons/ssh.plist
I'm having the same issues with X11 forwarding with the -X option after upgrading to Mac OS X Sierra.
Have a look at the ssh option -Y (trusted X11 forwarding). While using ssh -Y <host> things work for me.
It's an old question but I recently ran into the same issue on my Mac running 10.12.6. The DISPLAY variable is not set in the terminal and ssh -X doesn't work. This is what I did that solved the problem:
Reinstall XQuartz using Homebrew:
brew cask install xquartz (the option --forced may be necessary)
Add the XQuartz launcher to the system default (following the solution in this Reddit post:
launchctl load -w /Library/LaunchAgents/org.macosforge.xquartz.startx.plist
Restart the system.
After doing these, my DISPLAY variable is set properly:
$ echo $DISPLAY
/private/tmp/com.apple.launchd.mfXFpzZ0gC/org.macosforge.xquartz:0
And X11 forwarding in ssh works as well.
Just adding the one line XAuthLocation /usr/X11/bin/xauth to /etc/ssh/ssh_config works on my Mac, running MacOS Sierra, to ssh into a Linux host and be able to run X Windows programs remotely and have them display under XQuartz on my Mac.
My solution to this was the following.
(1) Launch xquartz before trying the ssh -X. In the xquartz options, I just enabled 'Open at login', and then it is always running in the background.
(2) Go to the xquartz Preferences menu, and on the Security window, click the box that says "Allow connections from clients".
After doing these things, everything works fine.
Just upgraded my macbook from El Capitan to Sierra. Simply reinstalling Xquartz has done the trick for me, using ssh -X [linux server]
I spent the whole day looking for solution only to realize that the recent Sierra does not ship with XQuartz installed https://support.apple.com/en-gb/HT201341. Upon install (https://www.xquartz.org/) all works.
If Quartz is installed, all that is needed is to add the line "X11Trusted yes" under "Host *" in the /etc/ssh/ssh_config file.
restarting XQuartz worked for me.
In my case, adding XAuthLocation /opt/X11/bin/xauth to /etc/ssh/sshd_config (note that it's not /etc/ssh/ssh_config) on macOS host worked after installing XQaurtz via brew install --cask xquartz as XQaurtz provide xauth binary