Run container:
[root#localhost ~]# tty
/dev/pts/3
[root#localhost ~]# docker run -it nginx /bin/bash
root#bee12031f933:/# sleep 20
root#bee12031f933:/#
See:
[root#localhost ~]# tty
/dev/pts/2
[root#localhost ~]# w
17:43:24 up 19 days, 45 min, 5 users, load average: 0.00, 0.01, 0.05
USER TTY FROM LOGIN# IDLE JCPU PCPU WHAT
root pts/0 192.168.1.22 16:24 1:01m 0.73s 0.00s sleep 20
root pts/1 192.168.1.22 11:31 1:02m 4.92s 4.65s docker run -it centos:7.7.1908
root pts/2 192.168.1.22 16:31 4.00s 0.70s 0.01s w
root pts/3 192.168.1.22 15:09 4.00s 0.25s 0.07s docker run -it nginx /bin/bash
root pts/4 192.168.1.22 16:41 44.00s 0.06s 0.06s -bash
Example picture:
enter image description here
enter image description here
docker container running in pts/3, execute command in container "sleep 20". then, i execute command "w" on the external host, display command "sleep 20" is executed in pts/0, what's the reason ?
why do external hosts display commands executed in containers ?
docker is similar to how LXC works. It allows sandboxing processes from one another, and controlling their resource allocations.
Since the resources are "separated", the system will show the information based on what it knows.
myuser#localhost: ~ $ tty
/dev/pts/1
myuser#localhost: ~ $ docker run --rm -it ubuntu:18.04 bash
root#36ed505961f4:/# tty
/dev/pts/0
Check the Kernel Namespaces for more info.
Related
I wanted to run an fsck check on my 5TB external hard drive on my raspberry pi.
This is the output:
$ sudo e2fsck -c -v /dev/sda
e2fsck 1.44.5 (15-Dec-2018)
Checking for bad blocks (read-only test): 0.46% done, 5:04 elapsed. (0/0/0 errors)
There has been zero progress for hours now. The elapsed time is stuck as well. This is actually my second attempt. Before I tried sudo e2fsck -p -c -v /dev/sda. This one doesn't give any output, that's why I let it run for a whole week before terminating.
My drive is unmounted, partitionless, and freshly formatted with mkfs.ext4. Output from ps:
$ ps -a
PID TTY TIME CMD
1075 tty1 00:00:00 bash
8404 pts/1 00:00:00 sudo
8405 pts/1 00:00:04 e2fsck
8446 pts/1 00:00:00 sh
8447 pts/1 00:00:05 badblocks
23605 pts/2 00:00:00 ps
I noticed on my first attempt, that it was impossible to send a SIGINT, SIGTERM, or SIGKILL to badblocks.
Why is this?
On my Windows machine, I started a Docker container from docker compose. My entrypoint is a Go filewatcher that runs a task of a taskmanager on every filechange. The executed task builds and runs the Go program.
But before I can build and run the program again after filechanges I have to kill the previous running version. But every time I kill the app process, the container is also gone.
The goal is to kill only the svc1 process with PID 74 in this example. I tried pkill -9 svc1 and kill $(pgrep svc1). But every time the parent processes are killed too.
The commandline output from inside the container:
root#bf073c39e6a2:/app/cmd/svc1# ps -aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 2.5 0.0 104812 2940 ? Ssl 13:38 0:00 /go/bin/watcher
root 13 0.0 0.0 294316 7576 ? Sl 13:38 0:00 /go/bin/task de
root 74 0.0 0.0 219284 4908 ? Sl 13:38 0:00 /svc1
root 82 0.2 0.0 18184 3160 pts/0 Ss 13:38 0:00 /bin/bash
root 87 0.0 0.0 36632 2824 pts/0 R+ 13:38 0:00 ps -aux
root#bf073c39e6a2:/app/cmd/svc1# ps -afx
PID TTY STAT TIME COMMAND
82 pts/0 Ss 0:00 /bin/bash
88 pts/0 R+ 0:00 \_ ps -afx
1 ? Ssl 0:01 /go/bin/watcher -cmd /go/bin/task dev -startcmd
13 ? Sl 0:00 /go/bin/task dev
74 ? Sl 0:00 \_ /svc1
root#bf073c39e6a2:/app/cmd/svc1# pkill -9 svc1
root#bf073c39e6a2:/app/cmd/svc1
Switching to the containerlog:
task: Failed to run task "dev": exit status 255
2019/08/16 14:20:21 exit status 1
"dev" is the name of the task in the taskmanger.
The Dockerfile:
FROM golang:stretch
RUN go get -u -v github.com/radovskyb/watcher/... \
&& go get -u -v github.com/go-task/task/cmd/task
WORKDIR /app
COPY ./Taskfile.yml ./Taskfile.yml
ENTRYPOINT ["/go/bin/watcher", "-cmd", "/go/bin/task dev", "-startcmd"]
I expect only the process with the target PID is killed and not the parent process that spawned it it.
You can use process manager like "supervisord" and configure it to re-execute your script or the command even if you killed it's process which will keep your container up and running.
Say someone runs htop with sudo:
$sudo htop
I know we can get the user name of the htop process by:
$ps aux | grep htop
But in this case it only returns root as the username:
$ps aux | grep htop
root 21186 0.0 0.0 71256 4148 pts/2 S+ 17:16 0:00 sudo htop
root 21187 2.6 0.0 31460 5128 pts/2 S+ 17:16 0:21 htop
How can I find out which user is behind root?
This might work for you. It grabs the commands executed with sudo from /var/log/auth.log:
awk '/sudo/&&/COMMAND/ {
print gensub(/sudo: ([^ ]*).*USER=([^ ]*).*COMMAND=([^ ]*)/,
"\\1 (as \\2) command: \\3", 1)
}' /var/log/auth.log
Simply use grep on /var/log/secure or /var/log/auth.log (depends on the distro):
$ sudo grep sudo /var/log/secure
(or)
$ sudo grep sudo /var/log/auth.log
If these two doesn't work then use sudo journalctl _COMM=sudo
It will give output as:
Apr 14 00:23:35 hell-abhi sudo[14519]: hell_abhi : TTY=pts/1 ; PWD=/home/hell_abhi ; USER=root ; COMMAND=/bin/journalctl _COMM=sudo
Apr 14 00:21:43 hell-abhi sudo[14348]: hell_abhi : TTY=pts/0 ; PWD=/home/hell_abhi ; USER=root ; COMMAND=/bin/nano
The table shows: date, time, user, pid, teminal, directory, command used.
Here you can see: hell_abhi ran sudo nano from /home/hell_abhi(his home directory).
$ jcmd -l
418 sun.tools.jcmd.JCmd -l
$ jstat -gcutil -t 10 250ms 1
10 not found
I am aware of the bug in jdk related to attaching jstat as root to a process running as a different user.
Here, this docker container has one user root and as can be seen below from the ps command, cassandra is running under root.
$ whoami
root
I have tried to do the following:
$ sudo -u root jcmd -l
Any help is appreciated.
Docker container is debian:jessie
running java version:
openjdk version "1.8.0_66-internal"
Here's the output of ps -ef:
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 17:40 ? 00:00:00 /bin/bash /run.sh
root 10 1 11 17:40 ? 00:02:25 java -ea -javaagent:/usr/share/c
root 375 0 0 17:49 ? 00:00:00 bash
root 451 375 0 18:00 ? 00:00:00 ps -ef
Aside: jstack successfully dumps out the stack traces of the threads.
I know at least two possible reasons why this can happen.
Java is run with -XX:+PerfDisableSharedMem option. This option helps sometimes to reduce JVM safepoint pauses, but it also makes JVM invisible to jps and jstat. This is a very likely case, because you are running Cassandra, and recent Cassandra has this option ON by default.
Java process has a different mount namespace, so that /tmp of Java process is not physically the same directory as /tmp of your shell. The directory /tmp/hsperfdata_root must be accessible in order to use jps or jstat. This is also a plausible reason since you are using docker containers.
My webapp allows users to execute some arbitrary code in a sandbox. To prevent forkbombs, the application calls setrlimit and limits RLIMIT_NPROC to 50 before executing user code. This worked great in Ubuntu 12.04 up till Ubuntu 13.04. However, after upgrading to Ubuntu 13.10 (which ships with Apache 2.4 and Linux 3.11), we hit the limit of 50 www-data processes, even when Apache2 is idle!
The problem is most easily reproduced by running bash as user www-data with ulimit. First switch into user www-data and start bash:
jeroen#Ubuntu:/$ sudo su www-data
$ bash
www-data#Ubuntu:/$
Now gradually lower RLIMIT_NPROC until we hit problems:
#RLIMIT_NPROC=100: works fine
www-data#Ubuntu:/$ ulimit -u 100
www-data#Ubuntu:/$ ls
bin dev initrd.img lib64 mnt root srv usr vmlinuz.old
boot etc initrd.img.old lost+found opt run sys var
cdrom home lib media proc sbin tmp vmlinuz
#RLIMIT_NPROC=50: limit reached
www-data#Ubuntu:/$ ulimit -u 50
www-data#Ubuntu:/$ ls
bash: fork: retry: No child processes
bash: fork: retry: No child processes
bash: fork: Resource temporarily unavailable
Hence after setting RLIMIT_NPROC to 50, the process can no longer fork. This implies that there are already 50 or more processes running as user www-data. However, this does not seem to be the case, the server is just a blank idle Apache 2.4. According to ps, there are currently only 2 procs owned by www-data:
jeroen#Ubuntu:~$ ps aux | grep www-data
www-data 11473 0.0 0.5 631296 46164 ? Sl 14:28 0:01 /usr/sbin/apache2 -k start
www-data 11474 0.0 0.5 565656 45632 ? Sl 14:28 0:01 /usr/sbin/apache2 -k start
jeroen 12136 0.0 0.0 13644 956 pts/4 S+ 14:51 0:00 grep --color=auto www-data
So why is www-data is hitting the RLIMIT_NPROC limit of 50 in Apache 2.4, even when idle?
Found the problem thanks to the suggestion from #sarnold. My Application depends on mpm_prefork and up till Ubuntu 13.04, this module was automatically enabled when the apache2-mpm-prefork package is installed. I assumed this was still the case, but it turned out that it was running mpm_event.
It seems that in Apache 2.4 the packaging of MPM's has changed and mpm_prefork needs to be enabled manually after installation:
sudo a2dismod mpm_event
sudo a2enmod mpm_prefork
sudo service apache2 restart
Now the problems seem to have disappeared.