Les Processus sous Linux

Voir aussi :

Notes atop

process_audit_quand_strace_n_est_pas_la

Linux - Process - nohup ne fonctionne pas

/proc/sys/kernel/ns_last_pid

Tuer tous les processus d'un utilisateur

pkill -u plop

Appels système au noyaux et signaux

strace -p $PID strace -f -e trace=file $CHEMIN_EXE 2>&1 | grep '/home/'

La table des processus

ps -ef | grep $PID # ps -Aww -o pid,ppid,user,start,state,pri,pcpu,time:12,pmem,rsz:10,vsz:10,cmd

2em colone ⇒ PID 3em colone ⇒ PPID

Qui a lancé ce processus ? PPID ? Service ?

journalctl _PID=2636 -o json-pretty

Que fait TTY1 ?

peekfd -cn8 $(ps -t tty1 | grep -v login | sort -nr | head -1 | awk '{print $1}')

ProcFS

Voir egalement /proc/$PID/ Voir man proc ou man procfs

Cacher /proc et la table des processus aux utilusateurs :

Avec Grsecurity Ou en en remontant /proc linux-hide-processes-from-other-users hide-process-information-for-other-users hidepid

Modifier la ligne /proc dans /etc/fstab. Si aucune ligne ne correspond, ajouter la fstab

proc /proc proc defaults,hidepid=2,gid=4 0 0

Pour appliquer la modif sans redemarrer :

mount -o remount /proc/

Audit process

Voir execsnoop et autres : using-selected-bcc-tools-for-performance-analyses_analyzing-system-performance-with-bpf-compiler_collection paquet bcc-tools

Arrière plan

Using the Job Control of bash to send the process into the background:

Ctrl+Z to stop (pause) the program and get back to the shell.

bg to run it in the background.

disown -h [job-spec] where [job-spec] is the job number (like %1 for the first running job; find about your number with the jobs command) so that the job isn't killed when the terminal closes.

Source : how-do-i-put-an-already-running-process-under-nohup

info coreutils 'nohup invocation'

Voir :

nohup $EXE

$EXE &

ctrl + z

bg

fg

pstree

ps

setsid

runit / shpst

trap

# kill -l
18) SIGCONT	19) SIGSTOP

Exemple

Exemple

# jobs
[1]+ Stoppé rsync -azS --partial /data/1/ $FIC root@192.168.205.2:/data/files/1/
[2]- En cours d'exécution rsync -azS --partial /data/2/ $FIC root@192.168.205.2:/data/files/2/ &
jobs %%
jobs %1

Stopper le job1

kill -19 %1

Lancer le job2 une fois le job1 terminé

wait %2; kill -18 %1

http://linuxfr.org/users/srb/journaux/waitend-executer-une-commande-apres-une-autre-deja-lancee

sleep $(( 60 * 3 )) ; echo "Les œufs sont prêt"
sleep $(( 60 * 3 )) && echo "Les œufs sont prêt"
sleep $(( 60 * 3 )) & wait $! echo "Les œufs sont prêt"
sleep $(( 60 * 3 ))

[Ctrl] + [Z]

fg && echo "Les œufs sont prêt"

Autres

Voir atop, htop Voir cgroup

kthreadd

Voir https://www.it-connect.fr/les-processus-sous-linux

