I'm not confident, so I'd appreciate it if you could point out your comments.
I don't know much about the process, so if you open all the files under the process for the time being I thought I could get closer, so I tried it.
I sshed to the server set up by GCP and logged in as root. Check the version of CentOS for the time being.
# cat /etc/redhat-release
CentOS Linux release 7.7.1908 (Core)
Contents of the current / proc directory (-v is a sort option)
# ls /proc/ -v
1   20  98   182  835   2198       diskstats    kpagecount    self
2   21  140  243  852   3082       dma          kpageflags    slabinfo
4   22  142  276  853   3250       driver       loadavg       softirqs
6   23  143  282  854   3254       execdomains  locks         stat
7   24  147  333  949   3389       fb           mdstat        swaps
8   30  171  376  950   3475       filesystems  meminfo       sys
9   31  172  378  951   3494       fs           misc          sysrq-trigger
10  32  173  379  955   acpi       interrupts   modules       sysvipc
11  33  174  384  965   buddyinfo  iomem        mounts        timer_list
13  41  175  398  969   bus        ioports      mtrr          timer_stats
14  42  176  427  970   cgroups    irq          net           tty
15  43  177  431  1160  cmdline    kallsyms     pagetypeinfo  uptime
16  44  178  434  1162  consoles   kcore        partitions    version
17  45  179  435  2128  cpuinfo    keys         schedstat     vmallocinfo
18  47  180  459  2131  crypto     key-users    sched_debug   vmstat
19  60  181  612  2132  devices    kmsg         scsi          zoneinfo
There are many lines. Each number directory seems to contain information about the running process. (For example, the directory "1" contains information about the process with PID 1.) I think that the other directories contain information shared by the entire process. You can check cpu and memory information with cpuinfo and meminfo. I also opened the list of running processes
# ps ax
  PID TTY      STAT   TIME COMMAND
    1 ?        Ss     0:06 /usr/lib/systemd/systemd --switched-root --system --dese
    2 ?        S      0:00 [kthreadd]
    4 ?        S<     0:00 [kworker/0:0H]
    6 ?        S      0:00 [ksoftirqd/0]
    7 ?        S      0:00 [migration/0]
    8 ?        S      0:00 [rcu_bh]
    9 ?        R      0:01 [rcu_sched]
   10 ?        S<     0:00 [lru-add-drain]
   11 ?        S      0:01 [watchdog/0]
   13 ?        S      0:00 [kdevtmpfs]
   14 ?        S<     0:00 [netns]
   15 ?        S      0:00 [khungtaskd]
    ...
There were a few differences, but there were as many processes running as there were process IDs above. That's all for confirmation, but first I would like to add one execution process and check the information of that process.
# sleep 365d > /dev/null &
[1] 3792
The process of waiting 365 days in the background. [Reference] http://www.usupi.org/sysad/024.html Does this make sense to spit out / dev / null? Does sleep 365d & just spit out a log somewhere? Where is it? Aside from that, he replied with 3792, so this time it seems that the process ID was created with 3792. Let's check with the ps command.
# ps aux | grep 3792
root      3792  0.0  0.0 107956   352 pts/0    S    06:28   0:00 sleep 365d
root      3881  0.0  0.1 112712   960 pts/0    S+   06:37   0:00 grep --color=auto 3792
It's running. There are two reasons because the currently searched grep 3792 command also matches.
Now let's take a look at the directory for this process.
ls /proc/3792
# ls /proc/3792
attr             cwd       map_files   oom_adj        schedstat  task
autogroup        environ   maps        oom_score      sessionid  timers
auxv             exe       mem         oom_score_adj  setgroups  uid_map
cgroup           fd        mountinfo   pagemap        smaps      wchan
clear_refs       fdinfo    mounts      patch_state    stack
cmdline          gid_map   mountstats  personality    stat
comm             io        net         projid_map     statm
coredump_filter  limits    ns          root           status
cpuset           loginuid  numa_maps   sched          syscall
Since the volume is large and the articles are likely to be long, I would like to separate the articles into rows.
Also, in the following articles, / proc / 3792 will be the current directory.
#cd /proc/3792
-Read all the contents of proc / [pid] ~ from attr / to cpuset ~ -Read all the contents of proc / [pid] ~ from cwd to loginuid ~ -Read all the contents of proc / [pid] ~ from attr to cpuset ~ -Read all the contents of proc / [pid] ~ from oom_adj to sessionid ~ -Read all the contents of proc / [pid] ~ from setgroups to wchan ~
Recommended Posts