Je ne suis pas confiant, alors je vous serais reconnaissant de bien vouloir faire part de vos commentaires.
Je ne sais pas grand chose sur le processus, donc si vous ouvrez tous les fichiers sous le processus pour le moment J'ai pensé que je pouvais me rapprocher, alors j'ai essayé.
Je me suis connecté au serveur configuré par GCP et je me suis connecté en tant que root. Vérifiez la version de CentOS pour le moment.
# cat /etc/redhat-release
CentOS Linux release 7.7.1908 (Core)
Contenu du répertoire / proc courant (-v est une option de tri)
# 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
Il existe de nombreuses lignes. Chaque répertoire de numéros semble contenir des informations sur le processus en cours. (Par exemple, des informations sur les processus avec PID 1 dans le répertoire "1") Je pense que les autres répertoires contiennent des informations partagées par l'ensemble du processus. Vous pouvez vérifier les informations du processeur et de la mémoire avec cpuinfo et meminfo. J'ai également ouvert la liste des processus en cours
# 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]
...
Il y avait quelques différences, mais il y avait autant de processus en cours d'exécution que d'ID de processus ci-dessus. C'est tout pour confirmation, mais j'aimerais d'abord ajouter un processus d'exécution et vérifier les informations de ce processus.
# sleep 365d > /dev/null &
[1] 3792
Le processus d'attente de 365 jours en arrière-plan. [Référence] http://www.usupi.org/sysad/024.html Est-ce que cela a du sens de cracher dans / dev / null? Sleep 365d et crache-t-il juste un journal quelque part? Où est-ce? En dehors de cela, il a répondu avec 3792, donc cette fois, il semble que l'ID de processus a été créé avec 3792. Vérifions avec la commande ps.
# 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
Il court. Il y a deux raisons parce que la commande grep 3792 actuellement recherchée correspond également.
Jetons maintenant un œil au répertoire de ce processus.
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
Étant donné que le volume est important et que les articles sont probablement longs, je voudrais séparer les articles en lignes.
De plus, dans les articles suivants, / proc / 3792 sera le répertoire courant.
#cd /proc/3792
-Lire tout le contenu de proc / [pid] ~ de attr / à cpuset ~ -Lire tout le contenu de proc / [pid] ~ de cwd à loginuid ~ -Lire tout le contenu de proc / [pid] ~ d'attr à cpuset ~ -Lire tout le contenu de proc / [pid] ~ de oom_adj à sessionid ~ -Lire tout le contenu de proc / [pid] ~ de setgroups à wchan ~
Recommended Posts