On Windows Subsystem for Linux running Ubuntu 16.04, I've installed InfluxDB 1.4.2 according to the Influx documentation. I can't run it as a service or with systemctl, probably because WSL doesn't support that (see GitHub issues 994 and 1579), so neither of these work:
$ sudo service influxdb start
influxdb: unrecognized service
$ sudo systemctl start influxdb
Failed to connect to bus: No such file or directory
If I run $ sudo influxd, Influx starts, but then crashes with the message
run: open server: open tsdb store: cannot allocate memory
How do I fix the "cannot allocate memory" error?
On Win10 Spring 2018 Update, I ran the following:
sudo apt install influxdb influxdb-client -y
Installed fine.
As per the docs …
… started the service using:
sudo service influxdb start
Started fine:
Let's connect, examine and create a database:
Please let me know if I've done anything wrong here to repro, otherwise, looks like this issue has been resolved.
I just had this problem when installing in WSL but systemd was installed. When installing the influxdb package it registered a systemd unit so I was unable to start it using init.d. I solved this using this guide. Instead of the dead link to the init.sh script i searched for an older version and found this.
Steps to get InfluxDB working in WSL (at least when systemd is installed):
Install influxdb using sudo apt install influxdb
Copy the content of this file into a new file at location /etc/init.d/influxdb
You can now start influxdb using sudo service influxdb start.
For me it showed an error message while starting but it still started correctly.
Related
I followed the instructions to install the nvidia-docker2 from the official documentation https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/install-guide.html
Whenever I run their test example:
sudo docker run --rm --gpus all nvidia/cuda:11.6.2-base-ubuntu20.04 nvidia-smi
I still get the error:
docker: Error response from daemon: could not select device driver "" with capabilities: [[gpu]]. 3
I rebooted but still no effect.
I am on Ubuntu 22.04 with my nvidia drivers updated.
Nvidia-smi works on the machine but not working using docker
EDIT (SOLVED): Finally I found out what was going on.
When reinstalling, it was working, however if rebooting, it was going again to a previous state where it was not working.
This was due to the installation of another docker service installed using "snapd" so I had to purge completely docker:
sudo snap remove docker and after I could "Reinstall everything" and it finally is stable, even after rebooting
Unfortunately I was not able to "Fix" properly the issue so I purge all docker package and all nvidia container packages and reinstalled everything and now it works!!
Good old methods work fine :)
you need to restart the docker daemon :
sudo systemctl restart docker
if the problem still occurs install the nvidia-container-toolkit then restart docker daemon.
Sometimes I can't communicate with my Nvidia GPUs inside a docker container when I came back to my workplace from home, even though the previously launched process that utilizes GPUs is running well. The running process (training a neural network via Pytorch) is not affected by the disconnection but I cannot launch a new process.
nvidia-smi gives Failed to initialize NVML: Unknown Error and torch.cuda.is_available() returns False likewise.
I met two different cases:
nvidia-smi works fine when it is done at the host machine. In this case, the situation can be solved by restarting the docker container via docker stop $MYCONTAINER followed by docker start $MYCONTAINER at the host machine.
nvidia-smi doesn't work at the host machine nor nvcc --version, throwing Failed to initialize NVML: Driver/library version mismatch and Command 'nvcc' not found, but can be installed with: sudo apt install nvidia-cuda-toolkit error. Strange point is that the current process still runs well. In this case, installing the driver again or rebooting the machine solves the problem.
However, these solutions require stopping all current processes. It would be unavailable when I should not stop the current process.
Does somebody has suggestion for solving this situation?
Many thanks.
(sofwares)
Docker version: 20.10.14, build a224086
OS: Ubuntu 22.04
Nvidia driver version: 510.73.05
CUDA version: 11.6
(hardwares)
Supermicro server
Nvidia A5000 * 8
(pic1) nvidia-smi not working inside of a docker container, but worked well on the host machine.
(pic2) nvidia-smi works after restarting a docker container, which is the case 1 I mentioned above
For the problem of Failed to initialize NVML: Unknown Error and having to restart the container, please see this ticket and post your system/package information there as well:
https://github.com/NVIDIA/nvidia-docker/issues/1671
There's a workaround on the ticket, but it would be good to have others post their configuration to help fix the issue.
Downgrading containerd.io to 1.6.6 works as long as you specify no-cgroups = true in /etc/nvidia-container-runtime/config.toml and specify the devices to docker run like docker run --gpus all --device /dev/nvidia0:/dev/nvidia0 --device /dev/nvidia-modeset:/dev/nvidia-modeset --device /dev/nvidia-uvm:/dev/nvidia-uvm --device /dev/nvidia-uvm-tools:/dev/nvidia-uvm-tools --device /dev/nvidiactl:/dev/nvinvidiactl --rm -it nvidia/cuda:11.4.2-base-ubuntu18.04 bash
so sudo apt-get install -y --allow-downgrades containerd.io=1.6.6-1 and sudo apt-mark hold containerd.io to prevent the package from being updated. So do that, edit the config file, and pass all of the /dev/nvidia* devices in to docker run.
For the Failed to initialize NVML: Driver/library version mismatch issue, that is caused by the drivers updating but you haven't rebooted yet. If this is a production machine, I would also hold the driver package to stop that from auto-updating as well. You should be able to figure out the package name from something like sudo dpkg --get-selections "*nvidia*"
I am trying to run a private tangle on my computer through linux docker containers.
Therefore I followed the guide over at https://wiki.iota.org/chrysalis-docs/tutorials/one_click_private_tangle
Every step succeeded up until we tried to execute
./private_tangle.sh install
This reports
Error 1
as seen in the screenshot below:
We do net get any further information, is anyone familiar with this error, or has any clue how to get some more information on the error so that we can at least have a clue where to look?
Some further information:
After executing docker ps -a we see that not a single container is running.
I am running on a windows 10 machine
I execute the commands from within ubuntu (version 20.04)
Ubuntu, docker-desktop and docker-desktop-data are all running WSL2
Docker integration with ubuntu is activated
I thought the error could maybe come from no hornet node initially being installed, so I installed a hornet node successfully, according the guide that https://wiki.iota.org/chrysalis-docs/tutorials/one_click_private_tangle. This changed nothing to the Error.
The version of docker and docker-compose are compliant with the requirements
If any more details are needed to help me solve this problem, please let me know.
I used the documentation (https://wiki.iota.org/chrysalis-docs/tutorials/one_click_private_tangle) to install these containers on my local ubuntu 18.04.
My docker version is: 20.10.12
And docker-compose version is: 1.29.2
By following the steps of the tutorial I managed to successfully start all of the containers without trouble.
My guess here would be that the permission of the 'private-tangle.sh' are not correct or that there is permission problem on the docker level.
You should start with checking the permission level of the private-tangle.sh script by using $ls -l
Here is my output -rwxrwxr-x 1 ben ben 9413 Jan 11 11:28 private-tangle.sh
It could also be due to the docker rights if you have to use sudo when executing a docker command it will give some troubles when executing the script.
You need to add yourself to a docker group to be able to run docker commands without sudo. You can do this by running sudo usermod -aG docker $USER with damiaan-vh as $user.
Solution from source https://stackoverflow.com/posts/70665394/edit
Suggesting to downgrade ubuntu version to 18.04 for more stable version.
For reinstalling the docker and docker-compose programs follow this documentations
(docker: https://docs.docker.com/engine/install/ubuntu/ )
(docker-compose: https://docs.docker.com/compose/install/ )
I am using the latest Ubuntu build 15.10 and have gone through the install of ElasticSearch here: https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-service.html
However, even after executing the command that adds the service to the start up process.
sudo update-rc.d elasticsearch defaults 95 10
sudo /etc/init.d/elasticsearch start
Rebooting the computer, then going to localhost:9200 gives a 404.
And every single morning I run the sudo /etc/init.d/elasticsearch start, then the sudo update-rc.d elasticsearch defaults 95 10 in hopes that tomorrow will be a different day, to find my machine in the exact same state as yesterday.
On a side note, my machine at work uses the same version of Ubuntu and the steps described above worked on the first try.
If anyone has overcome this issue, your insight would be very appreciated!
Thanks you!
Ubuntu, since version 15.04, is using systemd by default instead of the older upstart for handling services and init scripts. I think you need to initialize elasticsearch differently, as described in the ES docs.
Something like:
sudo /bin/systemctl daemon-reload
sudo /bin/systemctl enable elasticsearch.service
sudo /bin/systemctl start elasticsearch.service
I've installed Docker Toolbox v1.8.1b on OSX 10.10.5
This also installs VirtualBox v5.0.2
However, when the installation has finished and I run the Docker Quickstart Terminal, it does its thing, creates a new VM in virtualbox but then doesn't start it, finishing with the message that default is not running.
When I try to run the machine using docker-machine start default I get the message exit status 1.
When I go to VirtualBox and attempt to start the machine there, I get the following error message:
Failed to load VMMR0.r0 (VERR_VMM_SMAP_BUT_AC_CLEAR).
Result Code:
NS_ERROR_FAILURE (0x80004005)
Component:
ConsoleWrap
Interface:
IConsole {872da645-4a9b-1727-bee2-5585105b9eed}
So is anyone else getting this or am I not following the instructions properly?
I had exactly the same problem. It seems that there is a bug in recent versions of VirtualBox, which is fixed in the latest test build. See https://www.virtualbox.org/ticket/14412
I downloaded the latest VirtualBox test build from
https://www.virtualbox.org/wiki/Testbuilds
then used the uninstaller script provided in that installer to remove the buggy version before installing the new one.
Running the Docker QuickStart Terminal again got the default VM running, but it was missing a ca.pem file:
docker is configured to use the default machine with IP 192.168.99.100
For help getting started, check out the docs at https://docs.docker.com
open /Users/justin/.docker/machine/machines/default/ca.pem: no such file or directory
VirtualBox confirmed that the VM was running.
I could create a new VM and use it with docker successfully (in a different Terminal window):
Justins-MacBook:~ justin$ docker-machine create --driver virtualbox dev
Creating VirtualBox VM...
Creating SSH key...
Starting VirtualBox VM...
Starting VM...
To see how to connect Docker to this machine, run: docker-machine env dev
Justins-MacBook:~ justin$ eval "$(docker-machine env dev)"
Justins-MacBook:~ justin$ docker run hello-world
...
I then deleted the default VM:
Justins-MacBook:.docker justin$ docker-machine stop default
Justins-MacBook:.docker justin$ docker-machine rm default
Successfully removed default
Running the Docker QuickStart Terminal created a new default VM, and docker is now working happily with it.
Update: There is an open issue for this at: https://github.com/docker/toolbox/issues/119
Just wanted to add: if you have docker for mac installed, they intentionally removed the docker-machine command starting from version 2.2.0.
You can find the discussion here: https://github.com/docker/for-mac/issues/4208
So, you need to install docker-machine separately, using the commands provided by #shivanikoko or using brew:
brew install docker-machine
ON Osx after installing docker or updating docker we have to reinstall the docker-machine again to make it work in CLI.
Running the command below helped me.
base=https://github.com/docker/machine/releases/download/v0.16.0 &&
curl -L $base/docker-machine-$(uname -s)-$(uname -m) >/usr/local/bin/docker-
machine &&
chmod +x /usr/local/bin/docker-machine