Início / unix / Perguntas / 762741
Accepted
Jan
Asked: 2023-11-30 18:47:01 +0800 CST

Por que “pgrep -O 600” falha em um LXC? erro de procps?

  • 772

Debian 12.2 em um LXC sem privilégios (proxmox). São quase 11h45, horário local. Às 5h da manhã, o cron iniciou um script:

USER      PID    %CPU %MEM  VSZ   RSS TTY      STAT START   TIME COMMAND
jan       26633  0.0  0.0   8500  2056 ?       S    05:00   0:00 /usr/sbin/CRON -f

Estou usando pgrep -f CRON -O 600e espero que o pgrep retorne o PID 26633, porque o processo tem muito mais de 600 segundos. Mas o pgrep não retorna nada. Se eu deixar de fora -O, ele retornará corretamente o PID.

Fazendo o mesmo na máquina host, ou seja, fora do LXC, funciona corretamente.
Como o pgrep usa procps, olhei lá.
ps -o etime -p $pidno LXC: 441077225-02:04:48 (errado, porque desde 5h, ~6h45 se passaram)
ps -o etime -p $pidno host: 06:43:29 (correto)

Isso seria um bug no procps ou tem a ver com o LXC?

linux

1 respostas

  1. Best Answer

    O LXC monta um falso /proc/uptimepara simular o tempo de atividade do contêiner em vez do tempo de atividade do host, uma vez que esta propriedade não tem namespace. Aqui em um contêiner LXC (raiz):

    # findmnt /proc/uptime
TARGET       SOURCE              FSTYPE     OPTIONS
/proc/uptime lxcfs[/proc/uptime] fuse.lxcfs rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other

    Mas não existe tal provisão para stato pseudoarquivo de cada processo em /proc/PID/stat.

    Portanto, quando pgrepcompara o tempo, faz a diferença entre o atual /proc/uptimee o starttimecampo /proc/PID/statconforme descrito em proc(5)e fontes procps :

        PIDS_TIME_ELAPSED,      //     real     *  derived from stat: (/proc/uptime - start_time) / hertz

    Como o contêiner /proc/uptimeé falsificado pelo LXC (acho que usando /proc/uptimeo horário de início pid 1 do host menos o contêiner LXC), o resultado final obtém o horário de início do contêiner subtraído , resultando em um valor negativo inicialmente (e por algum tempo, mas ainda errado de qualquer maneira) se/quando se tornar positivo mais tarde), o que é inesperado, uma vez que o tempo de atividade do sistema deve ser maior que o start_time do processo de destino (possivelmente ajustado por um fator de $(getconf CLK_TCK)). As ferramentas procps não conseguem lidar com isso corretamente.

    Não sei sobre uma solução alternativa: se /proc/uptimefor restaurado para seu valor de host, então pgrep -Oou ps -o etime -pcalculará o valor correto, mas qualquer ferramenta que use o tempo de atividade do sistema agora obterá o tempo de atividade do host em vez do tempo de atividade (falsificado) do contêiner.

    • 2

relate perguntas