I have compiled and installed screen tool on Galileo running on Yocto.
http://www.gnu.org/software/screen/
When I run the tool everything is OK, I can create many sessions. However when I close the terminal all my sessions are closed (when I do "screen -ls" from other terminal there are no sockets). This is not happening in any other Linux distribution.
Regards,
Yevgeniy
Are you running screen from inside a ssh connection? There was a bug in earlier releases of the devkit where on disconnect systemd killed all processes started by the daemon, which isn't what you want. This has been fixed so upgrading your image should be sufficient.
If you can't get the upgrade, the fix is to add "KillMode=process" to the end of /lib/systemd/system/ssh#.service.
Related
I have a process that responds perfectly well to CTRL+C on my local machine. And it appears to also be working.
But on an EC2 instance it freezes and becomes a defunct or zombie process.
kill -9 <PID> doesn't remove it and I have to reboot the EC2 instance to clean it up properly.
When it runs it also loads an in house developed shared library that I have no influence over and have no access to any source code in it to see what it's doing. This library also uses CUDA and appears to start multiple threads.
I tried installing a signal handler on the main thread and it does get installed but calling _exit doesn't shut the whole process down, it seems to still be waiting.
Why might be happening here that is preventing CTRL+C from exiting the process cleanly? Can I override or examine what the other threads could be doing?
Ah, I found the problem. I'll leave the question as it stands in case it helps someone else.
It turns out that on my PC, I have a GTX 680 and the drivers get installed when installing CUDA. On EC2 the card is a GRID K520, and the driver installed by CUDA doesn't work. I downloaded and installed the latest stable card specific driver and it then worked.
The discovery was made after running nvidia-smi and it wouldn't print any details about the card but rather would just show Killed. Run nvidia-smi again and it would lock up the console.
Unfortunately, I hadn't tested that CUDA app's were working but relied on the driver appearing to print a message in the log saying it was loaded and assumed it was working.
Updating the driver consisted of downloading the latest driver from nvidia (use the .run version). Then:
sudo modprobe -r nvidia_uvm
sudo modprobe -r nvidia
Finally install it with a command like:
sudo ./NVIDIA-Linux-x86_64-3xx.xx.xx.run
I then rebooted the instance and verified it with nvidia-smi
This link was insightful - CUDA 7.5 unstable on EC2
I have been trying to run the exec node in Node-RED, hoping that it would use the command prompt native to Windows 10. I would provide a command that would run a python script I have. If the command went through, my windows button would be clicked. Node-RED says "Successfully Deployed" when I run my single exec node, but the windows button does not pop up. I am concluding that Node-RED does not know how to access the Windows command prompt, which is very frustrating. Is there a way to run python scripts from Node-RED while running Windows?
In case it is relevant, I am using Node-RED to communicate with the bluetooth low energy protocols of the Lightblue Bean Arduino board. I am sure that there is not a python library for communicating with bluetooth low energy for Windows. For Mac and Linux, sure, it's implemented by Adafruit. But they say they do not have anything for Windows.
Many thanks.
I asked someone and they told me you cannot have a standalone exec node- you need to use an inject node to get everything going. I checked off "Inject once at start?" and my script ran just dandy.
I'm running a VM in Azure with Ubuntu 14.04. I've installed XFCE and use X2GO to remote desktop to the machine.
I've downloaded the VS Code and unzipped the files. When I run Code from a terminal I get the following error:
WouterDeKort#UbuntuDev:~/tools/web/visual-studio-code$ ./Code
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
WouterDeKort#UbuntuDev:~/tools/web/visual-studio-code$ [ , [Error: channel closed] ]
Any idea what I'm doing wrong?
DISCLAIMER ;-) I'm a total Linux newby. I've just installed Linux for the first time today and I have no idea what I'm doing ;-)
The work-a-round is in issue 3451. After running this, I was able to launch it from Debian Jessie with LXDE over X2Go.
sudo sed -i 's/BIG-REQUESTS/_IG-REQUESTS/' /usr/lib/x86_64-linux-gnu/libxcb.so.1
I have the same problem using X2GO and LXDE. Works okay (but slowly) using MobaXterm so apparently this is a problem specific to X2GO.
For anyone who still wonder what is the best choice if you want to start Visual Studio Code on a headless Ubuntu - the winning combination is:
Ubuntu Server + xfce + nomachine remote desktop
VS Code starts immediately without any hacks, you can set your resolution however you like, and nomachine is blazingly fast.
I try to build a reproducible automated build environment based on Debian 8.1 Jessie.
I created a boot iso image based on a netinstall image and put a preseed.cfg file in int for automatic installation.
I managed to get it bootable with BIOS and UEFI and can install a KDE Developer Debian in VMWare Workstation 11 fully automated.
I have also a server iso image to install a debian Server with Jenkins, both with BIOS and UEFI Boot.
But after the installation, the Version with UEFI Boot shows a black Screen when started.
I can blindly log in, start the gui with "startx" and see my installed xfce desktop. When i quit xfce the console is usable and visible.
I tried suggested bootparameters "nomodeset" and "vga=Linux" that i found with google to no avail.
I also tried to debug the boot prozess, to find out which command leads to a blank screen, but i did not find the right place to delay the processes at bootup so i can see when the messages dissapear (quiet bootparameter was removed :-)
I also tried to reset the console to no avail.
Can anybode point me to a tool that does the same "switching" like X so the console is useable?
Can anybody give me some hints how to debug the bootprocess to find out which command is causing this behaviour?
I dont want to install X because this should be a headless server system later.
I managed to get my system to boot using the kernel command line modprobe.blacklist=vmwgfx, or placing 'blacklist vmwgfx' in /etc/modprobe.d/*.conf
I assume it is some bug in the vmwgfx module, however as this workaround works for me I have no immediate need to investigate further.
When using Eclipse over X-Windows on a remote shell (X port forwarding), is there a way to simply detach my X connection and come back to the process later. For a little more clarity, I'm on a Windows machine and have to reboot. I'd like to keep Eclipse running and come back where I left off. Eclipse is running on my Windows machine through an X-Server connected to a Linux box.
I'm thinking something like tmux could do the trick. However, I do a Ctrl-Z to stop Eclipse and it won't close the Eclipse Window. If I restart the X-Server in Windows, Eclipse fails when I try fg 1. Any other options?
Xpra did everything that I needed, but it was not clear exactly how it worked. I was able to get it working by opening two PuTTY sessions in windows, one server and one client. Also, the Google Code is out-dated. Instead, install from http://xpra.devloop.org.uk/dists/xpra-0.0.7.9.tar.bz2. I'm not sure how it's different, but it worked for me. The README tells how to build the package. It is necessary to apt-get a bunch of other stuff. But, here are the missing pieces on how to get it work as I describe above:
Setup server:
cd ~/download/xpra/xpra-0.0.7.9
export PYTHONPATH=$PWD/install/lib/python:$PYTHONPATH
./install/bin/xpra start :10
export DISPLAY=:10
xterm&
Setup client:
cd ~/download/xpra/xpra-0.0.7.9
export PYTHONPATH=$PWD/install/lib/python:$PYTHONPATH
./install/bin/xpra attach :10
Notes:
The Windows xpra installer is not needed for this configuration. I don't know what it's supposed to do.
Be sure to run Xming on Windows.
Be sure to enable X port forwarding on the client PuTTY window.
Launch whatever you want from the xterm window. (ie Eclipse)
You can close the server window once xterm is up.
Hit ctrl-c in the client window to detach from the session.
Do all the client commands again to re-attach..even after restarting PuTTY, the Xming, or Windows itself.
I have zero experience with it, but xpra sounds like exactly what you're looking for.