I pulled the image from public repo. The problem is when I attach and exit out of the container, it will reboot the host machine also. I'm not sure what is the problem here.
Logs : [ when restart the container]
[root#localhost ~]# docker restart 714fed06f99f
714fed06f99f
[root#localhost ~]# Write failed: Broken pipe
<-= DISCONNECTED (PRESS <ENTER> TO RECONNECT) (Fri Feb 20 16:44:35 2015)
Another Log: [ when run the "exit" command]
[root#4e53f038d880 ~]# exit
exit
Write failed: Broken pipe
<-= DISCONNECTED (PRESS <ENTER> TO RECONNECT) (Fri Feb 20 16:48:42 2015)
Do you mean the container stops when you exit from attach?
This will happen, as you're "attaching" to the main process. If you send the main process a SIGKILL (Ctrl-c), it will stop, causing the container to exit. You can use the special Docker code Ctrl-p Ctrl-q to exit the attach without stopping the container.
See http://docs.docker.com/reference/commandline/cli/#attach for more details.
Related
I am using Manjaro Linux and a while ago pulseaudio has stopped working (after an update, I assume, I did not change any configuration manually).
The symptoms:
In KDE, no sound device is found
Pulseaudio volume control cannot connect to Pulseaudio
ps x | grep pulse returns no running processes.
pulseaudio -k says no pulseaudio process is running.
However, Applications still play music using the speakers. I just cannot adjust the volume.
When running "pulseaudio" I get the following output
W: [pulseaudio] pid.c: Stale PID file, overwriting.
N: [pulseaudio] alsa-util.c: Disabling timer-based scheduling because running inside a VM.
N: [pulseaudio] alsa-util.c: Disabling timer-based scheduling because running inside a VM.
N: [pulseaudio] alsa-util.c: Disabling timer-based scheduling because running inside a VM.
zsh: killed pulseaudio
When I run "pulseaudio -D -v" I get the following output:
[pulseaudio] main.c: Daemon startup successful.
When I run "pulseaudio -k" afterwards it says it cannot abort the process because it could not been found. Also, "ps x | grep pulse" does not list any running process.
Any hints how to fix this?
The jetty on our linux server is not installed as a service as we have multiple jetty servers on different ports. And we use command./jetty.sh stop and ./jetty.sh start to stop and start jetty.
However, when I add sudo to the command, the server never stop/start successfully. When I run sudo ./jetty.sh stop, it shows
Stopping Jetty: start-stop-daemon: warning: failed to kill 18772: No such process
1 pids were not killed
No process in pidfile '/var/run/jetty.pid' found running; none killed.
and the server was not stopped.
When I run sudo ./jetty.sh start, it shows
Starting Jetty: FAILED Tue Apr 23 23:07:15 CST 2019
How could this happen? From my understanding. Using sudo gives you more power and privilege to run commands. If you can successfully execute without sudo, then the command should never fail with sudo, since it only grants superuser privilege.
As a user it uses $HOME.
As root it uses system paths.
The error you got ..
Stopping Jetty: start-stop-daemon: warning: failed to kill 18772: No such process
1 pids were not killed
No process in pidfile '/var/run/jetty.pid' found running; none killed.
... means that there was a bad pid file sitting around for a process that no longer exists.
Short answer, the processing is different if you are root (a service) vs a user (just an application).
I am trying to start my dockerd daemon by this command - dockerd &
Then i start getting the error as below -
ERRO[0036] libcontainerd: failed to receive event from containerd: rpc error: code = 12 desc = unknown service types.API
This keeps rolling again and again and i am unable to start any container after that. If i close the session and open a new session, i could see docker ps is accessible. But i am unable to start any container. While starting the container I am getting error -
docker run hello-world
docker: Error response from daemon: unknown service types.API. ERRO[0000] error waiting for container: context canceled
Please let me know if any logs are needed.
Why do you start the docker daemon using dockerd & and not systemctl start docker.service? This is probably the cause of your problem.
In order to start the daemon at boot, you need to run systemctl enable docker.service. See Getting Started with Containers.
Note that the kernel for Red Hat Enterprise Linux 6 only supports a limited subset of the functionality needed for container support, and I don't think anyone tests either the daemon or container images on that operating system version.
I'm trying to set up a remote debugging with LLDB 4.0.1.
There's a docker (17.06.0-ce) container with Arch linux.
Docker container is set in privileged mode, so now LLDB can be started in container.
Container contains core_service which is Rust executable.
Commands run inside container
(lldb) target create target/debug/core_service
Current executable set to 'target/debug/core_service' (x86_64).
(lldb) process launch
Process 182 launched: '/srv/core_service/target/debug/core_service' (x86_64)
Problem exists with remote debugging, lldb-server is started inside container with lldb-server platform --server --listen 0.0.0.0:1234.
I can connect from host lldb to container lldb-server, but I can't attach/create processes.
Commands run on host (lldb-server in container = localhost:1234)
(lldb) platform select remote-linux
Platform: remote-linux
Connected: no
(lldb) platform connect connect://localhost:1234
Platform: remote-linux
Triple: x86_64-*-linux-gnu
OS Version: 4.12.4 (4.12.4-1-ARCH)
Kernel: #1 SMP PREEMPT Fri Jul 28 18:54:18 UTC 2017
Hostname: 099bd76c07c9
Connected: yes
WorkingDir: /srv/core_service
(lldb) target create target/debug/core_service
Current executable set to 'target/debug/core_service' (x86_64).
(lldb) process launch
error: connect remote failed (Connection refused)
error: process launch failed: Connection refused
How can I fix it? Are there any docker, arch linux settings that would cause this error?
It seems, like there's some problem with lldb-server permissions in docker container.
Commands run on host (lldb-server in container)
(lldb) platform shell ps -A
PID TTY TIME CMD
1 ? 00:00:00 bash
9 ? 00:00:00 nginx
10 ? 00:00:00 nginx
11 ? 00:00:00 lldb-server
25 ? 00:00:00 core_service
59 ? 00:00:00 lldb-server
68 ? 00:00:00 ps
(lldb) platform shell kill -9 25
(lldb) platform process launch target/debug/core_service
error: connect remote failed (Connection refused)
error: Connection refused
(lldb) platform process launch anything
error: connect remote failed (Connection refused)
error: Connection refused
But I can't figure out what can it be. lldb-server is run as root in container, I can execute shell commands using lldb.
There is needed both platform port (1234 in your case) and gdbserver port (randomly generated by default). You can enforce the gdbserver port by lldb-server option --gdbserver-port.
Tested on Fedora 29 x86_64:
docker run --privileged -p 5000:5000 -p 5001:5001 fedora bash -c 'dnf -y install lldb;lldb-server platform --server --listen 0.0.0.0:5000 --gdbserver-port 5001'
and
echo 'int main(){}' >main.c;gcc -g -o main main.c;lldb -o 'platform select remote-linux' -o 'platform connect connect://localhost:5000' -o "target create ./main" -o 'b main' -o 'process launch'
(lldb) process launch
Process 45 stopped
* thread #1, name = 'main', stop reason = breakpoint 1.1
frame #0: 0x000000000040110f main`main at main.c:1
-> 1 int main(){}
Process 45 launched: '/root/main' (x86_64)
(lldb) _
This may be because the server cannot see any process on the host. It is still wrapped in its own PID namespace. When you launch the LLDB server, use a host pid name space
docker run --pid=host --privileged <yourimage>
Hopefully this will allow your container see all the host processes
I thought I had rsnapshot all setup properly, but after checking my logs the next day I found the following:
[05/Sep/2014:10:34:11] /usr/bin/rsnapshot daily: ERROR: /usr/bin/rsync returned 12 while processing john#192.168.0.102:/media/linuxstorage/docs/
What does return code "12" mean?
To see what was going on, I ran it manually and went off to do other things:
raspberrypi $ sudo rsnapshot daily
Well lo and hehold, it had been sitting there waiting for my password.
john#192.168.0.102's password:
Connection closed by 192.168.0.102
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(605) [Receiver=3.0.9]
----------------------------------------------------------------------------
rsnapshot encountered an error! The program was invoked with these options:
/usr/bin/rsnapshot daily
----------------------------------------------------------------------------
ERROR: /usr/bin/rsync returned 12 while processing bgrissom#192.168.0.102:/medi/linuxstorage/docs/
I had changed the rsnapshot user from pi to root in /etc/crontab and root was not setup the "ssh without a password" keys for the remote host. All I had to do to fix this is:
raspberrypi $ sudo bash
raspberrypi # ssh-copy-id john#192.168.0.102
The fact: return code "12" means there is something wrong with authentication to remote server.
I ran into this also and seems like this is the most common problem for getting that error:
ERROR: /usr/bin/rsync returned 12 while processing .....
Problem: rsnapshot uses rsync under the hood and can't connect because you probably never actually connected to that remote server.
Solution: You have to connect to that remote server at least once manually through terminal from that machine where rsnapshot is running
with: ssh remote_user#remote_server.domain
so that you confirm the connection and then entry can be made to known_hosts!
After that rsnapshot worked for me.