Eu já tinha descrito em atualizando mapas de DNS no estilo do DynDNS como fazia o sistema de DNS dinâmico que uso pra manter o nome bolha.linux-br.org atualizado, entre alguns outros, com o link residencial que tenho em casa.
Funcionava mas não era aquela maravilha. Atualizava a cada 5 minutos e pegava a mudança de IP pelos logs do Apache.
Até aí, sem grandes problemas.
Mas daí o Guto, da instância bolha.us, disse que estava tendo problemas de conexão com a bolha.linux-br.org.
Minha suspeita foi DNS. Então dei uma olhada nos logs.
starting: 20251228T18:45:01
finished: 20251228T18:45:01
starting: 20251228T18:50:01
finished: 20251228T18:50:01
starting: 20251228T18:55:01
updating IPv4 for raspberry3: old=83.233.219.150 new=51.75.236.128
updating: filename=/etc/bind/master/db.linux-br.org old_serial=2025122854 new_serial=2025122855
restarting named.service
finished: 20251228T18:55:01
starting: 20251228T19:00:01
updating IPv4 for raspberry3: old=51.75.236.128 new=83.233.219.150
updating: filename=/etc/bind/master/db.linux-br.org old_serial=2025122855 new_serial=2025122856
restarting named.service
finished: 20251228T19:00:01
starting: 20251228T19:05:01
finished: 20251228T19:05:01
starting: 20251228T19:10:01
finished: 20251228T19:10:01
starting: 20251228T19:15:01
finished: 20251228T19:15:01
starting: 20251228T19:20:01
updating IPv4 for raspberry3: old=83.233.219.150 new=51.68.247.213
updating: filename=/etc/bind/master/db.linux-br.org old_serial=2025122856 new_serial=2025122857
restarting named.service
finished: 20251228T19:20:01
starting: 20251228T19:25:01
updating IPv4 for raspberry3: old=51.68.247.213 new=83.233.219.150
updating: filename=/etc/bind/master/db.linux-br.org old_serial=2025122857 new_serial=2025122858
restarting named.service
finished: 20251228T19:25:01
starting: 20251228T19:30:01
finished: 20251228T19:30:01O código mostra que IPv4 mudou várias vezes no mesmo dia.
Então entrei em contato com o provedor e perguntei se não era possível deixar o lease do DHCP mais longo. A resposta foi que um desses IPs nem era deles.
Um bug na lógica.
Então resolvi escrever algo em Go pra tomar o lugar desse sistema pereba de atualização de DNS. Fiz o dns-monitor.
Agora o dns-monitor funciona ouvido numa API REST, que recebe JSON, atualiza no banco de dados, faz o update dos mapas de DNS e reinicia o serviço de DNS via systemd.
E vejo logs assim:
Feb 24 18:15:02 dns-monitor[1139847]: [2026-02-24T18:15:02] (INFO): [RESP] remote_addr=127.0.0.1:59286, real_ip=2a00:1598:23af:4900:5fe7:c566:dbbd:7b35 status_code=200 hostname=www.bolha message=unchanged
Feb 24 18:15:02 dns-monitor[1139847]: [2026-02-24T18:15:02] (INFO): [REQ] remote_addr=127.0.0.1:59312 real_ip=2a00:1598:23af:4900:5fe7:c566:dbbd:7b35 host=api.linux-br.org uri=/api/register method=POST user_agent=curl/8.5.0
Feb 24 18:17:27 dns-monitor[1139847]: [2026-02-24T18:17:27] (INFO): [REQ] remote_addr=127.0.0.1:52066 real_ip=2a00:1598:23af:4900::b55 host=api.linux-br.org uri=/api/register method=POST user_agent=curl/8.18.0
Feb 24 18:17:28 dns-monitor[1139847]: [2026-02-24T18:17:28] (INFO): [REQ] remote_addr=127.0.0.1:52074 real_ip=83.233.219.150 host=api.linux-br.org uri=/api/register method=POST user_agent=curl/8.18.0
Feb 24 18:20:01 dns-monitor[1139847]: [2026-02-24T18:20:01] (INFO): [REQ] remote_addr=127.0.0.1:47990 real_ip=83.233.219.150 host=api.linux-br.org uri=/api/register method=POST user_agent=curl/8.5.0
Feb 24 18:20:01 dns-monitor[1139847]: [2026-02-24T18:20:01] (INFO): [RESP] remote_addr=127.0.0.1:47990, real_ip=83.233.219.150 status_code=200 hostname=bolha message=unchanged
Feb 24 18:20:01 dns-monitor[1139847]: [2026-02-24T18:20:01] (INFO): [REQ] remote_addr=127.0.0.1:48006 real_ip=2a00:1598:23af:4900:3e52:82ff:fe62:ff11 host=api.linux-br.org uri=/api/register method=POST user_agent=curl/8.5.0
Feb 24 18:20:01 dns-monitor[1139847]: [2026-02-24T18:20:01] (INFO): trigger update on ipv6
Feb 24 18:20:01 dns-monitor[1139847]: [2026-02-24T18:20:01] (INFO): Updating DNS maps: hostname=www.bolha ip_version=6 ip_address=2a00:1598:23af:4900:3e52:82ff:fe62:ff11
Feb 24 18:20:01 dns-monitor[1139847]: [2026-02-24T18:20:01] (INFO): dns maps to be udpated: [/etc/bind/master/db.truta.org /etc/bind/master/db.linux-br.org]
Feb 24 18:20:01 dns-monitor[1139847]: [2026-02-24T18:20:01] (INFO): updated serial: 2026022400
Feb 24 18:20:01 dns-monitor[1139847]: [2026-02-24T18:20:01] (INFO): updated serial: 2026022400
Feb 24 18:20:01 dns-monitor[1139847]: [2026-02-24T18:20:01] (INFO): dns submap to also be update: /etc/bind/master/dyndns.map
Feb 24 18:20:01 dns-monitor[1139847]: [2026-02-24T18:20:01] (INFO): [RESP] remote_addr=127.0.0.1:48006, real_ip=2a00:1598:23af:4900:3e52:82ff:fe62:ff11 status_code=200 hostname=www.bolha message=IPv6_updated
Feb 24 18:20:01 dns-monitor[1139847]: [2026-02-24T18:20:01] (INFO): restart service named via systemd
Feb 24 18:20:01 dns-monitor[1139847]: [2026-02-24T18:20:01] (INFO): [REQ] remote_addr=127.0.0.1:48010 real_ip=83.233.219.150 host=api.linux-br.org uri=/api/register method=POST user_agent=curl/8.5.0
Feb 24 18:20:01 dns-monitor[1139847]: [2026-02-24T18:20:01] (INFO): [REQ] remote_addr=127.0.0.1:48034 real_ip=83.233.219.150 host=api.linux-br.org uri=/api/register method=POST user_agent=curl/8.5.0
Feb 24 18:20:01 dns-monitor[1139847]: [2026-02-24T18:20:01] (INFO): [REQ] remote_addr=127.0.0.1:48020 real_ip=2a00:1598:23af:4900:3e52:82ff:fe62:ff11 host=api.linux-br.org uri=/api/register method=POST user_agent=curl/8.5.0
Feb 24 18:20:01 dns-monitor[1139847]: [2026-02-24T18:20:01] (INFO): [RESP] remote_addr=127.0.0.1:48034, real_ip=83.233.219.150 status_code=200 hostname=www.bolha message=unchanged
Feb 24 18:20:01 dns-monitor[1139847]: [2026-02-24T18:20:01] (INFO): trigger update on ipv6
Feb 24 18:20:01 dns-monitor[1139847]: [2026-02-24T18:20:01] (INFO): Updating DNS maps: hostname=bolha ip_version=6 ip_address=2a00:1598:23af:4900:3e52:82ff:fe62:ff11
Feb 24 18:20:01 dns-monitor[1139847]: [2026-02-24T18:20:01] (INFO): dns maps to be udpated: [/etc/bind/master/db.truta.org /etc/bind/master/db.linux-br.org]
Feb 24 18:20:01 dns-monitor[1139847]: [2026-02-24T18:20:01] (INFO): updated serial: 2026022401
Feb 24 18:20:01 dns-monitor[1139847]: [2026-02-24T18:20:01] (INFO): updated serial: 2026022401
Feb 24 18:20:01 dns-monitor[1139847]: [2026-02-24T18:20:01] (INFO): [REQ] remote_addr=127.0.0.1:48036 real_ip=2a00:1598:23af:4900:3e52:82ff:fe62:ff11 host=api.linux-br.org uri=/api/register method=POST user_agent=curl/8.5.0
Feb 24 18:20:01 dns-monitor[1139847]: [2026-02-24T18:20:01] (INFO): trigger update on ipv6
Feb 24 18:20:01 dns-monitor[1139847]: [2026-02-24T18:20:01] (INFO): dns submap to also be update: /etc/bind/master/dyndns.map
Feb 24 18:20:01 dns-monitor[1139847]: [2026-02-24T18:20:01] (INFO): dns maps to be udpated: [/etc/bind/master/db.truta.org /etc/bind/master/db.linux-br.org]
Feb 24 18:20:01 dns-monitor[1139847]: [2026-02-24T18:20:01] (INFO): updated serial: 2026022402
Feb 24 18:20:01 dns-monitor[1139847]: [2026-02-24T18:20:01] (INFO): updated serial: 2026022402
Feb 24 18:20:01 dns-monitor[1139847]: [2026-02-24T18:20:01] (INFO): [RESP] remote_addr=127.0.0.1:48020, real_ip=2a00:1598:23af:4900:3e52:82ff:fe62:ff11 status_code=200 hostname=bolha message=IPv6_updated
Feb 24 18:20:01 dns-monitor[1139847]: [2026-02-24T18:20:01] (INFO): restart service named via systemd
Feb 24 18:20:01 dns-monitor[1139847]: [2026-02-24T18:20:01] (INFO): dns submap to also be update: /etc/bind/master/dyndns.map
Feb 24 18:20:01 dns-monitor[1139847]: [2026-02-24T18:20:01] (INFO): restart service named via systemd
Feb 24 18:22:28 dns-monitor[1139847]: [2026-02-24T18:22:28] (INFO): [REQ] remote_addr=127.0.0.1:48738 real_ip=2a00:1598:23af:4900::b55 host=api.linux-br.org uri=/api/register method=POST user_agent=curl/8.18.0
Feb 24 18:22:28 dns-monitor[1139847]: [2026-02-24T18:22:28] (INFO): [REQ] remote_addr=127.0.0.1:48740 real_ip=83.233.219.150 host=api.linux-br.org uri=/api/register method=POST user_agent=curl/8.18.0
Feb 24 18:25:02 dns-monitor[1139847]: [2026-02-24T18:25:02] (INFO): [REQ] remote_addr=127.0.0.1:52456 real_ip=83.233.219.150 host=api.linux-br.org uri=/api/register method=POST user_agent=curl/8.5.0
Feb 24 18:25:02 dns-monitor[1139847]: [2026-02-24T18:25:02] (INFO): [RESP] remote_addr=127.0.0.1:52456, real_ip=83.233.219.150 status_code=200 hostname=bolha message=unchanged
Feb 24 18:25:02 dns-monitor[1139847]: [2026-02-24T18:25:02] (INFO): [REQ] remote_addr=127.0.0.1:52468 real_ip=83.233.219.150 host=api.linux-br.org uri=/api/register method=POST user_agent=curl/8.5.0
Feb 24 18:25:02 dns-monitor[1139847]: [2026-02-24T18:25:02] (INFO): [REQ] remote_addr=127.0.0.1:52476 real_ip=83.233.219.150 host=api.linux-br.org uri=/api/register method=POST user_agent=curl/8.5.0
Feb 24 18:25:02 dns-monitor[1139847]: [2026-02-24T18:25:02] (INFO): [RESP] remote_addr=127.0.0.1:52476, real_ip=83.233.219.150 status_code=200 hostname=www.bolha message=unchanged
Feb 24 18:25:02 dns-monitor[1139847]: [2026-02-24T18:25:02] (INFO): [REQ] remote_addr=127.0.0.1:52482 real_ip=2a00:1598:23af:4900:3e52:82ff:fe62:ff11 host=api.linux-br.org uri=/api/register method=POST user_agent=curl/8.5.0
Feb 24 18:25:02 dns-monitor[1139847]: [2026-02-24T18:25:02] (INFO): [REQ] remote_addr=127.0.0.1:52484 real_ip=2a00:1598:23af:4900:3e52:82ff:fe62:ff11 host=api.linux-br.org uri=/api/register method=POST user_agent=curl/8.5.0
Feb 24 18:25:02 dns-monitor[1139847]: [2026-02-24T18:25:02] (INFO): [RESP] remote_addr=127.0.0.1:52484, real_ip=2a00:1598:23af:4900:3e52:82ff:fe62:ff11 status_code=200 hostname=www.bolha message=unchanged
Feb 24 18:25:02 dns-monitor[1139847]: [2026-02-24T18:25:02] (INFO): [REQ] remote_addr=127.0.0.1:52498 real_ip=2a00:1598:23af:4900:3e52:82ff:fe62:ff11 host=api.linux-br.org uri=/api/register method=POST user_agent=curl/8.5.0
Feb 24 18:25:02 dns-monitor[1139847]: [2026-02-24T18:25:02] (INFO): [RESP] remote_addr=127.0.0.1:52498, real_ip=2a00:1598:23af:4900:3e52:82ff:fe62:ff11 status_code=200 hostname=bolha message=unchanged
Feb 24 18:27:28 dns-monitor[1139847]: [2026-02-24T18:27:28] (INFO): [REQ] remote_addr=127.0.0.1:46772 real_ip=2a00:1598:23af:4900::b55 host=api.linux-br.org uri=/api/register method=POST user_agent=curl/8.18.0
Feb 24 18:27:29 dns-monitor[1139847]: [2026-02-24T18:27:29] (INFO): [REQ] remote_addr=127.0.0.1:46774 real_ip=83.233.219.150 host=api.linux-br.org uri=/api/register method=POST user_agent=curl/8.18.0
Feb 24 18:30:01 dns-monitor[1139847]: [2026-02-24T18:30:01] (INFO): [REQ] remote_addr=127.0.0.1:37288 real_ip=83.233.219.150 host=api.linux-br.org uri=/api/register method=POST user_agent=curl/8.5.0
Feb 24 18:30:01 dns-monitor[1139847]: [2026-02-24T18:30:01] (INFO): [REQ] remote_addr=127.0.0.1:37294 real_ip=83.233.219.150 host=api.linux-br.org uri=/api/register method=POST user_agent=curl/8.5.0
Feb 24 18:30:01 dns-monitor[1139847]: [2026-02-24T18:30:01] (INFO): [RESP] remote_addr=127.0.0.1:37294, real_ip=83.233.219.150 status_code=200 hostname=bolha message=unchanged
Feb 24 18:30:01 dns-monitor[1139847]: [2026-02-24T18:30:01] (INFO): [REQ] remote_addr=127.0.0.1:37302 real_ip=83.233.219.150 host=api.linux-br.org uri=/api/register method=POST user_agent=curl/8.5.0
Ficou mais fácil acompanhar as mudanças e o sistema ficou mais estável.
No servidor eu fiz um reverse proxy no Apache pra chegar no serviço dns-monitor.
Do lado do cliente, eu uso curl, como é possível ver pelos logs com user_agent. Envio algo como isso abaixo mas na crontab a cada 5 minutos:
❯ curl -6 -o /dev/null -s "https://api.linux-br.org/api/register" -d '{"hostname": "bolha", "token": "abcdefgh123456"}'
❯ curl -4 -o /dev/null -s "https://api.linux-br.org/api/register" -d '{"hostname": "bolha", "token": "abcdefgh123456"}'
O sistema está longe de estar perfeito. Roda vários updates no mapa seguidamente se o endereço mudar tanto no IPv4 quanto no IPv6, que aconteceu quando mudei o servidor fisicamente do quarto pra sala. Mas está funcionando e com menos erros que antes.
Quem quiser olhar o código, já esta no Codeberg:
https://codeberg.org/helioloureiro/dns_monitor
Não tem muita descrição, mas está lá e está funcionando em produção.
Nota: depois de tudo isso, o Guto falou que o problema era do lado da bolha.us. Ao menos serviu pra eu sair da inércia e escrever um pouco de Go, o que foi bem divertido.
Nota 2: nenhum código de AI foi usando durante o desenvolvimento desse programa.
E a bolha está de pé. Ou quase isso.
A primeira semana em operação foi erro 502 o tempo todo. Achei que o problema era como estava funcionando pelo systemd. Então criei um serviço novo só pra ela.
# /etc/systemd/user/podman-compose@.service
[Unit]
Description=GoToSocial as container service
StartLimitIntervalSec=0
[Service]
Type=simple
User=helio
Group=helio
#WorkingDirectory=/home/helio/gotosocial
ExecStart=/home/helio/gotosocial/entrypoint.sh start
ExecStop=/home/helio/gotosocial/entrypoint.sh stop
Restart=always
RestartSec=30
[Install]
WantedBy=default.target
Depois achei que era o enviroment.
Comentei a parte de WorkingDirectory, como pode ser visto acima.
Também troquei o podman-compose up por esse script entrypoint.sh.
#! /usr/bin/env bash
GOTOSOCIAL_DIR="/home/helio/gotosocial"
start_gotosocial() {
echo "Starting gotosocial"
cd $GOTOSOCIAL_DIR
/usr/bin/podman pull docker.io/superseriousbusiness/gotosocial:latest
/usr/bin/podman pull docker.io/library/postgres:latest
/usr/bin/podman-compose down
sleep 5
/usr/bin/podman-compose up
}
stop_gotosocial() {
echo "Stopping GoToSocial"
cd $GOTOSOCIAL_DIR
/usr/bin/podman-compose down
}
case $1 in
start) start_gotosocial ;;
stop) stop_gotosocial ;;
restart) $0 stop
sleep 30
$0 start
;;
*) echo "Unknown option: $1"
exit 1
esac
Os podman pull estavam antes no serviço do systemd.
Joguei tudo pra dentro do script.
E o resultado foi: 502.
Então comecei a considerar que tinha feito algo errado no compose.yml.
services:
gotosocial:
image: docker.io/superseriousbusiness/gotosocial:latest
container_name: gotosocial
user: 1000:1000
networks:
- gotosocial
environment:
# Change this to your actual host value.
GTS_HOST: bolha.linux-br.org
GTS_DB_TYPE: postgres
GTS_CONFIG_PATH: /gotosocial/config.yaml
# Path in the GtS Docker container where the
# Wazero compilation cache will be stored.
GTS_WAZERO_COMPILATION_CACHE: /gotosocial/.cache
## For reverse proxy setups:
GTS_TRUSTED_PROXIES: "127.0.0.1,::1,172.18.0.0/16"
## Set the timezone of your server:
TZ: Europe/Stockholm
ports:
- "127.0.0.1:8080:8080"
volumes:
- data:/gotosocial/storage
- cache:/gotosocial/.cache
- ~/gotosocial/config.yaml:/gotosocial/config.yaml
restart: unless-stopped
healthcheck:
test: wget --no-vebose --tries=1 --spider http://localhost:8080/readyz
interval: 10s
retries: 5
start_period: 30s
depends:
- postgres
postgres:
image: docker.io/library/postgres:latest
container_name: postgres
networks:
- gotosocial
environment:
POSTGRES_PASSWORD: *****
POSTGRES_USER: gotosocial
POSTGRES_DB: gotosocial
restart: unless-stopped
volumes:
- ~/gotosocial/postgresql:/var/lib/postgresql
ports:
- "5432:5432"
healthcheck:
test: pg_isready
interval: 10s
timeout: 5s
retries: 5
start_period: 120s
networks:
gotosocial:
ipam:
driver: default
config:
- subnet: "172.18.0.0/16"
gateway: "172.18.0.1"
volumes:
data:
cache:
Nada de muito fantástico. Um postgres rodando junto com um gotosocial. Algumas configurações de proxy, que é o nginx da máquina, e é isso. E continuava o 502.
Mas se eu entrava na máquina, e rodava uma sessão de tmux e dentro dela chamava o podman-compose up,
daí tudo funcionava.
Dei então uma olhada no erro.
Oct 15 10:16:56 mimir entrypoint.sh[1895291]: podman-compose version: 1.0.6
Oct 15 10:16:56 mimir entrypoint.sh[1895291]: ['podman', '--version', '']
Oct 15 10:16:56 mimir entrypoint.sh[1895291]: using podman version: 4.9.3
Oct 15 10:16:56 mimir entrypoint.sh[1895291]: ** excluding: set()
Oct 15 10:16:56 mimir entrypoint.sh[1895291]: ['podman', 'ps', '--filter', 'label=io.podman.compose.project=gotosocial', '-a', '--format', '{{ index .Labels "io.podman.compose.config-hash"}}']
Oct 15 10:16:56 mimir entrypoint.sh[1895303]: time="2025-10-15T10:16:56+02:00" level=warning msg="RunRoot is pointing to a path (/run/user/1000/containers) which is not writable. Most likely podman will fail."
Oct 15 10:16:56 mimir entrypoint.sh[1895303]: Error: default OCI runtime "crun" not found: invalid argument
Oct 15 10:16:57 mimir entrypoint.sh[1895291]: Traceback (most recent call last):
Oct 15 10:16:57 mimir entrypoint.sh[1895291]: File "/usr/bin/podman-compose", line 33, in
Oct 15 10:16:57 mimir entrypoint.sh[1895291]: sys.exit(load_entry_point('podman-compose==1.0.6', 'console_scripts', 'podman-compose')())
Oct 15 10:16:57 mimir entrypoint.sh[1895291]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Oct 15 10:16:57 mimir entrypoint.sh[1895291]: File "/usr/lib/python3/dist-packages/podman_compose.py", line 2941, in main
Oct 15 10:16:57 mimir entrypoint.sh[1895291]: podman_compose.run()
Oct 15 10:16:57 mimir entrypoint.sh[1895291]: File "/usr/lib/python3/dist-packages/podman_compose.py", line 1423, in run
Oct 15 10:16:57 mimir entrypoint.sh[1895291]: cmd(self, args)
Oct 15 10:16:57 mimir entrypoint.sh[1895291]: File "/usr/lib/python3/dist-packages/podman_compose.py", line 1754, in wrapped
Oct 15 10:16:57 mimir entrypoint.sh[1895291]: return func(*args, **kw)
Oct 15 10:16:57 mimir entrypoint.sh[1895291]: ^^^^^^^^^^^^^^^^^
Oct 15 10:16:57 mimir entrypoint.sh[1895291]: File "/usr/lib/python3/dist-packages/podman_compose.py", line 2038, in compose_up
Oct 15 10:16:57 mimir entrypoint.sh[1895291]: compose.podman.output(
Oct 15 10:16:57 mimir entrypoint.sh[1895291]: File "/usr/lib/python3/dist-packages/podman_compose.py", line 1098, in output
Oct 15 10:16:57 mimir entrypoint.sh[1895291]: return subprocess.check_output(cmd_ls)
Oct 15 10:16:57 mimir entrypoint.sh[1895291]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Oct 15 10:16:57 mimir entrypoint.sh[1895291]: File "/usr/lib/python3.12/subprocess.py", line 466, in check_output
Oct 15 10:16:57 mimir entrypoint.sh[1895291]: return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
Oct 15 10:16:57 mimir entrypoint.sh[1895291]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Oct 15 10:16:57 mimir entrypoint.sh[1895291]: File "/usr/lib/python3.12/subprocess.py", line 571, in run
Oct 15 10:16:57 mimir entrypoint.sh[1895291]: raise CalledProcessError(retcode, process.args,
Oct 15 10:16:57 mimir entrypoint.sh[1895291]: subprocess.CalledProcessError: Command '['podman', 'ps', '--filter', 'label=io.podman.compose.project=gotosocial', '-a', '--format', '{{ index .Labels "io.podman.compose.config-hash"}}']' returned non-zero exit status 125.
Oct 15 10:16:57 mimir systemd[1]: gotosocial.service: Main process exited, code=exited, status=1/FAILURE
Oct 15 10:16:57 mimir systemd[1]: gotosocial.service: Failed with result 'exit-code'.
Oct 15 10:16:57 mimir systemd[1]: gotosocial.service: Consumed 1.481s CPU time.
Oct 15 10:17:27 mimir systemd[1]: gotosocial.service: Scheduled restart job, restart counter is at 1280.
Oct 15 10:17:27 mimir systemd[1]: Started gotosocial.service - GoToSocial as container service.
Oct 15 10:17:27 mimir entrypoint.sh[1895707]: Starting gotosocial
Oct 15 10:17:30 mimir entrypoint.sh[1895781]: podman-compose version: 1.0.6
Oct 15 10:17:30 mimir entrypoint.sh[1895781]: ['podman', '--version', '']
Oct 15 10:17:30 mimir entrypoint.sh[1895781]: using podman version: 4.9.3
Oct 15 10:17:30 mimir entrypoint.sh[1895781]: ** excluding: set()
Oct 15 10:17:30 mimir entrypoint.sh[1895781]: podman stop -t 10 postgres
Oct 15 10:17:31 mimir entrypoint.sh[1895781]: exit code: 0
Oct 15 10:17:31 mimir entrypoint.sh[1895781]: podman stop -t 10 gotosocial
Oct 15 10:17:31 mimir entrypoint.sh[1895781]: exit code: 0
Oct 15 10:17:31 mimir entrypoint.sh[1895781]: podman rm postgres
Oct 15 10:17:31 mimir entrypoint.sh[1895781]: exit code: 0
Oct 15 10:17:31 mimir entrypoint.sh[1895781]: podman rm gotosocial
Oct 15 10:17:31 mimir entrypoint.sh[1895781]: exit code: 0
Oct 15 10:17:36 mimir entrypoint.sh[1895920]: podman-compose version: 1.0.6
Oct 15 10:17:36 mimir entrypoint.sh[1895920]: ['podman', '--version', '']
Oct 15 10:17:36 mimir entrypoint.sh[1895920]: using podman version: 4.9.3
Oct 15 10:17:36 mimir entrypoint.sh[1895920]: ** excluding: set()
Oct 15 10:17:36 mimir entrypoint.sh[1895920]: ['podman', 'ps', '--filter', 'label=io.podman.compose.project=gotosocial', '-a', '--format', '{{ index .Labels "io.podman.compose.config-hash"}}']
Oct 15 10:17:36 mimir entrypoint.sh[1895920]: podman volume inspect gotosocial_data || podman volume create gotosocial_data
Oct 15 10:17:36 mimir entrypoint.sh[1895920]: ['podman', 'volume', 'inspect', 'gotosocial_data']
Oct 15 10:17:36 mimir entrypoint.sh[1895920]: podman volume inspect gotosocial_cache || podman volume create gotosocial_cache
Oct 15 10:17:36 mimir entrypoint.sh[1895920]: ['podman', 'volume', 'inspect', 'gotosocial_cache']
Oct 15 10:17:36 mimir entrypoint.sh[1895920]: ['podman', 'network', 'exists', 'gotosocial_gotosocial']
Oct 15 10:17:36 mimir entrypoint.sh[1895920]: podman create --name=gotosocial --label io.podman.compose.config-hash=4f4b10e0c67c04b7b4f2392784b378735d4378d9d411f1405cf3819c6207bd1a --label io.podman.compose.project=gotosocial --label io.podman.compose.version=1.0.6 --label PODMAN_SYSTEMD_UNIT=This email address is being protected from spambots. You need JavaScript enabled to view it. --label com.docker.compose.project=gotosocial --label com.docker.compose.project.working_dir=/home/helio/gotosocial --label com.docker.compose.project.config_files=compose.yaml --label com.docker.compose.container-number=1 --label com.docker.compose.service=gotosocial -e GTS_HOST=bolha.linux-br.org -e GTS_DB_TYPE=postgres -e GTS_CONFIG_PATH=/gotosocial/config.yaml -e GTS_WAZERO_COMPILATION_CACHE=/gotosocial/.cache -e GTS_TRUSTED_PROXIES=127.0.0.1,::1,172.18.0.0/16 -e TZ=Europe/Stockholm -v gotosocial_data:/gotosocial/storage -v gotosocial_cache:/gotosocial/.cache -v /home/helio/gotosocial/config.yaml:/gotosocial/config.yaml --net gotosocial_gotosocial --network-alias gotosocial -p 127.0.0.1:8080:8080 -u 1000:1000 --restart unless-stopped --healthcheck-command /bin/sh -c 'wget --no-vebose --tries=1 --spider http://localhost:8080/readyz' --healthcheck-interval 10s --healthcheck-start-period 30s --healthcheck-retries 5 docker.io/superseriousbusiness/gotosocial:latest
Oct 15 10:17:36 mimir entrypoint.sh[1895920]: exit code: 0
A parte final, com podman create, é o systemd reiniciando o serviço.
O problema está on início, onde há um crash de python:
subprocess.CalledProcessError: Command '['podman', 'ps', '--filter', 'label=io.podman.compose.project=gotosocial', '-a', '--format', '{{ index .Labels "io.podman.compose.config-hash"}}']' returned non-zero exit status 125.
Eu entrava na máquina e rodava o comando pra ver o resultado:
❯ podman ps --filter 'label=io.podman.compose.project=gotosocial' -a --format '{{ index .Labels "io.podman.compose.config-hash"}}'
4f4b10e0c67c04b7b4f2392784b378735d4378d9d411f1405cf3819c6207bd1a
4f4b10e0c67c04b7b4f2392784b378735d4378d9d411f1405cf3819c6207bd1a
E mostrava os containers rodando (porque tinha sido reiniciados pelo systemd). Eu ficava com aquela cara de "ué!?".
No início do erro, tem essa outra mensagem aqui:
Error: default OCI runtime "crun" not found: invalid argument
.
Então fui olhar se era algum problema nesse crun.
E está instalado (acho que veio como dependência do podman.
❯ which crun
/usr/bin/crun
❯ dpkg -S /usr/bin/crun
crun: /usr/bin/crun
Busquei sobre erros do GoToSocial mesmo. E nada.
Olhando pra todo lado tentando descobrir o que poderia ser, reparei em outro erro:
msg="RunRoot is pointing to a path (/run/user/1000/containers) which is not writable. Most likely podman will fail."
.
Isso soou promissor.
Então de repente o pointing path não estava disponível pra escrita.
Poderia ser... systemd?
Com isso eu comecei a buscar algo relacionado com timeout ou user logout.
Acabei encontrando o artigo abaixo:
Nesse artigo alguém comenta que pode ser uma opção de container linger.
Segui a referência que tinha sobre isso.
loginctl?
Faz até sentido isso.
Mas o podman não deveria descrever isso na documentação?
Então fui buscar e achei isso aqui:
Pra deixar bem ilustrado onde aparece a referência de linger na documentação:
Algo que é vital pra funcionar como serviço aparece como... exemplo??? Os caras tão de brincation uite me.
Mas no fim era isso mesmo.
Bastou um sudo logictl enable-user helio pra ter o container rodando depois que eu saio da sessão.
Se eu tivesse decido rodar com docker compose, eu provavelmente não teria o mesmo problema uma vez que roda com o privilégio de root.
Então fica mais essa lição aqui.
E mesmo tendo lendo a documentação, sempre aparecem alguns pontos que a porra da documentação só dá um peteleco em cima e dentro dos exemplos ainda por cima.
Mas está funcionando. Minha bolha, bolha minha.