# ps -ef | head -40
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 Mar15 ? 00:02:12 /sbin/init
root 2 0 0 Mar15 ? 00:00:00 [kthreadd]
root 3 2 0 Mar15 ? 19:02:47 [migration/0]
root 4 2 0 Mar15 ? 00:07:26 [ksoftirqd/0]
root 5 2 0 Mar15 ? 00:00:00 [stopper/0]
root 6 2 0 Mar15 ? 00:07:33 [watchdog/0]
root 7 2 0 Mar15 ? 18:46:13 [migration/1]
root 8 2 0 Mar15 ? 00:00:00 [stopper/1]
root 9 2 0 Mar15 ? 00:07:05 [ksoftirqd/1]
root 10 2 0 Mar15 ? 00:06:16 [watchdog/1]
root 11 2 0 Mar15 ? 18:55:58 [migration/2]
root 12 2 0 Mar15 ? 00:00:00 [stopper/2]
root 13 2 0 Mar15 ? 00:06:45 [ksoftirqd/2]
root 14 2 0 Mar15 ? 00:06:04 [watchdog/2]
root 15 2 0 Mar15 ? 19:15:39 [migration/3]
root 16 2 0 Mar15 ? 00:00:00 [stopper/3]
root 17 2 0 Mar15 ? 00:06:43 [ksoftirqd/3]
root 18 2 0 Mar15 ? 00:05:41 [watchdog/3]
root 19 2 0 Mar15 ? 18:54:50 [migration/4]
root 20 2 0 Mar15 ? 00:00:00 [stopper/4]
root 21 2 0 Mar15 ? 00:06:48 [ksoftirqd/4]
root 22 2 0 Mar15 ? 00:06:09 [watchdog/4]
root 23 2 0 Mar15 ? 18:51:16 [migration/5]
root 24 2 0 Mar15 ? 00:00:00 [stopper/5]
root 25 2 0 Mar15 ? 00:06:06 [ksoftirqd/5]
root 26 2 0 Mar15 ? 00:05:27 [watchdog/5]
root 27 2 0 Mar15 ? 18:59:33 [migration/6]
root 28 2 0 Mar15 ? 00:00:00 [stopper/6]
root 29 2 0 Mar15 ? 00:06:27 [ksoftirqd/6]
root 30 2 0 Mar15 ? 00:05:13 [watchdog/6]
root 31 2 0 Mar15 ? 19:15:16 [migration/7]
root 32 2 0 Mar15 ? 00:00:00 [stopper/7]
root 33 2 0 Mar15 ? 00:06:16 [ksoftirqd/7]
root 34 2 0 Mar15 ? 00:06:33 [watchdog/7]

Nous pouvons constater immédiatement quatre choses :

Les processus '[migration/n]', contrairement aux processus classiques, on leurs noms entre des crochets []

Le process père est [kthreadd] (PPID 2)

Nous avons 8 processus : migration/0..migration/7. Soit un par core.

Ces processus sont démarrés depuis le démarrage du système d'exploitation soit le 15 mars.

$ LANG=C man ps
"Sometimes the process args will be unavailable; when this happens, ps will instead print the executable name in brackets"

Les zombies

Voir :

https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/

Tuer les zombies !

Source : https://www.linuxjournal.com/content/how-kill-zombie-processes-linux

Also known as “defunct” or “dead” process – In simple words, a Zombie process is one that is dead but is present in the system’s process table. Ideally, it should have been cleaned from the process table once it completed its job/execution but for some reason, its parent process didn’t clean it up properly after the execution.

In a just (Linux) world, a process notifies its parent process once it has completed its execution and has exited. Then the parent process would remove the process from process table. At this step, if the parent process is unable to read the process status from its child (the completed process), it won’t be able to remove the process from memory and thus the process being dead still continues to exist in the process table – hence, called a Zombie!

In order to kill a Zombie process, we need to identify it first. The following command can be used to find zombie processes:

ps aux | egrep "Z|defunct"

Z in the STAT column and/or [defunct] in the last (COMMAND) column of the output would identify a Zombie process.

Now practically you can’t kill a Zombie because it is already dead! What can be done is to notify its parent process explicitly so that it can retry to read the child (dead) process’s status and eventually clean them from the process table. This can be done by sending a SIGCHLD signal to the parent process. The following command can be used to find the parent process ID (PID):

ps -o ppid= <Child PID>

Once you have the Zombie’s parent process ID, you can use the following command to send a SIGCHLD signal to the parent process:

kill -s SIGCHLD <Parent PID>

However, if this does not help clearing out the Zombie process, you will have to kill or restart its parent process OR in case of a huge surge in Zombie processes causing or heading towards system outage, you will have no choice but to go for a system reboot. The following command can be used to kill its parent process:

kill -9 <Parent PID>

Note that killing a parent process will affect all of its child processes, so a quick double check will be helpful to be safe. Alternatively, if few lying zombie processes are not consuming much CPU/Memory, it’s better to kill the parent process or reboot the system in the next scheduled system maintenance.

Strace

Voir : https://aurelien-riv.github.io/php/2019/12/28/what-process-waiting-for.html

Exemple :

strace -e trace=network -f iceweasel http://acme.com 2>&1 | grep '8.8.8.8' strace -ttfv -s128 -o /var/tmp/ping-$(hostname)-$(date +%Y.%m.%d-%H.%M).out ping -c1 acme.com strace -f -p $(pidof mariadbd) --trace=sendto,recvfrom -s 2048 2>&1 | grep -i update vimdiff <(cat plop.log | sed -e 's/^\[pid [0-9]\+\] //') <(cat plop.err | sed -e 's/^\[pid [0-9]\+\] //')