Início / unix / Perguntas / 772135
Accepted
ysalmon
Asked: 2024-03-12 06:23:18 +0800 CST

Como os "Aplicativos" são executados com processos wrt gerenciados pelo krunner?

  • 772

Eu tenho um script bash, chamado runthunderbird, que… executa o Thunderbird:

#!/bin/bash
sleep 5
thunderbird & disown

Quando executo runthunderbirda partir do krunner, o Thunderbird inicia após 5 segundos conforme pretendido e, em seguida, o runthunderbirdprocesso termina, conforme evidenciado pela ps -eflista de processos no monitor do sistema do Plasma 5.27.10.

Porém, o mesmo monitor do sistema possui uma aba Aplicativos onde runthunderbirdpermanece listado, em vez de thunderbird-bin, o consumo de recursos (ex. memória) do Thunderbird.

Se, em vez de apenas o Thunderbird, os scripts executarem vários aplicativos gráficos antes de terminarem, eles serão agrupados na guia Aplicativo, novamente sob o nome do script (terminado).

Estou me perguntando como isso é gerenciado e como devo escrever meu script para separar completamente o Thunderbird do script e executá-lo.

Também estou me perguntando se esse fato está relacionado ao Thunderbird não ser executado de forma eficaz quando o script runthunderbird é executado no login a partir de um arquivo da área de trabalho no formato ~/.config/autostart.

shell-script

1 respostas

  1. Best Answer

    É gerenciado via cgroups e systemd. (Ou seja, tenho 95% de certeza de que é gerenciado via cgroups e systemd, embora não tenha o KDE instalado aqui para confirmar.)

    Recentemente, tanto o GNOME quanto o KDE começaram a usar o suporte do systemd para criação dinâmica de .services e .scopes para iniciar aplicativos de desktop se o systemd --usergerenciador de serviços em nível de usuário estiver em execução. Isso é baseado no recurso cgroup do Linux – cada .service ou .scope do systemd corresponde a um cgroup do Linux. (Cgroups são anteriores ao systemd, mas tiveram pouca utilidade antes dele.)

    Assim que o processo do aplicativo é gerado, eles pedem ao systemd para movê-lo para uma unidade .scope temporária (e, consequentemente, para um novo cgroup). Posteriormente, o gerenciador de tarefas pode consultar o nome do cgroup de cada processo /proc/<PID>/cgroupe ler os valores dos recursos /sys/fs/cgroup(que também fornece uma lista de PIDs dentro de cada cgroup).

    Dê uma olhada systemd-cglsou loginctl user-statusveja a árvore cgroup resultante; confira systemd-cgtopcomo exemplo de medição de recursos por cgroup. Você pode até adicionar a coluna "Unidade Systemd" em htop ou ps, por exemplo ps -e -o pid,cmd,unit,uunit.

    Você também poderá ver cgroups individuais sendo criados para cada aba do terminal ; Terminais GNOME (libvte) e tmux fazem isso agora e ouvi dizer que o Konsole também faz. (Entre outras coisas, ele permite que cada guia tenha seu próprio limite de tarefas; executei com sucesso o forkbomb "bash smiley" no Terminal GNOME e o resto do sistema continuou funcionando.)

    Estou me perguntando como isso é gerenciado e como devo escrever meu script para separar completamente o Thunderbird do script e executá-lo.

    Cgroups são criados a) iniciando serviços, b) dinamicamente com systemd-run --user. Para "desconectar" o Thunderbird, você poderia usar:

    systemd-run --user [--scope] --collect /bin/thunderbird

    (…ou você pode criar um "thunderbird.service" real no seu ~/.config/systemd/user/e executá-lo usando systemctl --user start. Isso, combinado com "thunderbird.timer" para atrasar a inicialização, eliminaria totalmente a necessidade do seu script.)

    Use --scopee -u/--unit="app-foo-bar"para torná-lo mais semelhante ao que o GNOME e o KDE estão fazendo. O padrão do Systemd-run é criar um .service; a diferença é que as unidades .service sempre têm seus processos gerados pelo próprio systemd, enquanto .scope permite que o chamador mova um processo já em execução.

    Isso também significa que no modo de escopo o comando ainda será executado "em primeiro plano", a menos que você &o execute normalmente, enquanto no modo de serviço ele sempre será executado "em segundo plano" e você precisará perguntar explicitamente -t/--ptyse deseja executar um terminal interativo app, ou -P/--pipese o programa não for necessariamente interativo, mas você ainda quiser ver seu resultado; caso contrário, todo stdout irá para os logs do sistema (journalctl).

    Isso -G/--collectapenas evita que unidades obsoletas permaneçam por aí.

    Systemd-run pode ser útil para especificar um limite de memória no nível do cgroup para uma tarefa potencialmente grande sem risco de OOM em todo o sistema – dê uma olhada nos -p/--propertyparâmetros.

    • 0

relate perguntas