I am trying to configure auditing for docker daemon as follows:
Add the line below to the /etc/audit/audit.rules file:
-w /usr/bin/dockerd -k docker
Then, restart the audit daemon using the following command:
service auditd restart
This gives the following error:
Failed to restart auditd.service: Operation refused, unit auditd.service may be requested by dependency only.
Using systemctl also doesn't work. Is there a workaround or a fix for this?
Updating RefuseManualStop to no in the /usr/lib/systemd/system/auditd.service
RefuseManualStop=no
Then reload the daemon as follows:
systemctl daemon-reload
Probably 2 years too late but for anyone facing the same on redhat 7. Run;
service auditd condrestart|try-restart
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-starting_the_audit_service
Found a solution here. The method to use is
sudo systemctl kill auditd
sudo systemctl start auditd
Related
I have been working with Docker for about two months now, working on Windows/WSL. The other day I needed to restart my machine and once it restarted I tried setting up my docker containers again and ran into an issue that I have had before, however. All the solutions I used last time do not work, and none on google work either.
I have tried a lot of things, every single possibility on the internet I could fine and I have been stuck on this for at least 8 hours already and wish to waste no more time on it. I will list a few I have already tried but do not work:
sudo usermod -aG docker $USER
sudo ln -s /mnt/c/Program\ Files/Docker/Docker/resources/bin/docker.exe /usr/bin/docker
using sudo
restarted docker
reinstalled docker desktop (windows)
The command within our make file runs this:
docker-compose up -d
We use a MakeFile to make our lives a lot easier in terms of docker commands so usually I would run this command and it should just bring the container up and work fine. But instead I get this:
ERROR: Couldn't connect to Docker daemon at http+docker://localhost - is it running?
If it's at a non-standard location, specify the URL with the DOCKER_HOST environment variable.
Makefile:13: recipe for target 'up' failed
make: *** [up] Error 1
I was then recommended trying sudo dockerd which I then get this error, which does half explain the issue but I could not find a clear answer on how to fix my issue:
failed to start daemon: Error initializing network controller: error obtaining controller instance: failed to create NAT chain DOCKER: iptables failed: iptables -t nat -N DOCKER: iptables v1.6.1: can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
(exit status 3)
I am really hoping someone is able to help me with this as I am so stuck and need to get this to work.
It turns out the issue was to do with the groups. The solution that I found worked was to remove the user group "docker" using:
sudo groupadd docker
sudo usermod -aG docker $(whoami)
Then I ran the command for my make file and it worked!
I hope this benefits some of you!
From this github issue:
Try running dockerd or sudo dockerd if required first to start daemon. If you start dockerd with sudo you may want to run docker-compose up with sudo also. otherwise it's fine.
I had the same issue. I managed to fix this by upgrading to WSL 2 from version 1.
To get your current version in powershell :
wsl -l -v
For me it was written version 1.
To upgrade from 1 to 2 :
wsl --set-version <NAME-FROM-PREVIOUS-COMMAND> 2
For me it was Ubuntu :
wsl --set-version Ubuntu 2
And then the docker daemon could be started as expected inside wsl. (with sudo in my case)
sudo dockerd
sudo docker-compose up
I hope it could help.
On running docker-compose stop it fails to stop the docker images, and gives an error like this:
ERROR: for nginx cannot stop container: 5f5ed6d2110a0d845508ede160d8196d3e01f1d677e22e4944adc8c984800cff: Cannot kill container
5f5ed6d2110a0d845508ede160d8196d3e01f1d677e22e4944adc8c984800cff: Unknown error after kill: docker-runc did not terminate sucessfully: container_linux.go:393: signaling init process caused "Permission Denied": unknown
The images are still running properly, they just don't restart. I am running docker-compose on Ubuntu.
I was able to work around the problem by running:
sudo killall docker-containerd-shim
And then docker-compose down started working for me.
I found the solution in this bug report, and it seems that it involves a backport of a fix to the runc code.
EDIT
It seems that the root cause of these problems on my system was the Docker snap image on my Ubuntu 18.04 installation. I completely removed the snap image and reinstalled Docker using https://get.docker.io, and I no longer encounter these problems. In the meantime, the rest of my answer above worked for me as a workaround.
Somehow this worked for me.
$ sudo killall containerd-shim
2021: in my case, I am using the
sudo aa-remove-unknown
then, run
sudo docker-compose down
then, the application down successfully
I had the same problem and what helped me was to kill all of my containers, delete all of my images and data volumes, and start over.
If you have no problem DELETING all of your data volumes and all of your unused images, you can try these two commands:
sudo service docker restart
docker system prune --all --volumes
There is such a solution.
Stop and restart docker services
sudo systemctl stop docker.socket
sudo systemctl stop docker
sudo systemctl restart docker
After check -> docker ps
if cant be deleted to containers then try this -> docker container rm container_name --force
Ports may not have been deleted. this will cause conflict.
Find used port PID -> sudo lsof -i:port
and kill sudo kill -9 PID
I installed docker on a CentOS server but it failed while starting.
Below is the error which i got after typing systemctl start docker
Job for docker.service failed because the control process exited with
error code. See "systemctl status docker.service" and "journalctl -xe"
for details.
enter image description here
Me too faced the same error and below worked for me.
Edit the /etc/systemd/system/docker.service.d/10-machine.conf file
Change the ExecStart to be /usr/bin/dockerd instead of /user/bin/docker daemon, restart the systemctl daemon-reload, and run sudo systemctl -f start docker again.
Funnily enough only today we started having this issue with our dev env. Our version of docker that was provisioned wasn't pinned, and it looks like the most recent version available (1.13.1-53.git774336d.el7.centos) is causing problems as per your question. Targeting a previous version seems to get it back into a working state:
yum install docker-1.12.6-71.git3e8e77d.el7.centos
Be sure to remove the previous version first
yum remove docker
It Worked for me:
yum remove containerd
And remove previous docker and reinstall docker < of course >
I get following error when starting Docker daemon from command line:
Error starting daemon: error while opening volume store metadata database: timeout
OS is Linux.
Any pointer how can I resolve this?
(Google search didn't yield anything)
It depends on your exact Linux distro, and docker version.
See for instance issue 26022: it has the same error message on Fedora after a
yum -y install docker-engine-1.13.1-1.el7.centos
Try and follow again the full installation procedure for your exact distro.
After investigating a lot and trying many commands, this has worked for me:
*Do not use '&&' to make the most compact command or otherwise it will not work.
sudo rm /var/run/docker.pid
sudo systemctl stop docker.socket
sudo systemctl stop docker
systemctl start docker
systemctl enable docker
sudo systemctl start docker
If this error appears ( running $ docker [command] ):
Cannot connect to the Docker daemon at unix:///home/mg/.docker/desktop/docker.sock. Is the docker daemon running?
The first thing you should do is to have Docker Desktop installed on your pc, of which you can get here https://docs.docker.com/desktop/windows/wsl/
You should also enable wsl2, Just going through the documentation from the link above should be enough.
Also make sure Settings > General > Use the WSL 2 based engine... box is checked.
REFERENCE https://stackoverflow.com/a/72890783/21061651
When I in a fedora container systemctl use, I get:
Failed to get D-Bus connection:: Unknown error -1
Does someone know how to fix this? Or can systemctl not be used in a docker container?
The systemctl command talks to systemd over a DBus connection. It is unlikely that you are running systemd in your container, so systemctl has nothing with which to talk.
While it is possible to run systemd in a container, doing so is often (but not always!) a sign that you need to rethink the architecture of your containers.
I have fixed a similar issue, check this answer.
The main idea is to make /usr/sbin/init the first process inside the container.
As already said, the standard systemctl needs SystemD. But for a command like "systemctl enable " or starting a service process one actually do that without a running SystemD.
The "systemctl enable" will essentially look into the sshd.service file for a "WantedBy=multi-user.target" clause and then it creates a symlink in /etc/systemd/system/multi-user.target.wants/. Similary, a "systemctl start" will look for the "ExecStart=/usr/bin/sshd" clause in the ssh.service file.
If you do not want look that up and run those parts manually, you could use my systemctl.py helper from the docker-systemctl-replacement which can do the interpretation of systemd service files for you.