Quando você faz:
sudo ./lwdpi -i enp5s0
-
sudo
é o processo pai, em quefork(2)
s é filho, que fazemexecve(2)
com./lwdpi
como o nome do executável -
então
lwdpi
é% de processo filho desudo
Isso resulta em dois processos, como você pode ver, um é sudo
e outro é lwdpi
.
A melhor maneira de ver os detalhes é verificar o PPID (ID do processo pai) também:
ps -eo pid,ppid,args | grep '[l]wdpi'
você verá que o pai de lwdpi
é sudo
em si.
Aqui está o modelo de processo de sudo
, de man sudo
:
When sudo runs a command, it calls fork(2), sets up the execution environment as described above, and calls the execve system call in the child process. The main sudo process waits until the command has completed, then passes the command's exit status to the security policy's close function and exits.
If an I/O logging plugin is configured or if the security policy explicitly requests it, a new pseudo-terminal (“pty”) is created and a second sudo process is used to relay job control signals between the user's existing pty and the new pty the command is being run in. This extra process makes it possible to, for example, suspend and resume the command. Without it, the command would be in what POSIX terms an “orphaned process group” and it would not receive any job control signals.
As a special case, if the policy plugin does not define a close function and no pty is required, sudo will execute the command directly instead of calling fork(2) first. The sudoers policy plugin will only define a close function when I/O logging is enabled, a pty is required, or the pam_session or pam_setcred options are enabled. Note that pam_session and pam_setcred are enabled by default on systems using PAM.