No meu exemplo, o wcprograma está tentando abrir o FIFO de teste ou pipe nomeado.
Essas syscalls em andamento openparecem não ser mostradas por fuserou lsof:
mknod /tmp/testpipe p
wc /tmp/testpipe &
timeout 0.2 strace -p $! |& timeout 0.1 cat; echo
strace: Process 10103 attached
open("/tmp/testpipe", O_RDONLY
fuser /tmp/testpipe # no output
lsof | grep testpipe # no output
Como encontrar processos tentando abrir algum FIFO em sistemas Linux?
Um thread ou processo bifurcado do Linux pode alterar seu nome e/ou sua linha de comando conforme visível por psou no /procsistema de arquivos.
Ao utilizar o python-setproctitlepacote, a mesma alteração ocorre em /proc/pid/cmdline, /proc/pid/comm, na Name:linha de /proc/pid/statuse no segundo campo de /proc/pid/stat, onde apenas cmdlineestá mostrando o comprimento completo e os outros três locais estão mostrando os primeiros 15 caracteres do nome alterado.
Ao observar processos multithread ruby, parece que /proc/pid/cmdlinepermanece inalterado, mas os outros três locais mostram um nome de thread, truncado para 15 caracteres.
man prctlinforma que /proc/pid/commé modificado pela PR_SET_NAMEoperação do prctlsyscall, mas não diz nada sobre /proc/pid/statusand /proc/pid/stat.
man procTell /proc/pid/commfornece um superconjunto do prctl PR_SET_NAMEqual não é mais explicado.
E informa que o segundo campo /proc/pid/statainda estará disponível mesmo se o processo for trocado.
Ao observar os processos JVM, todos os locais mencionados fornecem conteúdos idênticos para todos os threads (os três locais diferentes de cmdlineall shows java), mas jcmd pid Thread.printainda mostram nomes de threads diferentes para os threads existentes, então parece que os threads Java estão usando algum mecanismo não padrão para mudar seu nome.
É /proc/pid/commsempre idêntico à Name:linha /proc/pid/statuse ao segundo campo de /proc/pid/statou há circunstâncias em que um destes três locais oferece conteúdos diferentes?
Forneça um exemplo (fácil de reproduzir) se houver possíveis diferenças.
Depois apt-get install chromiumde executá-lo no Debian 12,
ps alx | grep -e ^F -e ^5.*chromiumretorna:
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
5 1000 3452315 3452313 20 0 33884428 16712 do_sys S ? 0:00 /usr/lib/chromium/chromium --type=zygote --crashpad-handler-pid=3452306 --enable-crash-reporter=,built on Debian 12.4, running on Debian 12.4 --change-stack-guard-on-fork=enable
Isso foi executado no LUbuntu 18 depois apt-get install chromium-browser(o que acontece
snap install chromium) /var/lib/dpkg/info/chromium-browser.preinst:
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
5 1000 197953 197951 20 0 33909972 1228 do_sys S ? 0:00 /snap/chromium/2729/usr/lib/chromium-browser/chrome --type=zygote --crashpad-handler-pid=197944 --enable-crash-reporter=,snap --change-stack-guard-on-fork=enable
Fonde o valor do sinalizador 5significa privilégios de superusuário usados de acordo com man ps.
Por que o navegador Chromium precisa e obtém privilégios de superusuário quando instalado pelo gerenciamento regular de pacotes e executado por um usuário não privilegiado?
ChatGPT diz que isso seria para instalação ou atualização, mas não acredito nisso porque fiz a instalação regularmente apt-gete as atualizações seriam feitas unattended-upgradesno Debian ou snapdno Ubuntu.
Em um HP ZBook G6 com dois SSDs Kingston M.2 NVMe, o Windows está sendo executado sem problemas. Mas ao inicializar o ISO do instalador do Debian 12 a partir de um disco rígido USB, o kernel do Linux 6.0 não detecta esses discos NVMe, mas detecta apenas o disco de inicialização USB no formato /proc/partitions.
Eu tentei, modprobe nvme-core nvme nvmetmas o instalador repetido do Debian "Detect disks" ainda não os detecta. (O instalador ISO initrd não contém um partprobeexecutável, então não tentei /that.) lspcinão mostra nada sobre NVMe.
Mesmo resultado com a instalação gráfica padrão e o instalador especialista em modo texto.
O que posso fazer para detectar os discos NVMe?
Editar: atualizar o BIOS e desativar o Secure Boot não ajudou. O RAID de hardware está desativado.