Perguntas[systemd](unix)

Um serviço meu morreu recentemente devido a oom-kill.

$ systemctl status my-server.service
● my-server.service - "General purposes load-independent HTTP server"
     Loaded: loaded (/lib/systemd/system/my-server.service; enabled; vendor preset: enabled)
     Active: failed (Result: oom-kill) since Thu 2025-02-27 12:47:44 CST; 17h ago
    Process: 636 ExecStart=/usr/bin/my-server --listen-http :13668 --threads 10 (code=exited, status=0/SUCCESS)
   Main PID: 636 (code=exited, status=0/SUCCESS)
        CPU: 52min 57.893s

Feb 27 12:47:44 ios systemd[1]: my-server.service: A process of this unit has been killed by the OOM killer.
Feb 27 12:47:44 ios my-server[636]: Received signal to stop (15). Stopping...
Feb 27 12:47:44 ios systemd[1]: my-server.service: Failed with result 'oom-kill'.
Feb 27 12:47:44 ios systemd[1]: my-server.service: Consumed 52min 57.893s CPU time.

man systemd.execdiz $SERVICE_RESULTque está definido para oom-killquando "Um processo de serviço foi encerrado pelo assassino de falta de memória (OOM)".

Este foi um vazamento de memória em um processo filho de longa duração de /usr/bin/my-server. Quando isso acontece, eu gostaria de Restart=o serviço.

A questão:

Isso $SERVICE_RESULT=oom-killaciona um código de saída impuro ou um sinal impuro?

Gostaria de limitar Restart=o máximo possível. Assim, gostaria de escolher a primeira condição que atende aos oom-killcritérios da lista abaixo:

• Restart=on-abortpode ser usado se for um sinal impuro.
• Restart=on-abormalpode ser usado para o caso acima, ou se acionar a causa de tempo limite ou causa de watchdog (provavelmente não aplicável).
• Restart=on-failurefunciona para todos os casos acima, além de um código de saída impuro.
• Restart=alwaysteoricamente cobre tudo

De man systemd.service:

Table 2. Exit causes and the effect of the Restart= settings
┌──────────────────────┬────┬────────┬────────────┬────────────┬─────────────┬──────────┬─────────────┐
│Restart settings/Exit │ no │ always │ on-success │ on-failure │ on-abnormal │ on-abort │ on-watchdog │
│causes                │    │        │            │            │             │          │             │
├──────────────────────┼────┼────────┼────────────┼────────────┼─────────────┼──────────┼─────────────┤
│Clean exit code or    │    │ X      │ X          │            │             │          │             │
│signal                │    │        │            │            │             │          │             │
├──────────────────────┼────┼────────┼────────────┼────────────┼─────────────┼──────────┼─────────────┤
│Unclean exit code     │    │ X      │            │ X          │             │          │             │
├──────────────────────┼────┼────────┼────────────┼────────────┼─────────────┼──────────┼─────────────┤
│Unclean signal        │    │ X      │            │ X          │ X           │ X        │             │
├──────────────────────┼────┼────────┼────────────┼────────────┼─────────────┼──────────┼─────────────┤
│Timeout               │    │ X      │            │ X          │ X           │          │             │
├──────────────────────┼────┼────────┼────────────┼────────────┼─────────────┼──────────┼─────────────┤
│Watchdog              │    │ X      │            │ X          │ X           │          │ X           │
└──────────────────────┴────┴────────┴────────────┴────────────┴─────────────┴──────────┴─────────────┘

Estou tentando configurar o SpamAssassin no meu servidor de e-mail (Rocky Linux 9.5). Apenas uma configuração básica!

Esta é a variável de opções em /etc/sysconfig/spamassassin:

SPAMDOPTIONS="-d -c -m5 -H --create-prefs --max-children 2 -u spamd -g spamd --socketpath=/var/lib/spamassassin/spamd.sock --socketowner=spamd --socketgroup=spamd --socketmode=0666 -s /var/log/spamd.log --debug"

--debugfoi adicionada a temporalidade

Quando inicio o SpamAssassin usando systemctl, ele sai com erros aleatórios e o systemd o reinicia novamente, coloquei o log truncado abaixo:

