I was going through logged in user in to my system using who command what i found is very surprising a user named unknown is logged in
Result of command who :
myuser pts/1 Aug 6 20:27 (localhost)
(unknown) :0 Aug 5 16:25 (:0)
myuser pts/0 Aug 6 00:48 (localhost.localdomain)
But when i tried running w it results different:
20:46:53 up 1 day, 23:11, 3 users, load average: 1.00, 1.01, 1.05
USER TTY FROM LOGIN# IDLE JCPU PCPU WHAT
myuser pts/1 localhost 20:27 5.00s 0.20s 0.03s w
myuser pts/0 localhost.locald 00:48 19:57m 0.08s 1.71s python2 -m guake.main
I am neither able to find any user on my machine named unknown. On trying sudo su unknown/"(unknown)"
I tried running last it shows unknown user still logged in
myuser pts/1 localhost Thu Aug 6 20:27 still logged in
myuser pts/2 :pts/1:S.0 Thu Aug 6 20:15 - 20:16 (00:00)
myuser pts/1 localhost Thu Aug 6 20:03 - 20:18 (00:15)
myuser pts/2 :pts/1:S.0 Thu Aug 6 19:49 - 19:49 (00:00)
myuser pts/1 localhost Thu Aug 6 19:47 - 19:49 (00:02)
myuser pts/1 localhost Thu Aug 6 19:37 - 19:46 (00:09)
myuser pts/1 localhost Thu Aug 6 19:33 - 19:37 (00:03)
myuser pts/1 :9 Thu Aug 6 19:32 - 19:33 (00:00)
myuser pts/1 localhost Thu Aug 6 19:26 - 19:32 (00:05)
myuser pts/2 :pts/1:S.0 Thu Aug 6 19:22 - 19:22 (00:00)
myuser pts/1 localhost Thu Aug 6 19:22 - 19:22 (00:00)
myuser pts/2 :pts/1:S.0 Thu Aug 6 19:15 - 19:16 (00:00)
myuser pts/1 localhost Thu Aug 6 19:15 - 19:16 (00:00)
myuser pts/2 :pts/1:S.0 Thu Aug 6 19:13 - 19:13 (00:00)
myuser pts/1 localhost Thu Aug 6 19:13 - 19:13 (00:00)
myuser pts/2 :pts/1:S.0 Thu Aug 6 19:12 - 19:13 (00:00)
myuser pts/2 :pts/1:S.0 Thu Aug 6 19:11 - 19:11 (00:00)
myuser pts/2 :pts/1:S.0 Thu Aug 6 19:10 - 19:10 (00:00)
myuser pts/1 localhost Thu Aug 6 18:37 - 19:13 (00:35)
myuser pts/1 localhost Thu Aug 6 18:17 - 18:21 (00:03)
myuser pts/1 localhost Thu Aug 6 18:09 - 18:13 (00:03)
myuser pts/0 localhost.locald Thu Aug 6 00:48 still logged in
myuser pts/0 localhost.locald Thu Aug 6 00:34 - 00:48 (00:14)
myuser pts/1 :9 Wed Aug 5 23:01 - 23:01 (00:00)
myuser pts/0 localhost.locald Wed Aug 5 22:00 - 00:34 (02:34)
myuser pts/0 localhost Wed Aug 5 21:06 - 21:06 (00:00)
myuser pts/0 localhost Wed Aug 5 20:57 - 20:59 (00:01)
myuser pts/0 localhost Wed Aug 5 20:56 - 20:56 (00:00)
myuser pts/0 localhost Wed Aug 5 20:56 - 20:56 (00:00)
myuser pts/0 :9 Wed Aug 5 20:55 - 20:56 (00:00)
myuser pts/4 localhost Wed Aug 5 20:14 - 20:55 (00:40)
myuser pts/4 localhost Wed Aug 5 20:11 - 20:12 (00:00)
myuser pts/5 localhost Wed Aug 5 19:52 - 19:56 (00:04)
myuser pts/4 localhost Wed Aug 5 19:29 - 19:31 (00:02)
myuser pts/2 localhost Wed Aug 5 18:42 - 19:32 (00:49)
myuser pts/2 localhost Wed Aug 5 18:42 - 18:42 (00:00)
myuser pts/3 :9 Wed Aug 5 18:38 - 18:42 (00:04)
myuser pts/3 localhost Wed Aug 5 16:28 - 16:28 (00:00)
myuser pts/2 :9 Wed Aug 5 16:26 - 16:28 (00:02)
(unknown :0 :0 Wed Aug 5 16:25 still logged in
Any idea how ?
I faced a similar problem some time ago on a Fedora host.
In my case, i found it was the X system that created a wrong entry in /var/run/utmp.
Here the link to the page.
Maybe you are not using Fedora but I suggest to try disable X and check if you still have an (unknown) user logged in.
Hope this helps.
I saw this appearing in a Fedora installation in the past, when I launched the X from a tty (not in init 5)
In red hat, there is a bug open related to this problem here (but maybe you are not even running a red hat based distro)
Take a look on it, there are some possible explanations, but depends on what you are running in your box
Related
I have a container which was restart 14 hours ago. The container is running since 7 weeks. I want to inspect the container logs during a certain interval. When i run below command, I see there is no output
docker container logs pg-connect --until 168h --since 288h
When i run below commands i only see logs since the container was restarted.
docker logs pg-connect
Any idea how to retrieve older logs for the container?
More info if helps
> docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
9f08fb6fb0fb kosta709/alpine-plus:0.0.2 "/connectors-restart…" 7 weeks ago Up 14 hours connectors-monitor
7e919a253a29 debezium/connect:1.2.3.Final "/docker-entrypoint.…" 7 weeks ago Up 14 hours pg-connect
>
>
> docker logs 7e919a253a29 -n 2
2022-08-26 06:37:10,878 INFO || WorkerSourceTask{id=relations-0} Committing offsets [org.apache.kafka.connect.runtime.WorkerSourceTask]
2022-08-26 06:37:10,878 INFO || WorkerSourceTask{id=relations-0} flushing 0 outstanding messages for offset commit [org.apache.kafka.connect.runtime.WorkerSourceTask]
> docker logs 7e919a253a29 |head
org.apache.kafka.common.KafkaException: Producer is closed forcefully.
at org.apache.kafka.clients.producer.internals.RecordAccumulator.abortBatches(RecordAccumulator.java:766)
at org.apache.kafka.clients.producer.internals.RecordAccumulator.abortIncompleteBatches(RecordAccumulator.java:753)
at org.apache.kafka.clients.producer.internals.Sender.run(Sender.java:279)
at java.base/java.lang.Thread.run(Thread.java:834)
2022-08-24 16:13:06,567 ERROR || WorkerSourceTask{id=session-0} failed to send record to barclays.public.session: [org.apache.kafka.connect.runtime.WorkerSourceTask]
org.apache.kafka.common.KafkaException: Producer is closed forcefully.
at org.apache.kafka.clients.producer.internals.RecordAccumulator.abortBatches(RecordAccumulator.java:766)
at org.apache.kafka.clients.producer.internals.RecordAccumulator.abortIncompleteBatches(RecordAccumulator.java:753)
at org.apache.kafka.clients.producer.internals.Sender.run(Sender.java:279)
>
> ls -lart /var/lib/docker/containers/7e919a253a296494b74361e258e49d8c3ff38f345455316a15e1cb28cf556fa1/
total 90720
drwx------ 2 root root 6 Jul 1 10:39 checkpoints
drwx--x--- 2 root root 6 Jul 1 10:39 mounts
drwx--x--- 4 root root 150 Jul 1 10:40 ..
-rw-r----- 1 root root 10000230 Aug 24 16:13 7e919a253a296494b74361e258e49d8c3ff38f345455316a15e1cb28cf556fa1-json.log.9
-rw-r----- 1 root root 10000163 Aug 24 16:13 7e919a253a296494b74361e258e49d8c3ff38f345455316a15e1cb28cf556fa1-json.log.8
-rw-r----- 1 root root 10000054 Aug 24 16:16 7e919a253a296494b74361e258e49d8c3ff38f345455316a15e1cb28cf556fa1-json.log.7
-rw-r----- 1 root root 10000147 Aug 24 16:42 7e919a253a296494b74361e258e49d8c3ff38f345455316a15e1cb28cf556fa1-json.log.6
-rw-r----- 1 root root 10000123 Aug 24 16:42 7e919a253a296494b74361e258e49d8c3ff38f345455316a15e1cb28cf556fa1-json.log.5
-rw-r----- 1 root root 10000019 Aug 24 16:42 7e919a253a296494b74361e258e49d8c3ff38f345455316a15e1cb28cf556fa1-json.log.4
-rw-r----- 1 root root 10000159 Aug 24 16:42 7e919a253a296494b74361e258e49d8c3ff38f345455316a15e1cb28cf556fa1-json.log.3
-rw-r----- 1 root root 10000045 Aug 24 16:42 7e919a253a296494b74361e258e49d8c3ff38f345455316a15e1cb28cf556fa1-json.log.2
-rw-r--r-- 1 root root 199 Aug 25 16:30 hosts
-rw-r--r-- 1 root root 68 Aug 25 16:30 resolv.conf
-rw-r--r-- 1 root root 25 Aug 25 16:30 hostname
-rw------- 1 root root 7205 Aug 25 16:30 config.v2.json
-rw-r--r-- 1 root root 1559 Aug 25 16:30 hostconfig.json
-rw-r----- 1 root root 10000085 Aug 25 16:31 7e919a253a296494b74361e258e49d8c3ff38f345455316a15e1cb28cf556fa1-json.log.1
drwx--x--- 4 root root 4096 Aug 25 16:31 .
-rw-r----- 1 root root 2843232 Aug 26 06:38 7e919a253a296494b74361e258e49d8c3ff38f345455316a15e1cb28cf556fa1-json.log
As stated by [the official guide][1]:
The docker logs command batch-retrieves logs present at the time of execution.```
To solve this issue you should instrument the container software to log its output to a persistent (rotated if you want) log file.
[1]: https://docs.docker.com/engine/reference/commandline/logs/
I'm creating a PostgreSQL database with Docker Compose on Debian 11.
Docker version 20.10.14, build a224086
Docker Compose version v2.3.3
When I try to shutdown Docker Compose and remove all existing data, I cannot seem to get rid of bind mounted data.
docker-compose.yml
version: '3'
services:
postgres:
image: postgres:9.3.25
healthcheck:
test: [ "CMD", "pg_isready", "-q", "-d", "postgres", "-U", "root" ]
timeout: 45s
interval: 10s
retries: 10
restart: always
environment:
- POSTGRES_USER=root
- POSTGRES_PASSWORD=docker
- APP_DB_USER=app_user
- APP_DB_PASS=docker
- APP_DB_NAME=myapp_db
# Notice this creates bind mounts, not volumes!
volumes:
- ./db-entry-point:/docker-entrypoint-initdb.d/
- ./postgres-db-data:/var/lib/postgresql/data
ports:
- 5432:5432
The command below is issued to shutdown docker containers. I know it doesn't remove volumes by default. --volumes argument could be used for removing volumes, but I tested that it doesn't remove bind mound data.
docker compose -f /opt/storage/disk-03/docker/myapp-db/docker-compose.yml down
These files are on the bind mount target directory:
ls -la /opt/storage/disk-03/docker/myapp-db/postgres-db-data/
total 44
drwx------ 15 systemd-timesync root 329 Mar 29 09:52 .
drwxr-xr-x 4 root root 78 Mar 29 09:35 ..
-rw------- 1 systemd-timesync systemd-timesync 4 Mar 28 14:52 PG_VERSION
drwx------ 7 systemd-timesync systemd-timesync 67 Mar 28 14:52 base
drwx------ 2 systemd-timesync systemd-timesync 4096 Mar 29 09:51 global
drwx------ 2 systemd-timesync systemd-timesync 18 Mar 28 14:52 pg_clog
-rw------- 1 systemd-timesync systemd-timesync 4486 Mar 28 14:52 pg_hba.conf
-rw------- 1 systemd-timesync systemd-timesync 1636 Mar 28 14:52 pg_ident.conf
drwx------ 4 systemd-timesync systemd-timesync 36 Mar 28 14:52 pg_multixact
drwx------ 2 systemd-timesync systemd-timesync 18 Mar 29 09:50 pg_notify
drwx------ 2 systemd-timesync systemd-timesync 6 Mar 28 14:52 pg_serial
drwx------ 2 systemd-timesync systemd-timesync 6 Mar 28 14:52 pg_snapshots
drwx------ 2 systemd-timesync systemd-timesync 105 Mar 29 09:52 pg_stat
drwx------ 2 systemd-timesync systemd-timesync 6 Mar 29 09:52 pg_stat_tmp
drwx------ 2 systemd-timesync systemd-timesync 18 Mar 28 14:52 pg_subtrans
drwx------ 2 systemd-timesync systemd-timesync 6 Mar 28 14:52 pg_tblspc
drwx------ 2 systemd-timesync systemd-timesync 6 Mar 28 14:52 pg_twophase
drwx------ 3 systemd-timesync systemd-timesync 60 Mar 28 14:52 pg_xlog
-rw------- 1 systemd-timesync systemd-timesync 20120 Mar 28 14:52 postgresql.conf
-rw------- 1 systemd-timesync systemd-timesync 37 Mar 29 09:50 postmaster.opts
I'm not sure how to delete these files as rm -rf doesn't remove them. ls -la /opt/storage/disk-03/docker/myapp-db/postgres-db-data/ still lists the files.
sudo rm -rf /opt/storage/disk-03/docker/myapp-db/postgres-db-data/*
What would be the right way from Docker's perspective to remove these files?
Seems that the files can be removed by changing the owner of the files first and then removing. I'm not sure what's going on in the underlying OS, but I tested this couple times and it works.
# This doesn't remove the files when files are owned by "systemd-timesync"
sudo rm -rf /opt/storage/disk-03/docker/myapp-db/postgres-db-data/*
# chown to admin user
sudo chown -R admin. /opt/storage/disk-03/docker/myapp-db/postgres-db-data/
# Now removal works
sudo rm -rf /opt/storage/disk-03/docker/myapp-db/postgres-db-data/*
I am trying to figure out why I cannot start and stop the amazon-ssm-agent service manually in a Kali Linux Focker image running on an Ubuntu 20.04.1 LTS host. Per their instructions, I have obtained the .deb file and installed it with dpkg -i. Although I can interact with it via amazon-ssm-agent -h and registering it just fine, etc., I cannot restart the service which sometimes fixes the Connection Lost issue after registering.
As you can see below, I am using wget to get the .deb file, and installing it:
➜ ~ wget https://s3.us-east-1.amazonaws.com/amazon-ssm-us-east-1/latest/debian_amd64/amazon-ssm-agent.deb
--2020-12-27 22:21:32-- https://s3.us-east-1.amazonaws.com/amazon-ssm-us-east-1/latest/debian_amd64/amazon-ssm-agent.deb
Resolving s3.us-east-1.amazonaws.com (s3.us-east-1.amazonaws.com)... 52.217.109.126
Connecting to s3.us-east-1.amazonaws.com (s3.us-east-1.amazonaws.com)|52.217.109.126|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 41537900 (40M) [binary/octet-stream]
Saving to: 'amazon-ssm-agent.deb'
amazon-ssm-agent.deb 100%[========================================================================================================================================================================================================================================>] 39.61M 105MB/s in 0.4s
2020-12-27 22:21:33 (105 MB/s) - 'amazon-ssm-agent.deb' saved [41537900/41537900]
➜ ~ dpkg -i amazon-ssm-agent.deb
Selecting previously unselected package amazon-ssm-agent.
(Reading database ... 231292 files and directories currently installed.)
Preparing to unpack amazon-ssm-agent.deb ...
Preparing for install
Unpacking amazon-ssm-agent (3.0.431.0-1) ...
Setting up amazon-ssm-agent (3.0.431.0-1) ...
Starting agent
➜ ~ service amazon-ssm-agent status
amazon-ssm-agent: unrecognized service
➜ ~
I also cannot use systemctl because of the following error:
➜ ~ systemctl status amazon-ssm-agent
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
➜ ~
I tried looking in /etc/init.d as well, but no luck:
➜ ~ ls /etc/init.d -l
total 240
-rwxr-xr-x 1 root root 2489 Aug 8 07:47 apache-htcacheclean
-rwxr-xr-x 1 root root 8181 Aug 8 07:47 apache2
-rwxr-xr-x 1 root root 1614 Jul 14 2019 atftpd
-rwxr-xr-x 1 root root 2401 May 26 2020 avahi-daemon
-rwxr-xr-x 1 root root 1175 Apr 17 2020 binfmt-support
-rwxr-xr-x 1 root root 2948 Sep 16 07:49 bluetooth
-rwxr-xr-x 1 root root 1232 Dec 1 01:02 console-setup.sh
-rwxr-xr-x 1 root root 937 Sep 3 22:30 cryptdisks
-rwxr-xr-x 1 root root 896 Sep 3 22:30 cryptdisks-early
-rwxr-xr-x 1 root root 3152 Jul 2 13:19 dbus
-rwxr-xr-x 1 root root 1408 Aug 4 23:00 dns2tcp
-rwxr-xr-x 1 root root 7159 May 23 2020 exim4
-rwxr-xr-x 1 root root 3708 Nov 25 21:07 hwclock.sh
-rwxr-xr-x 1 root root 3615 Sep 5 2019 inetsim
-rwxr-xr-x 1 root root 4113 Sep 26 16:48 iodined
-rwxr-xr-x 1 root root 1479 Oct 9 2016 keyboard-setup.sh
-rwxr-xr-x 1 root root 2044 Apr 18 2020 kmod
-rwxr-xr-x 1 root root 5966 Nov 22 15:42 mariadb
-rwxr-xr-x 1 root root 2882 Jul 26 2019 miredo
-rwxr-xr-x 1 root root 4486 Sep 21 14:45 networking
-rwxr-xr-x 1 root root 5658 Jul 26 12:02 nfs-common
-rwxr-xr-x 1 root root 4579 May 28 2020 nginx
-rwxr-xr-x 1 root root 1934 Jul 7 05:55 nmbd
-rwxr-xr-x 1 root root 1494 Sep 23 11:46 ntp
-rwxr-xr-x 1 root root 9138 Oct 28 18:37 openvpn
-rwxr-xr-x 1 root root 3720 Jun 14 2020 pcscd
-rwxr-xr-x 1 root root 1490 Nov 15 2019 postgresql
-rwxr-xr-x 1 root root 924 May 16 2020 procps
-rwxr-xr-x 1 root root 3699 Jul 22 2017 ptunnel
-rwxr-xr-x 1 root root 3836 Jan 2 2017 redsocks
-rwxr-xr-x 1 root root 1615 Aug 19 2018 rlinetd
-rwxr-xr-x 1 root root 2507 Jul 13 01:22 rpcbind
-rwxr-xr-x 1 root root 4417 Aug 26 20:23 rsync
-rwxr-xr-x 1 root root 2864 Oct 20 19:45 rsyslog
-rwxr-xr-x 1 root root 1661 Jun 5 2013 rwhod
-rwxr-xr-x 1 root root 2259 Jul 7 05:55 samba-ad-dc
-rwxr-xr-x 1 root root 1222 Apr 2 2017 screen-cleanup
-rwxr-xr-x 1 root root 3088 Oct 10 2019 smartmontools
-rwxr-xr-x 1 root root 2061 Jul 7 05:55 smbd
-rwxr-xr-x 1 root root 1175 Sep 24 23:10 snmpd
-rwxr-xr-x 1 root root 4056 Dec 2 10:32 ssh
-rwxr-xr-x 1 root root 4440 Sep 5 2019 sslh
-rwxr-xr-x 1 root root 5730 Sep 13 10:43 stunnel4
-rwxr-xr-x 1 root root 1030 Dec 2 03:10 sudo
-rwxr-xr-x 1 root root 1581 Dec 16 08:36 sysstat
-rwxr-xr-x 1 root root 6871 Dec 3 22:53 udev
-rwxr-xr-x 1 root root 2757 Oct 9 08:13 x11-common
➜ ~
However, you can see that running the amazon-ssm-agent command works just fine:
➜ ~ amazon-ssm-agent
Error occurred fetching the seelog config file path: open /etc/amazon/ssm/seelog.xml: no such file or directory
Initializing new seelog logger
New Seelog Logger Creation Complete
2020-12-27 22:24:08 ERROR error fetching the instanceID, Failed to fetch instance ID. Data from vault is empty. EC2MetadataError: failed to make EC2Metadata request
status code: 404, request id:
caused by: not found
2020-12-27 22:24:08 ERROR error occurred when starting amazon-ssm-agent: error fetching the instanceID, Failed to fetch instance ID. Data from vault is empty. EC2MetadataError: failed to make EC2Metadata request
status code: 404, request id:
caused by: not found
➜ ~
The only reason that I need to restart the service after registering is because sometimes I get a "Connection Lost" on the managed instance's ping status after registering. Usually restarting the service seem to do the trick for me.
I'm able to restart the service successfully when just using the host (Ubuntu 20.04) and even when the host is running Kali Linux as well, but not when it's a docker container, which doesn't make any sense to me because everything is functional with the exception of being able to start/stop the service manually.
I was able to get this running by cloning this repository: https://github.com/gdraheim/docker-systemctl-replacement
After cloning, I ran the following:
/root/docker-systemctl-replacement/files/docker/systemctl.py restart amazon-ssm-agent
I'm using kubeadm 1.15.3, docker-ce 18.09 on Debian 10 buster 5.2.9-2, and seeing errors in journalctl -xe | grep kubelet:
server.go:273] failed to run Kubelet: mountpoint for cpu not found
My /sys/fs/cgroup contains:
-r--r--r-- 1 root root 0 Sep 2 18:49 cgroup.controllers
-rw-r--r-- 1 root root 0 Sep 2 18:50 cgroup.max.depth
-rw-r--r-- 1 root root 0 Sep 2 18:50 cgroup.max.descendants
-rw-r--r-- 1 root root 0 Sep 2 18:49 cgroup.procs
-r--r--r-- 1 root root 0 Sep 2 18:50 cgroup.stat
-rw-r--r-- 1 root root 0 Sep 2 18:49 cgroup.subtree_control
-rw-r--r-- 1 root root 0 Sep 2 18:50 cgroup.threads
-rw-r--r-- 1 root root 0 Sep 2 18:50 cpu.pressure
-r--r--r-- 1 root root 0 Sep 2 18:50 cpuset.cpus.effective
-r--r--r-- 1 root root 0 Sep 2 18:50 cpuset.mems.effective
drwxr-xr-x 2 root root 0 Sep 2 18:49 init.scope
-rw-r--r-- 1 root root 0 Sep 2 18:50 io.pressure
-rw-r--r-- 1 root root 0 Sep 2 18:50 memory.pressure
drwxr-xr-x 20 root root 0 Sep 2 18:49 system.slice
drwxr-xr-x 2 root root 0 Sep 2 18:49 user.slice
docker.service is running okay and has /etc/docker/daemon.json:
{
"exec-opts": [
"native.cgroupdriver=systemd"
],
"log-driver": "json-file",
"log-opts": {
"max-size": "100m"
},
"storage-driver": "overlay2"
}
The kubeadm docs say if using docker the cgroup driver will be autodetected, but I tried supplying it anyway for good measure - no change.
With mount or cgroupfs-mount:
$ mount -t cgroup -o all cgroup /sys/fs/cgroup
mount: /sys/fs/cgroup: cgroup already mounted on /sys/fs/cgroup/cpuset.
$ cgroupfs-mount
mount: /sys/fs/cgroup/cpu: cgroup already mounted on /sys/fs/cgroup/cpuset.
mount: /sys/fs/cgroup/blkio: cgroup already mounted on /sys/fs/cgroup/cpuset.
mount: /sys/fs/cgroup/memory: cgroup already mounted on /sys/fs/cgroup/cpuset.
mount: /sys/fs/cgroup/pids: cgroup already mounted on /sys/fs/cgroup/cpuset.
Is the problem that it's at cpuset rather than cpu? I tried to create a symlink, but root does not have write permission for /sys/fs/cgroup. (Presumably I can change it, but I took that as enough warning not to meddle.)
How can let kubelet find my CPU cgroup mount?
I would say that something very weird with your docker-ce installation and not kubelet. You are looking into the right direction showing mapping problem.
I have tried 3 different docker versions on both GCP and AWS environments instances.
What I have noticed comparing our results - you have wrong folder structure under /sys/fs/cgroup. Pay attention that I have much more permissions in /sys/fs/cgroup comparing to your output. This is how my results looks like:
root#instance-3:~# docker version
Client: Docker Engine - Community
Version: 19.03.1
API version: 1.39 (downgraded from 1.40)
Go version: go1.12.5
Git commit: 74b1e89
Built: Thu Jul 25 21:21:24 2019
OS/Arch: linux/amd64
Experimental: false
Server: Docker Engine - Community
Engine:
Version: 18.09.1
API version: 1.39 (minimum version 1.12)
Go version: go1.10.6
Git commit: 4c52b90
Built: Wed Jan 9 19:02:44 2019
OS/Arch: linux/amd64
Experimental: false
root#instance-3:~# ls -la /sys/fs/cgroup
total 0
drwxr-xr-x 14 root root 360 Sep 3 11:30 .
drwxr-xr-x 6 root root 0 Sep 3 11:30 ..
dr-xr-xr-x 5 root root 0 Sep 3 11:30 blkio
lrwxrwxrwx 1 root root 11 Sep 3 11:30 cpu -> cpu,cpuacct
dr-xr-xr-x 5 root root 0 Sep 3 11:30 cpu,cpuacct
lrwxrwxrwx 1 root root 11 Sep 3 11:30 cpuacct -> cpu,cpuacct
dr-xr-xr-x 2 root root 0 Sep 3 11:30 cpuset
dr-xr-xr-x 5 root root 0 Sep 3 11:30 devices
dr-xr-xr-x 2 root root 0 Sep 3 11:30 freezer
dr-xr-xr-x 5 root root 0 Sep 3 11:30 memory
lrwxrwxrwx 1 root root 16 Sep 3 11:30 net_cls -> net_cls,net_prio
dr-xr-xr-x 2 root root 0 Sep 3 11:30 net_cls,net_prio
lrwxrwxrwx 1 root root 16 Sep 3 11:30 net_prio -> net_cls,net_prio
dr-xr-xr-x 2 root root 0 Sep 3 11:30 perf_event
dr-xr-xr-x 5 root root 0 Sep 3 11:30 pids
dr-xr-xr-x 2 root root 0 Sep 3 11:30 rdma
dr-xr-xr-x 5 root root 0 Sep 3 11:30 systemd
dr-xr-xr-x 5 root root 0 Sep 3 11:30 unified
root#instance-3:~# ls -la /sys/fs/cgroup/unified/
total 0
dr-xr-xr-x 5 root root 0 Sep 3 11:37 .
drwxr-xr-x 14 root root 360 Sep 3 11:30 ..
-r--r--r-- 1 root root 0 Sep 3 11:42 cgroup.controllers
-rw-r--r-- 1 root root 0 Sep 3 11:42 cgroup.max.depth
-rw-r--r-- 1 root root 0 Sep 3 11:42 cgroup.max.descendants
-rw-r--r-- 1 root root 0 Sep 3 11:30 cgroup.procs
-r--r--r-- 1 root root 0 Sep 3 11:42 cgroup.stat
-rw-r--r-- 1 root root 0 Sep 3 11:42 cgroup.subtree_control
-rw-r--r-- 1 root root 0 Sep 3 11:42 cgroup.threads
drwxr-xr-x 2 root root 0 Sep 3 11:30 init.scope
drwxr-xr-x 52 root root 0 Sep 3 11:30 system.slice
drwxr-xr-x 3 root root 0 Sep 3 11:30 user.slice
Encourage you completely reinstall docker from scratch(or recreate instance and install docker again). That should help.
Let me share with you my docker-ce installation steps:
$ sudo apt update
$ sudo apt install apt-transport-https ca-certificates curl gnupg2 software-properties-common
$ curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key add -
$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable"
$ sudo apt update
$ apt-cache policy docker-ce
$ sudo apt install docker-ce=5:18.09.1~3-0~debian-buster
I have also seen a workaroung in Kubelet: mountpoint for cpu not found issue answer, but also dont have a permission under root to fix it:
mkdir /sys/fs/cgroup/cpu,cpuacct
mount -t cgroup -o cpu,cpuacct none /sys/fs/cgroup/cpu,cpuacct
I am running Visual Studio Code Version 1.19.3 on Linux Mint 18.3. When I try to execute binaries that I can clearly see and run in my external terminal, they cannot be found. When I 'ls' /usr/bin from the integrated terminal, many files are missing and others are different versions.
External bash /usr/bin ls snippet:
-rwxr-xr-x 1 root root 10392 Jan 30 2016 pgmtolispm
-rwxr-xr-x 1 root root 17048 Jan 30 2016 pgmtopbm
-rwxr-xr-x 1 root root 10392 Jan 30 2016 pgmtoppm
-rwxr-xr-x 1 root root 27280 Nov 21 2016 pgrep
lrwxrwxrwx 1 root root 22 Jan 15 21:29 phar -> /etc/alternatives/phar
lrwxrwxrwx 1 root root 12 Aug 9 10:43 phar7.0 -> phar.phar7.0
lrwxrwxrwx 1 root root 27 Jan 15 21:29 phar.phar -> /etc/alternatives/phar.phar
-rwxr-xr-x 1 root root 14826 Aug 9 10:42 phar.phar7.0
lrwxrwxrwx 1 root root 21 Jan 15 21:29 php -> /etc/alternatives/php
-rwxr-xr-x 1 root root 4430896 Aug 9 10:43 php7.0
-rwxr-xr-x 1 root root 6264 Jan 30 2016 pi1toppm
-rwxr-xr-x 1 root root 10384 Jan 30 2016 pi3topbm
-rwxr-xr-x 1 root root 200736 Jan 29 2016 pic
Integrated terminal /usr/bin ls snippet:
-rwxr-xr-x 3 nfsnobody nfsnobody 45393 Dec 31 1969 perlthanks
-rwxr-xr-x 2 nfsnobody nfsnobody 14408 Dec 31 1969 pfbtops
-rwxr-xr-x 2 nfsnobody nfsnobody 38896 Dec 31 1969 pg
-rwxr-xr-x 3 nfsnobody nfsnobody 26680 Dec 31 1969 pgrep
-rwxr-xr-x 2 nfsnobody nfsnobody 200696 Dec 31 1969 pic
Is VSC creating some kind of virtual filesystem for the terminal that has its own /usr/bin, but still attaches my working folder in the right path? I am lost and it is preventing me from being able to use the Google debugger and PHP Intellisense, just to name a couple of things.