3. Serviços de usuário, ambiente, permissões e linger

3.1 Por que criar serviços no escopo do usuário?

Nem toda tarefa merece privilégios administrativos ou integração global ao sistema. Agentes pessoais, sincronizadores, serviços de desenvolvimento e aplicações auxiliares podem ser gerenciados por um user manager do systemd. A vantagem é poder criar e controlar o serviço sem escrever em /etc/systemd/system/.

O comando fundamental é:

systemctl --user

Não use sudo systemctl --user para administrar um serviço da sua própria conta: isso poderá direcionar o comando ao contexto errado.

3.2 Criando um serviço pessoal

Vamos fazer um serviço de demonstração em ~/apps/monitor/:

mkdir -p ~/apps/monitor ~/.config/systemd/user

Crie ~/apps/monitor/monitor.py:

import os
import signal
import time

ativo = True

def parar(signum, frame):
    global ativo
    ativo = False

signal.signal(signal.SIGTERM, parar)
signal.signal(signal.SIGINT, parar)

print(f"Monitor iniciado para UID={os.getuid()}", flush=True)
while ativo:
    print("Monitor ativo", flush=True)
    time.sleep(10)
print("Monitor encerrado", flush=True)

Crie ~/.config/systemd/user/monitor-pessoal.service:

[Unit]
Description=Monitor pessoal de exemplo

[Service]
Type=exec
WorkingDirectory=%h/apps/monitor
ExecStart=/usr/bin/python3 %h/apps/monitor/monitor.py
Restart=on-failure
RestartSec=3s

[Install]
WantedBy=default.target

%h é o especificador do diretório pessoal do usuário no gerenciador de usuário. Confirme a localização de python3 na sua máquina.

Ative:

systemctl --user daemon-reload
systemctl --user enable --now monitor-pessoal.service
systemctl --user status monitor-pessoal.service
journalctl --user -u monitor-pessoal.service -f

Para encerrar:

systemctl --user disable --now monitor-pessoal.service

3.3 O que muda no [Install]?

Serviços de sistema frequentemente são associados a multi-user.target; em serviços de usuário gerais, normalmente utilizamos:

[Install]
WantedBy=default.target

O default.target do user manager é distinto do target global da inicialização do sistema. Também existem targets de sessão gráfica que podem atender melhor a programas com interface gráfica.

3.4 User manager e linger

Uma aplicação habilitada no user manager não deve ser automaticamente presumida ativa antes de qualquer login. Seu ciclo de vida depende de como o sistema gerencia sessões.

Para permitir que o gerenciador de determinado usuário continue sem sessão interativa e seja iniciado durante o boot, configure linger:

sudo loginctl enable-linger "$USER"
loginctl show-user "$USER" -p Linger

Para desativar:

sudo loginctl disable-linger "$USER"

Ativar linger não concede privilégios administrativos à aplicação. Ele altera a persistência do user manager. Evite habilitá-lo sem necessidade.

3.5 Serviços de sistema com usuário restrito versus serviços de usuário

Ambos podem executar com privilégios reduzidos, mas não são a mesma coisa:

• No serviço de sistema com User=coletor, a Unit pertence ao gerenciador do sistema e pode ser iniciada como parte da inicialização global.
• No serviço de usuário, a Unit pertence ao gerenciador da conta, com ciclo de vida e configuração próprios.

Para um gateway IoT de função permanente, serviço do sistema com conta dedicada costuma ser uma escolha robusta. Para sincronização pessoal e automação de desenvolvimento, um serviço de usuário costuma ser mais conveniente.

3.6 Python com ambiente virtual

Se o projeto usar pacotes externos, evite depender implicitamente do Python global:

python3 -m venv ~/apps/monitor/.venv
~/apps/monitor/.venv/bin/python -m pip install --upgrade pip

Adapte a Unit:

[Service]
WorkingDirectory=%h/apps/monitor
ExecStart=%h/apps/monitor/.venv/bin/python %h/apps/monitor/monitor.py

Não é necessário executar source .venv/bin/activate: apontar diretamente para o interpretador do ambiente virtual é suficiente para a maioria dos serviços Python.

3.7 Node.js e ambientes carregados por shells

Muitos desenvolvedores instalam Node.js via gerenciadores de versões usados em shells interativos. Isso introduz uma armadilha: o processo criado pelo systemd não herda necessariamente o mesmo PATH e os comandos de inicialização de seu terminal.

Verifique:

command -v node

Use o caminho absoluto do executável adequado no arquivo .service, por exemplo:

[Service]
WorkingDirectory=%h/apps/minha-api
ExecStart=/usr/bin/node %h/apps/minha-api/server.js

Adapte /usr/bin/node ao caminho real. Se o binário estiver instalado em diretório específico de um gerenciador de versões, fixe explicitamente esse caminho ou use uma instalação estável destinada ao serviço. Não dependa de .bashrc.

3.8 Acesso a portas seriais, GPIO e dispositivos

Um serviço de usuário não consegue abrir automaticamente qualquer dispositivo Linux. Para UART, por exemplo:

ls -l /dev/ttyUSB0
id

Permissões podem ser controladas por grupo do dispositivo, regras udev e políticas de acesso. A associação ao grupo dialout, comum em algumas distribuições, não é universal. Para ambientes industriais, use regras udev persistentes que identifiquem o equipamento de modo estável e evite conceder permissões indiscriminadas.

Para um coletor que exige capacidades especiais, prefira definir precisamente os acessos em vez de executar toda a aplicação como root.

Ponto de aprendizagem

Serviços de usuário oferecem isolamento administrativo e conveniência, mas exigem cuidado com o ciclo de sessão, o ambiente herdado, paths absolutos e permissões de hardware.