.
.
Fri Feb 14 19:59:03 2025 [2133] info: spamd: server successfully spawned child process, pid 2135
Fri Feb 14 19:59:03 2025 [2133] dbg: prefork: child 2135: entering state 0
Fri Feb 14 19:59:03 2025 [2133] dbg: prefork: new lowest idle kid: none
Fri Feb 14 19:59:03 2025 [2135] dbg: spamd: Privilege de-escalation from user 0 and groups 0
Fri Feb 14 19:59:03 2025 [2135] dbg: spamd: setgid ERRNO is 
Fri Feb 14 19:59:03 2025 [2135] dbg: util: get_user_groups: uid is 98
Fri Feb 14 19:59:03 2025 [2133] info: spamd: server successfully spawned child process, pid 2136
Fri Feb 14 19:59:03 2025 [2133] dbg: prefork: child 2136: entering state 0
Fri Feb 14 19:59:03 2025 [2133] dbg: prefork: new lowest idle kid: none
Fri Feb 14 19:59:03 2025 [2136] dbg: spamd: Privilege de-escalation from user 0 and groups 0
Fri Feb 14 19:59:03 2025 [2136] dbg: spamd: setgid ERRNO is 
Fri Feb 14 19:59:03 2025 [2136] dbg: util: get_user_groups: uid is 98
Fri Feb 14 19:59:03 2025 [2133] info: spamd: server killed by SIGTERM, shutting down
Fri Feb 14 19:59:04 2025 [2137] dbg: logger: successfully added file method
.
.

Decidi usar o seguinte comando e executá-lo tanto spamdem cliprimeiro plano quanto no daemonizado. Funcionou perfeitamente!

sudo -u spamd -- spamd -c -m5 -H --create-prefs --max-children 2 -u spamd -g spamd --socketpath=/var/lib/spamassassin/spamd.sock --socketowner=spamd --socketgroup=spamd --socketmode=0666 -s /var/log/spamd.log --debug

Também funciona corretamente sem sudo!

Alguém já teve problemas semelhantes com o SpamAssassin ou qualquer outro serviço?

Temos três serviços com PrivateTmp=yes( tomcat, clamde soffice). clamde sofficedefinimos JoinsNamespaceOf=tomcat.service.

clamddeveria ser capaz de ler tudo que tomcatescreve nele /tmp, certo?

Existe uma chance (por exemplo, reinicialização de serviços) de que essa junção seja interrompida em tempo de execução (por exemplo, clamdperdendo a capacidade de leitura tomcat's /tmp)?

Como posso verificar em tempo de execução se essa junção existe (ainda está funcionando)?

Tentei usar lsnse lsns NSver alguma relação, mas não consegui reconhecer nada.

Quero iniciar automaticamente um aplicativo GUI, sempre que eu conectar um determinado dispositivo USB. Quando iniciado, o aplicativo roda em primeiro plano e não deve rodar como root.

Como posso fazer isso?

No meu caso específico, quero executar o Yubico Authenticator sempre que conectar meu token de hardware Yubikey USB FIDO2/TOTP.

Notei que no meu servidor RHEL 7 no GCP, meus serviços habilitados (como o test.service) só serão iniciados se eu encerrar o serviço multi-user.target usando systemctl. Haveria algum motivo para o multi-user.target travar as coisas?

Quero configurar a limitação de recursos do cgroups V2 em um contêiner Docker-Compose. Como faço isso?

Eu tenho esse script que funciona:

#! /usr/bin/bash

export SEQVAL=$(date +%s) &&  sed -i "s/^SEQ1=.*$/SEQ1=${SEQVAL}/" /etc/environment
systemctl restart ccs-srvapp-telemetry.service

Não consigo fazer o que foi dito acima funcionar corretamente em um arquivo de unidade.

a última encarnação que tenho está abaixo, mas houve várias tentativas com várias configurações, todas falhando porque a variável não foi definida ou algo não escapou corretamente no comando sed.

[Unit]
Description=restarts fluent bit with a new SEQ1 to force a logrotate
After=network.target


[Service]
Type=oneshot
EnvironmentFile=/etc/environment
ExecStart=/usr/bin/sh -c 'export SEQVAL=$(date +%s) && sed -i "s/^SEQ1=.*$/SEQ1=${SEQVAL}/" /etc/environment'
ExecStartPost=/bin/systemctl restart ccs-srvapp-telemety.service


[Install]
WantedBy=multi-user.target

Quero aprender sobre o backdoor do XZ Utils seguindo a demonstração do exploit xzbot e configurando o ambiente . Sei que a versão 5.6.1 do xz-utils deve ter o backdoor, mas não consigo instalar esse pacote comprometido.

Começando com um ambiente limpo Kali Linux 2024.4, ele tem liblzma 5.6.3 e sshdnão parece depender de libsystemd e liblzma. Aparentemente, nem o OpenSSH de estoque nem o portátil vêm com suporte ao systemd. Estou confuso com todos os guias que esperam sshdjá estar vinculados ao liblzma, enquanto ele simplesmente não é para mim.

└─$ dpkg -l | grep liblzma5
ii  liblzma5:amd64                                 5.6.3-1+b1                               amd64        XZ-format compression library

└─$ ldconfig -p | grep liblzma
        liblzma.so.5 (libc6,x86-64) => /lib/x86_64-linux-gnu/liblzma.so.5

└─$ sshd -V
OpenSSH_9.9p1 Debian-3, OpenSSL 3.3.2 3 Sep 2024

└─$ ldd $(which sshd)
        linux-vdso.so.1 (0x00007fc3de0b8000)
        libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fc3ddfde000)
        libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007fc3dda00000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc3dd80a000)
        libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007fc3dd768000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fc3de0ba000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fc3ddfbe000)
        libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007fc3dd6a7000)

