Início / unix / Perguntas / 775286
Accepted
k.schroeder31
Asked: 2024-04-27 00:02:31 +0800 CST

Por que um comando process ps mostra espaços em torno de um diretório em vez de barras?

  • 772

Estou tentando depurar um monitor de processo legado com falha que pesquisa processos em execução. Eu determinei que isso está sendo causado por algum comportamento misterioso do Linux. O processo que está sendo executado é /opt/my/path/directoryname/daemonname, mas por algum motivo estranho, ele aparece com espaços, não /, ao redor do nome do diretório. Muitos daemons estão sendo executados no mesmo diretório e aparecem com o caminho correto. É apenas um daemon específico em cada servidor.

ps -efmostra o seguinte para este daemon:

/opt/my/path directoryname daemonname --arg1 VALUE1 --arg-two VALUE.TWO --arg-three ARG.UMENT.THREE.ERR --worker daemonname --pid-role daemonname

Este daemon está sendo iniciado por um script perl. Comparando-o com outros, parece que o caminho do diretório está sendo fornecido usando exatamente a mesma variável env de todos os outros scripts, mas esses outros scripts resultam em um caminho correto como /opt/my/path/directoryname/daemonname. As linhas Perl relevantes se parecem com exec => catfile( $settings->config("/directories/executables"), $daemon_name ),e eu confirmei que o valor de config("/directories/executables") é o valor correto/opt/my/path/directoryname

Procurar por esta pergunta tem sido um pesadelo devido a todas as perguntas sobre nomes de diretórios com espaços. Isto não é isso. Nenhum caminho deve conter um espaço. ps mostra meu comando mkdir com um espaço onde eu tinha uma barra é o mais próximo que consegui encontrar, que não foi respondido.

perl

1 respostas

  1. Best Answer

    Entre os campos retornados por ps -festá a lista de argumentos passados ​​para a última execução do comando que o processo (ou um de seus ancestrais) realizou. Você pode conseguir exatamente isso com ps -o args.

    Quando um processo executa um arquivo, isso ocorre com a execve()chamada do sistema:

    execve("/path/to/executable", [arg0, arg1..., 0], [env1, env2... 0])

    arg0por convenção é o nome do executável. Quando um shell interpreta um:

    cmd arg

    linha de comando, ele chama execve("/path/to/cmd", ["cmd", "arg", 0], ...). Quando isso é:

    /path/to/cmd arg

    Ele chama execve("/path/to/cmd", ["/path/to/cmd", "arg", 0], ...).

    Essas strings ( cmd, arg) terminam na parte inferior da pilha do processo, delimitadas por NUL. Dentro do processo, é isso que argv[0]... argv[1]aponta.

    No Linux, essa área é exposta em /proc/<pid>/cmdline, e é daí psque vem para o argscampo.

    Tecnicamente, pspega essa lista de strings e imprime-a unida com espaços para que no final os argscampos se pareçam com a linha de comando do shell que seria usada para executar o comando.

    Aqui, se psmostra:

    /opt/my/path directoryname daemonname --arg1...

    Esses espaços podem indicar um espaço real nessas strings, ou strings separadas ou o fato de que os espaços foram substituídos por NULs nessas strings.

    O último é plausível se o processo usou a função padrãostrtok() ou uma abordagem semelhante para argv[0]dividi-lo, /possivelmente para descobrir o nome base do executável como ele foi executado ou os diferentes componentes do diretório de seu caminho.

    Por exemplo, se eu criar:

    #include <string.h>
#include <unistd.h>
int main(int argc, char *argv[])
{
  strtok(argv[0], "/");
  while (strtok(NULL, "/"));
  pause();
}

    E compile e execute:

    $ cc a.c
$ "$PWD/a.out" &
[1] 67758
$ ps -fp "$!"
UID          PID    PPID  C STIME TTY          TIME CMD
chazelas   67758   60043  0 19:19 pts/4    00:00:00 /home chazelas a.out

    Você verá que os /s foram substituídos por espaços.

    Na verdade, eles foram substituídos por NULs, como pode ser verificado em:

    $ sed -n l "/proc/$!/cmdline"
/home\000chazelas\000a.out\000$

    Mas psvi esses NULs e os interpretei como delimitadores para 3 argumentos diferentes que uniram com espaços.

    Então, supondo que essa seja a explicação correta, não é um comportamento estranho do Linux, é apenas o próprio aplicativo modificando-o argv[0]após ser iniciado (provavelmente substituindo /s por NULs, provavelmente para extrair alguns componentes do caminho).

    No Linux, uma maneira mais confiável de descobrir qual executável um processo está em execução no momento é executar um readlink()on /proc/<pid>/exe, por exemplo, com o utilitário realpathor readlinkou o statintegrado de zsh:

    $ zmodload zsh/stat
$ stat +link /proc/$!/exe
/home/chazelas/a.out
$ readlink "/proc/$!/exe"
/home/chazelas/a.out
$ realpath "/proc/$!/exe"
/home/chazelas/a.out

    E a implementação do procps psno Linux retorna com ps -o exe.

    Não existe uma maneira infalível de saber com certeza quais argumentos foram passados ​​para o comando, pois o que é mostrado /proc/<pid>/cmdlinepode ser modificado pelo processo.

    Os registros de auditoria podem conter as informações.

    • 10

relate perguntas