Ceci est une ancienne révision du document !
Table des matières
Les Processus sous Linux
Voir aussi :
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 http://www.cyberciti.biz/faq/linux-hide-processes-from-other-users/ http://www.linux-dev.org/2012/09/hide-process-information-for-other-users/ http://tuxdiary.com/2014/08/23/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 : https://access.redhat.com/documentation/fr-fr/red_hat_enterprise_linux/9/html/managing_monitoring_and_updating_the_kernel/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 : http://stackoverflow.com/questions/625409/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
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]\+\] //')