Ao fazer o downgrade para o pacote liblzma 5.6.1 e verificar lddnovamente, nada parece ter mudado.

└─$ wget https://snapshot.debian.org/archive/debian/20240328T025657Z/pool/main/x/xz-utils/liblzma5_5.6.1-1_amd64.deb             
2024-12-24 00:45:29 (4.72 MB/s) - ‘liblzma5_5.6.1-1_amd64.deb’ saved [252188/252188]

└─$ sudo dpkg -i ./liblzma5_5.6.1-1_amd64.deb
dpkg: warning: downgrading liblzma5:amd64 from 5.6.3-1+b1 to 5.6.1-1
(Reading database ... 425071 files and directories currently installed.)
Preparing to unpack ./liblzma5_5.6.1-1_amd64.deb ...
Unpacking liblzma5:amd64 (5.6.1-1) over (5.6.3-1+b1) ...
Setting up liblzma5:amd64 (5.6.1-1) ...
Processing triggers for libc-bin (2.40-3) ...

└─$ dpkg -l | grep liblzma5
ii  liblzma5:amd64                                 5.6.1-1                                  amd64        XZ-format compression library
                                                                                          
└─$ sudo systemctl restart ssh

└─$ ldd $(which sshd)                                                                                               
        linux-vdso.so.1 (0x00007f705e59b000)
        libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f705e4c1000)
        libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f705de00000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f705dc0a000)
        libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f705e41f000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f705e59d000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f705e3ff000)
        libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f705db49000)

Então eu tentei construir o OpenSSH 9.7p1, já que isso foi antes do backdoor se tornar público, se isso talvez ajudasse. Isso exigiu uma reinicialização antes de sshd -Vmostrar 9.7p1

wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-9.7p1.tar.gz
tar -xvf openssh-9.7p1.tar.gz
cd openssh-9.7p1
sudo apt install libssl-dev
./configure
make
sudo make install

Mas tanto o libsystemd quanto o liblzma ainda não estavam vinculados ao sshd.

Neste ponto, não tenho a mínima ideia de como instalar ou construir o pacote vulnerável xz-utils. Tive problemas semelhantes ao tentar os mesmos passos com o Ubuntu 24.04

Ambiente

Este é um servidor vps Ubuntu 22.04.5. O Wireguard usa tuntap em vez do kernel mod.

Roteiro

/etc/wireguard/gw0.shpode iniciar o wireguard corretamente se executado a partir da linha de comando:

# cleanup
echo "$(date) - cleanup"
/usr/sbin/ip link del gw0 2>&1
/usr/sbin/iptables -t nat -D POSTROUTING -s 10.0.0.0/24 -o venet0 -j MASQUERADE 2>&1

# setup
echo "$(date) - setup"
#/usr/sbin/ip tuntap add dev gw0 mode tun
/usr/bin/wireguard gw0 2>&1
/usr/sbin/ip a add 10.0.0.1/24 dev gw0
/usr/bin/wg set gw0 listen-port 12345
/usr/bin/wg set gw0 private-key /etc/wireguard/gw0.key
# wg0
/usr/bin/wg set gw0 peer <wg0 key> allowed-ips 10.0.0.2/32
# wg1
/usr/bin/wg set gw0 peer <wg1 key> allowed-ips 10.0.0.3/32

# start
echo "$(date) - start"
/usr/sbin/ip link set gw0 up 2>&1
/usr/sbin/iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o venet0 -j MASQUERADE 2>&1

# end
echo "$(date) - end"

exit 0

Saída:

