Ich bin nicht zuversichtlich, daher würde ich mich freuen, wenn Sie auf Ihre Kommentare hinweisen könnten.
Ich weiß nicht viel über den Prozess. Wenn Sie also vorerst alle Dateien unter dem Prozess öffnen Ich dachte, ich könnte näher kommen, also versuchte ich es.
Ich habe mich an den von GCP eingerichteten Server gewandt und mich als root angemeldet. Überprüfen Sie vorerst die Version von CentOS.
# cat /etc/redhat-release
CentOS Linux release 7.7.1908 (Core)
Inhalt des aktuellen / proc-Verzeichnisses (-v ist eine Sortieroption)
# 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
Es gibt viele Zeilen. Jedes Nummernverzeichnis scheint Informationen über den laufenden Prozess zu enthalten. (Zum Beispiel Informationen zu Prozessen mit PID 1 im Verzeichnis "1") Ich denke, die anderen Verzeichnisse enthalten Informationen, die vom gesamten Prozess gemeinsam genutzt werden. Sie können CPU- und Speicherinformationen mit cpuinfo und meminfo überprüfen. Ich habe auch die Liste der laufenden Prozesse geöffnet
# 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]
...
Es gab einige Unterschiede, aber es wurden so viele Prozesse ausgeführt, wie oben Prozess-IDs angegeben waren. Das ist alles zur Bestätigung, aber zuerst möchte ich einen Ausführungsprozess hinzufügen und die Informationen dieses Prozesses überprüfen.
# sleep 365d > /dev/null &
[1] 3792
Der Prozess des Wartens 365 Tage im Hintergrund. [Referenz] http://www.usupi.org/sysad/024.html Ist es sinnvoll, in / dev / null zu spucken? Schläft 365d & spuckt nur irgendwo ein Protokoll aus? Wo ist es? Abgesehen davon antwortete er mit 3792, so dass diesmal die Prozess-ID mit 3792 erstellt wurde. Lassen Sie uns mit dem Befehl ps überprüfen.
# 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
Es rennt. Es gibt zwei Gründe, weil der aktuell gesuchte Befehl "grep 3792" ebenfalls übereinstimmt. Schauen wir uns nun das Verzeichnis für diesen Prozess an.
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
Da das Volumen groß ist und die Artikel wahrscheinlich lang sind, möchte ich die Artikel in Zeilen unterteilen. In den folgenden Artikeln ist "/ proc / 3792" das aktuelle Verzeichnis.
#cd /proc/3792
-Lesen Sie den gesamten Inhalt von proc / [pid] ~ von attr / bis cpuset ~ -Lesen Sie den gesamten Inhalt von proc / [pid] ~ von cwd bis loginuid ~. -Lesen Sie den gesamten Inhalt von proc / [pid] ~ von attr bis cpuset ~. -Lesen Sie den gesamten Inhalt von proc / [pid] ~ Von oom_adj zu sessionid ~ -Lesen Sie den gesamten Inhalt von proc / [pid] ~ von setgroups bis wchan ~.
Recommended Posts