Na primeira parte desta série de artigos sobre o systemd, procurei mostrar como é simples obter uma relação dos serviços disparados durante a inicialização do sistema.
Depois do boot, o systemd segue seu trabalho iniciando outros processos.
Neste texto vamos abordar alguns métodos para descobrir qual processo é dono de quais outros processos.
Há um número substancial de processos rodando, por padrão, na maioria dos sistemas GNU/Linux.
Saber o que cada processo faz e a que ele pertence, pode ser uma tarefa difícil para um administrador.
Alguns serviços mantém certos processos ativos, que “se misturam”, na saída do comando ps, e podem ser difíceis de identificar.
Este é o caso, por exemplo, de daemons que geram arbitrariamente processos e mais processos.
Uma forma de remediar esta situação é exibir a relação de processos por ordem de herança, através do comando ‘ps xaf’:
ps xaf
Segue o resultado parcial, obtido no meu sistema:
... 2440 ? Ssl 0:00 /usr/sbin/gdm3 2450 ? Sl 0:00 \_ gdm-session-worker [pam/gdm-launch-environment] 2468 tty1 Ssl+ 0:00 | \_ /usr/lib/gdm3/gdm-wayland-session gnome-sessi 2470 tty1 S+ 0:00 | \_ dbus-daemon --print-address 3 --session 2471 tty1 Sl+ 0:00 | \_ /usr/lib/gnome-session/gnome-session-bina 2481 tty1 Sl+ 0:04 | \_ /usr/bin/gnome-shell 2507 tty1 Sl+ 0:00 | | \_ /usr/bin/Xwayland :1024 -rootless 2629 tty1 Sl+ 0:00 | \_ /usr/lib/gnome-settings-daemon/gnome- 2671 ? Sl 0:00 \_ gdm-session-worker [pam/gdm-password] 2719 tty2 Ssl+ 0:00 \_ /usr/lib/gdm3/gdm-x-session --run-script defa 2721 tty2 S+ 10:15 \_ /usr/lib/xorg/Xorg vt2 -displayfd 3 -auth 2754 tty2 S+ 0:00 \_ dbus-daemon --print-address 4 --session 2756 tty2 Sl+ 0:00 \_ /usr/lib/gnome-session/gnome-session-bina 2813 ? Ss 0:00 \_ /usr/bin/ssh-agent x-session-manager 2843 tty2 Sl+ 4:55 \_ /usr/bin/gnome-shell 2981 tty2 Sl+ 0:01 \_ zeitgeist-datahub 2982 tty2 Sl+ 0:00 \_ /usr/bin/python3 /usr/share/system-co 2983 tty2 Sl+ 0:00 \_ /usr/lib/evolution/evolution-alarm-no 3002 tty2 SNl+ 0:00 \_ /usr/lib/tracker/tracker-miner-apps 3003 tty2 SNl+ 0:10 \_ /usr/lib/tracker/tracker-miner-fs 3004 tty2 SNl+ 0:00 \_ /usr/lib/tracker/tracker-miner-user-g 3005 tty2 Sl+ 0:01 \_ /usr/bin/gnome-software --gapplicatio 5613 tty2 Sl+ 0:02 \_ /usr/lib/gnome-settings-daemon/gnome- ...
O resultado deste método, contudo, não é muito confíável, uma vez que os processos — cujos ascendentes morrem — tem seu “parentesco” realocado ao PID 1, fazendo com que toda informação sobre sua árvore se perca.
Se um processo sofrer um “double fork, ele já perde seu relacionamento com o processo que o gerou.
Isto não é um defeito e está dentro da lógica tradicional de lidar com daemons do Unix.
O problema é que não serve para o que se quer no momento.
A possibilidade de um processo mudar seu nome – com o PR_SETNAME ou ajustando o argv – é um recurso que também atrapalha este objetivo.
Com os métodos tradicionais de identificação de processos, o administrador pode acabar no meio de um jogo (sem graça) de “esconde-esconde” com os seus processos.
A abordagem do systemd
Com o systemd, colocamos cada processo novo em um grupo de controle (ou control group) — que leva o nome do seu serviço.
Os control groups ou cgroups na sua forma mais básica são simplesmente grupos de processos que pode ser organizados em uma hierarquia e rotulados individualmente.
Quando processos geram processos filhos, estes se tornam automaticamente membros dos cgroups de seus pais. Sem privilégios, não é possível abandonar um cgroup.
Por isto é que os cgroups podem ser usados como meio eficiente de rotular processos a partir do serviço a que cada um pertence. Além de nos dar a certeza de que os serviços não irão se livrar de seus rótulos, independente da quantidade de vezes em que fizerem forks de si mesmos ou se renomearem.
Neste post, quero introduzir dois comandos que podem ajudar a relacionar serviços e processos do systemd.
O primeiro é o (já conhecido) ps e o segundo é o systemd-cgl.
Relacione processos com o comando ps
O comando ps tem opções para exibir informações dos cgroups junto aos outros detalhes dos processos.
Veja um exemplo (com resultado parcial) do uso do comando:
ps xawf -eo pid,user,cgroup,args
PID USER CGROUP COMMAND ... 2410 root 7:pids:/system.slice,3:devi /usr/sbin/irqbalance --pid=/var/run/irqbalance.pid 2411 root 7:pids:/system.slice,3:devi /usr/lib/policykit-1/polkitd --no-debug 2421 root 7:pids:/system.slice,3:devi /usr/sbin/cups-browsed 2429 colord 7:pids:/system.slice,3:devi /usr/lib/colord/colord 2440 root 7:pids:/system.slice,3:devi /usr/sbin/gdm3 2450 root 7:pids:/user.slice/user-116 \_ gdm-session-worker [pam/gdm-launch-environment] 2468 Debian-+ 7:pids:/user.slice/user-116 | \_ /usr/lib/gdm3/gdm-wayland-session gnome-session --autostart /usr/share/gdm/greete 2470 Debian-+ 7:pids:/user.slice/user-116 | \_ dbus-daemon --print-address 3 --session 2471 Debian-+ 7:pids:/user.slice/user-116 | \_ /usr/lib/gnome-session/gnome-session-binary --autostart /usr/share/gdm/greete 2481 Debian-+ 7:pids:/user.slice/user-116 | \_ /usr/bin/gnome-shell 2507 Debian-+ 7:pids:/user.slice/user-116 | | \_ /usr/bin/Xwayland :1024 -rootless -noreset -listen 4 -listen 5 -displ 2629 Debian-+ 7:pids:/user.slice/user-116 | \_ /usr/lib/gnome-settings-daemon/gnome-settings-daemon 2671 root 7:pids:/user.slice/user-100 \_ gdm-session-worker [pam/gdm-password] 2719 justinc+ 7:pids:/user.slice/user-100 \_ /usr/lib/gdm3/gdm-x-session --run-script default 2721 justinc+ 7:pids:/user.slice/user-100 \_ /usr/lib/xorg/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -back 2754 justinc+ 7:pids:/user.slice/user-100 \_ dbus-daemon --print-address 4 --session 2756 justinc+ 7:pids:/user.slice/user-100 \_ /usr/lib/gnome-session/gnome-session-binary 2813 justinc+ 7:pids:/user.slice/user-100 \_ /usr/bin/ssh-agent x-session-manager 2843 justinc+ 7:pids:/user.slice/user-100 \_ /usr/bin/gnome-shell 2981 justinc+ 7:pids:/user.slice/user-100 \_ zeitgeist-datahub 2982 justinc+ 7:pids:/user.slice/user-100 \_ /usr/bin/python3 /usr/share/system-config-printer/applet.py 2983 justinc+ 7:pids:/user.slice/user-100 \_ /usr/lib/evolution/evolution-alarm-notify 3002 justinc+ 7:pids:/user.slice/user-100 \_ /usr/lib/tracker/tracker-miner-apps 3003 justinc+ 7:pids:/user.slice/user-100 \_ /usr/lib/tracker/tracker-miner-fs 3004 justinc+ 7:pids:/user.slice/user-100 \_ /usr/lib/tracker/tracker-miner-user-guides 3005 justinc+ 7:pids:/user.slice/user-100 \_ /usr/bin/gnome-software --gapplication-service 5613 justinc+ 7:pids:/user.slice/user-100 \_ /usr/lib/gnome-settings-daemon/gnome-settings-daemon 2455 root 7:pids:/system.slice,3:devi /sbin/wpa_supplicant -u -s -O /run/wpa_supplicant 2462 Debian-+ 7:pids:/user.slice/user-116 /lib/systemd/systemd --user 2463 Debian-+ 7:pids:/user.slice/user-116 \_ (sd-pam) 2485 root 7:pids:/system.slice,3:devi /usr/lib/upower/upowerd 2532 Debian-+ 7:pids:/user.slice/user-116 /usr/lib/at-spi2-core/at-spi-bus-launcher 2551 Debian-+ 7:pids:/user.slice/user-116 \_ /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --n ...
Na terceira coluna, da listagem, é exibido o cgroup dado pelo systemd a cada processo.
Se você pretende rodar este comando com frequência, crie um alias para ele:
alias psc='ps xawf -eo pid,user,cgroup,args'
Agora, basta usar o alias psc.
Relacione os processos com o systemd-cgls
Talvez você julgue mais adequado relacionar processos com seus cgroups usando a ferramenta systemd-cgls.
Ela exibe cada cgroup hierarquicamente, dentro de uma árvore.
Veja um exemplo:
systemd-cgls
...
│ ├─polkitd.service
│ │ └─2411 /usr/lib/policykit-1/polkitd --no-debug
│ ├─cups-browsed.service
│ │ └─2421 /usr/sbin/cups-browsed
│ ├─NetworkManager.service
│ │ ├─2332 /usr/sbin/NetworkManager --no-daemon
│ │ └─2583 /sbin/dhclient -d -q -sf /usr/lib/NetworkManager/nm-dhcp-helper -pf /
│ ├─irqbalance.service
│ │ └─2410 /usr/sbin/irqbalance --pid=/var/run/irqbalance.pid
│ ├─rsyslog.service
│ │ └─2337 /usr/sbin/rsyslogd -n
│ ├─gdm.service
│ │ └─2440 /usr/sbin/gdm3
│ ├─bluetooth.service
│ │ └─7068 /usr/lib/bluetooth/bluetoothd
│ └─rtkit-daemon.service
└─2569 /usr/lib/rtkit/rtkit-daemon
...
Novamente, o resultado exibido no meu exemplo está resumido (cortado) para tentar evitar informações irrelevantes para o contexto deste artigo.
Aqui, são exibidos os processos, por cgroups e, consequentemente, por serviços, uma vez que o systemd etiqueta os cgroups pelos seus serviços.
Referências
Outros posts sobre o systemd.
Systemd para administradores – parte 1.
http://0pointer.de/blog/projects/systemd-for-admins-2.html.