# /etc/wireguard/gw0.sh
Thu Dec  5 10:03:32 EST 2024 - cleanup
Cannot find device "gw0"
Thu Dec  5 10:03:32 EST 2024 - setup
┌──────────────────────────────────────────────────────┐
│                                                      │
│   Running wireguard-go is not required because this  │
│   kernel has first class support for WireGuard. For  │
│   information on installing the kernel module,       │
│   please visit:                                      │
│         https://www.wireguard.com/install/           │
│                                                      │
└──────────────────────────────────────────────────────┘
Thu Dec  5 10:03:32 EST 2024 - start
Thu Dec  5 10:03:33 EST 2024 - end

Serviço Systemd

/etc/systemd/system/gw0.service:

[Unit]
Description = Start Wireguard gw0
After = network-online.target
Wants = network-online.target
[Service]
Type = oneshot
ExecStart = /usr/bin/bash -c "/etc/wireguard/gw0.sh >> /tmp/gw0.log"

[Install]
WantedBy=multi-user.target

Iniciar o serviço sempre resultará em erro de tempo limite e nenhum processo wireguard:

# systemctl start gw0.service
Job for gw0.service failed because a timeout was exceeded.
See "systemctl status gw0.service" and "journalctl -xeu gw0.service" for details.

# systemctl status gw0.service
× gw0.service - Start Wireguard gw0
     Loaded: loaded (/etc/systemd/system/gw0.service; disabled; vendor preset: enabled)
     Active: failed (Result: timeout) since Thu 2024-12-05 10:12:07 EST; 34s ago
    Process: 95515 ExecStart=/usr/bin/bash -c /etc/wireguard/gw0.sh >> /tmp/gw0.log (code=exited, status=0/SUCCESS)
   Main PID: 95515 (code=exited, status=0/SUCCESS)

Dec 05 10:10:37 mybox systemd[1]: Starting Start Wireguard gw0...
Dec 05 10:12:07 mybox systemd[1]: gw0.service: State 'stop-sigterm' timed out. Killing.
Dec 05 10:12:07 mybox systemd[1]: gw0.service: Failed with result 'timeout'.
Dec 05 10:12:07 mybox systemd[1]: Failed to start Start Wireguard gw0.

# journalctl -xeu gw0.service
Dec 05 10:10:37 mybox systemd[1]: Starting Start Wireguard gw0...
░░ Subject: A start job for unit gw0.service has begun execution
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit gw0.service has begun execution.
░░
░░ The job identifier is 2611.
Dec 05 10:12:07 mybox systemd[1]: gw0.service: State 'stop-sigterm' timed out. Killing.
Dec 05 10:12:07 mybox systemd[1]: gw0.service: Failed with result 'timeout'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ The unit gw0.service has entered the 'failed' state with result 'timeout'.
Dec 05 10:12:07 mybox systemd[1]: Failed to start Start Wireguard gw0.
░░ Subject: A start job for unit gw0.service has failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit gw0.service has finished with a failure.
░░
░░ The job identifier is 2611 and the job result is failed.

No entanto, /tmp/gw0.logmostra o script concluído:

Thu Dec  5 10:10:37 EST 2024 - cleanup
Thu Dec  5 10:10:37 EST 2024 - setup
┌──────────────────────────────────────────────────────┐
│                                                      │
│   Running wireguard-go is not required because this  │
│   kernel has first class support for WireGuard. For  │
│   information on installing the kernel module,       │
│   please visit:                                      │
│         https://www.wireguard.com/install/           │
│                                                      │
└──────────────────────────────────────────────────────┘
Thu Dec  5 10:10:37 EST 2024 - start
Thu Dec  5 10:10:37 EST 2024 - end

Pergunta

Alguém tem ideia de como fazer gw0.servicefuncionar?

O arquivo de unidade systemd não pode ser executado manualmente, então deve haver algo que o acione. Dependências reversas podem exigir isso, mas como elas também são iniciadas? Normalmente, elas não são iniciadas antes startx(ou pelo menos não deveriam ser), então deve haver um ponto de acionamento.

Estou mais interessado em como ele funciona com o startx, e não com um gerenciador de login.

Detalhes sobre como gnome-session.targetfunciona especificamente também seriam ótimos, já que é o exemplo mais prático de uma implementação de framework de sessão que utiliza graphical-session.target. O binário gnome-session tem uma --systemdopção. Talvez seja onde o gatilho do ponto de partida é colocado. Seria triste saber que os binários podem simplesmente ignorar RefuseManualStart=yes. Isso seria muito... gatilho.