Como hospedar um conversor de arquivos com HRConvert2

Por que hospedar o seu próprio conversor de arquivos

Um conversor de arquivos hospedado por você mantém o arquivo no seu próprio disco. Esse é o motivo principal para executá-lo. Um site de conversão gratuito recebe o upload e não oferece nenhuma forma de saber o que aconteceu com o arquivo depois disso. Quando o arquivo é um contrato assinado de um cliente ou um prontuário médico digitalizado, o próprio upload já constitui o incidente. O HRConvert2 é um servidor de conversão de arquivos com suporte a arrastar e soltar, escrito em PHP e licenciado sob a GPLv3. A versão 3.7.4 foi lançada em 18 August 2026, e o projeto declara oferecer suporte a 488 formatos.

Ele não tem banco de dados, contas nem cookies. Cada usuário corresponde a um diretório temporário. Cada conversão é executada por uma ferramenta local de linha de comando: LibreOffice para documentos, FFmpeg para áudio e vídeo, ImageMagick para imagens, Tesseract para reconhecimento óptico de caracteres (OCR) e várias outras ferramentas menores para os demais formatos. O HRConvert2 fornece a página de upload, o pipeline e a limpeza desses componentes.

Ele converte um arquivo de um formato para outro. Não é uma suíte de escritório no navegador. Se o objetivo é permitir que as pessoas editem documentos em uma aba, compare OnlyOffice e Collabora hospedados por você. Ele também não é um sistema de armazenamento. O resultado convertido deve ser excluído. Se os arquivos precisarem permanecer armazenados, essa função deve ser desempenhada por um gerenciador de arquivos hospedado por você.

O que é necessário

Debian ou Ubuntu, Apache 2.4, PHP 8 ou posterior e bubblewrap. O bubblewrap (bwrap) é o sandbox e é obrigatório: um servidor que não consiga criar um sandbox recusa a conversão em vez de executá-la sem isolamento. O README do projeto upstream indica que um Raspberry Pi Model B+ é suficiente, o que é verdade para a parte do PHP. Os binários do conversor determinam os requisitos reais de hardware, e isso é explicado mais abaixo.

Há duas formas de começar. A imagem Docker funciona ainda hoje. A instalação do Apache e do PHP demora uma tarde e mostra exatamente o que está instalado no servidor.

Execute hoje à noite com Docker

A imagem inclui todos os binários de conversão, por isso é grande: cerca de 3 GB em agosto de 2026. Verifique o espaço livre em disco antes de a descarregar.

As tags são importantes neste caso. A tag mais recente publicada no Docker Hub em 17 August 2026 é v3.7.2, enquanto a versão mais recente no GitHub é v3.7.4. A tag latest muda sem aviso, e esta aplicação tem uma grande superfície de análise, por isso fixe uma versão e faça as atualizações deliberadamente.

docker pull zelon88/hrconvert2:v3.7.2
docker run -d --name hrconvert2 \
  -p 127.0.0.1:8080:80 \
  --security-opt seccomp=unconfined \
  zelon88/hrconvert2:v3.7.2

docker ps
curl -I http://127.0.0.1:8080/

Um contentor em bom estado permanece no estado Up e curl devolve HTTP/1.1 200 OK. Um contentor que reinicia continuamente tem um problema no arranque, por isso consulte docker logs hrconvert2 antes de alterar qualquer outra coisa.

Duas flags são especialmente importantes. -p 127.0.0.1:8080:80 publica a porta apenas na interface de loopback, por isso nada chega ao conversor até colocar deliberadamente um proxy à frente dele. O exemplo do projeto mapeia -p 8080:80 -p 8443:443, que escuta em todas as interfaces, incluindo a interface pública. --security-opt seccomp=unconfined é necessário porque o bubblewrap cria a sua sandbox utilizando chamadas de sistema de user namespace e mount que o perfil seccomp predefinido do Docker bloqueia. Sem esta flag, as conversões falham e a aplicação explica o motivo: A sandbox blocks the required syscalls unless it was started with the correct options.

Esta flag implica uma compensação real. Relaxa o filtro de chamadas de sistema do contentor para que a aplicação possa criar uma sandbox mais restritiva dentro dele. As duas definições que determinam o comportamento são $RequireSandbox e $RequireSandboxOnDocker em Resources/config.php, que têm como valores predefinidos TRUE e FALSE. Como o requisito do Docker está desativado por predefinição, um contentor sem a flag seccomp pode converter sem qualquer sandbox. Depois de adicionar a flag, defina $RequireSandboxOnDocker = TRUE; para recuperar o comportamento de recusa dentro do contentor.

Se o Docker for novo nesta máquina, configure primeiro o daemon. Executar o Docker num VPS explica a instalação, o controlador de armazenamento e a forma como o Docker escreve as suas próprias regras de firewall.

Instale-o no Apache e no PHP

O ficheiro Documentation/INSTALLATION_INSTRUCTIONS.txt no repositório é a referência oficial e contém nove passos. Esta é a estrutura. Comece pelo servidor Web, pela linguagem e pelo sandbox:

sudo apt update
sudo apt install -y apache2 php libapache2-mod-php php-all-dev php8.3-zip php8.3-gd bubblewrap

Os nomes php8.3-* correspondem ao Ubuntu 24.04. Execute php -v e use o prefixo correspondente à sua versão, porque esses nomes de pacotes mudam a cada versão do PHP e o nome errado produz Unable to locate package.

Depois, os conversores. Isto abrange documentos, imagens, áudio, vídeo e OCR, que representam a maior parte das conversões realizadas:

sudo apt install -y imagemagick ffmpeg libreoffice-common libreoffice-java-common \
  default-jre ghostscript poppler-utils libgxps-utils tesseract-ocr inkscape \
  xvfb clamav curl tar libxcb-cursor0

Formatos de arquivo, modelos 3D, ebooks e imagens ISO inicializáveis precisam de mais pacotes, e alguns estão no componente multiverse do Ubuntu. Os passos 3 e 5 das instruções oficiais contêm a lista completa, pela ordem correta. Duas dependências não são pacotes apt: o repositório disponibiliza Documentation/Build/ffmpeg-build.sh e Documentation/Build/build-imagemagick-v7.sh para quem precisa de codificadores ou de uma versão 7 do ImageMagick que o Ubuntu não empacota. O suporte a ebooks vem do instalador próprio do calibre, fornecido nas instruções como uma única linha:

sudo -v && wget -nv -O- https://download.calibre-ebook.com/linux-installer.sh | sudo sh /dev/stdin

Este é um script do fornecedor redirecionado para um shell como root. É o método do projeto upstream e é opcional: se o ignorar, a única funcionalidade perdida será a conversão de ebooks.

A seguir, os limites do PHP. As conversões são lentas e os ficheiros são grandes, portanto os valores predefinidos são demasiado baixos. O projeto define estes valores em php.ini:

max_execution_time = 1200
max_input_time = 90
memory_limit = 512M
post_max_size = 5000M
upload_max_filesize = 5000M
max_file_uploads = 100
display_errors = Off
zlib.output_compression = On

Estes números pressupõem uma máquina com recursos disponíveis. Reduza-os antes de os utilizar num VPS pequeno, porque upload_max_filesize = 5000M com max_file_uploads = 100 descreve um único pedido que pode escrever muito mais dados do que um disco de 40 GB comporta. Reinicie o Apache e confirme o que o PHP carregou efetivamente:

sudo service apache2 restart
php -i | grep -E "upload_max_filesize|post_max_size|memory_limit"

Agora, o diretório de trabalho. $ConvertLoc em Resources/config.php define esse diretório, cujo valor predefinido é /DATA/HRConvert2. O utilizador do servidor Web tem de ser o proprietário:

sudo mkdir -p /DATA/HRConvert2
sudo chmod -R 0755 /DATA/HRConvert2
sudo chown -R www-data:www-data /DATA/HRConvert2

Extraia o release na raiz de documentos do Apache. A disposição predefinida coloca-o numa pasta HRProprietary/HRConvert2, e $InstLoc em Resources/config.php tem de indicar o local onde o colocou efetivamente. Em seguida, execute o diagnóstico incorporado. É a forma mais rápida de encontrar uma dependência em falta antes que um utilizador a encontre:

sudo php /path/to/HRConvert2/convertCore.php -v

-v verifica toda a instalação: versões do núcleo, dependências, estado do sandbox e pacotes de idiomas. As conversões de ficheiros não são suportadas pela linha de comandos, portanto este conjunto de argumentos serve apenas para tarefas administrativas.

Por que todas as conversões falham numa instalação nova do Ubuntu 24.04?

Por causa da sandbox. Este é o problema inicial mais comum. O Ubuntu 24.04 e o Debian 12 restringem os user namespaces de utilizadores sem privilégios por predefinição. O Bubblewrap precisa de um user namespace para criar a sua sandbox. Por isso, bwrap não consegue iniciar. Como a aplicação não faz conversões sem uma sandbox, todos os trabalhos falham.

Verifique diretamente:

bwrap --ro-bind / / --dev /dev /bin/true && echo sandbox ok

Um erro de permissão negada significa que o namespace foi bloqueado. A correção consiste em criar um perfil AppArmor para o binário bwrap. Primeiro, liste os ficheiros ABI e anote o número mais alto disponível:

ls /etc/apparmor.d/abi/

Depois, escreva /etc/apparmor.d/bwrap, substituindo 4.0 pelo número mais alto:

abi <abi/4.0>,
include <tunables/global>

profile bwrap /usr/bin/bwrap flags=(unconfined) {
  userns,
  include if exists <local/bwrap>
}

Carregue-o:

sudo apparmor_parser -r /etc/apparmor.d/bwrap

A ausência de saída significa que o perfil foi carregado. Execute novamente a verificação bwrap. Ela deverá apresentar sandbox ok. A partir desse momento, as conversões funcionam.

Um conversor público é um parser exposto a desconhecidos

Esta é a razão de existir do restante do artigo. Um conversor de ficheiros acessível pela Internet aceita um ficheiro arbitrário de uma pessoa anónima e entrega-o ao LibreOffice, ImageMagick, FFmpeg ou Ghostscript. Estes são grandes conjuntos de código C e C++ com um longo historial de erros em parsers. A pessoa que faz o upload escolhe o formato. Isso significa que também escolhe qual parser é executado e qual caminho de código é seguido.

A resposta do HRConvert2 é executar cada dependência dentro de um namespace do bubblewrap. Cada conversão vê dois diretórios: o diretório que contém a entrada, montado como só de leitura, e o diretório que recebe a saída. A rede não é partilhada. Nas palavras do projeto, closes every URL handler in every dependency at once. Isto é mais importante do que parece. O ImageMagick e o Ghostscript aceitam referências que fazem o fetch de um URL. É assim que um conversor se transforma numa ferramenta de server-side request forgery (SSRF) para alcançar um endpoint de metadados da cloud a partir da sua rede. Sem rede no namespace, o fetch não pode ocorrer.

A recusa é a outra metade: A server that cannot build a sandbox refuses the conversion rather than quietly running without one. Uma ferramenta que falha de forma segura vale mais do que uma ferramenta que apresenta um aviso num log que ninguém lê. É também por isso que o passo do AppArmor acima não é opcional e que $RequireSandboxOnDocker merece ser analisado antes de expor o container.

Fortaleça o ImageMagick com policy.xml

O ficheiro de política do próprio ImageMagick é uma segunda camada sob o sandbox e vale a pena configurá-lo. No Ubuntu 24.04 com ImageMagick 6, o ficheiro é /etc/ImageMagick-6/policy.xml. Mostre o que está ativo atualmente:

identify -list policy

O projeto fornece uma política em Documentation/Build/policy.xml, que é um bom modelo. Ela nega os coders PS, PS2, PS3, EPS, XPS e MVG, e nega os delegates URL, HTTPS, HTTP e gs, permitindo PDF:

<policy domain="coder" rights="none" pattern="PS" />
<policy domain="coder" rights="none" pattern="MVG" />
<policy domain="delegate" rights="none" pattern="URL" />
<policy domain="delegate" rights="none" pattern="gs" />
<policy domain="coder" rights="read|write" pattern="PDF" />

A linha gs é a mais importante. O ImageMagick não interpreta PostScript diretamente. Ele executa o Ghostscript como um processo externo, e é nesse delegate que existem as conhecidas vulnerabilidades de execução remota de código do ImageMagick. Negue o delegate e o ImageMagick não entregará o ficheiro enviado ao gs, independentemente do tipo declarado pelo ficheiro.

A mesma política define limites de recursos. Assim, uma única imagem criada para esse fim não consegue consumir toda a máquina:

<policy domain="resource" name="memory" value="256MiB"/>
<policy domain="resource" name="map" value="512MiB"/>
<policy domain="resource" name="disk" value="1GiB"/>
<policy domain="resource" name="width" value="16KP"/>
<policy domain="resource" name="height" value="16KP"/>
<policy domain="resource" name="area" value="128MP"/>

Uma bomba de descompressão é um ficheiro pequeno que declara dimensões enormes. Os limites width, height e area recusam o ficheiro antes da alocação. Dessa forma, o processo termina em vez de o kernel matar outro processo.

Existe uma armadilha no sentido contrário. A política padrão do Ubuntu nega diretamente o coder PDF. Por isso, num sistema sem alterações, o processamento de PDF falha com attempt to perform an operation not allowed by the security policy 'PDF'. Essa mensagem indica que a política está a funcionar. Permitir novamente o coder é uma decisão deliberada. Ao fazê-lo, mantenha o delegate gs negado.

O custo da cadeia de dependências num VPS pequeno

Em estado ocioso, nada disto é dispendioso. O Apache e o PHP ocupam algumas dezenas de megabytes, e os binários de conversão nem sequer estão em execução. Todo o custo surge de uma vez, quando chega um ficheiro.

A conversão de um documento inicia o LibreOffice, que inicia um runtime Java. A conversão de uma imagem atribui ao ImageMagick 256 MiB de memória e um mapa de memória de 512 MiB ao abrigo da política acima. A conversão de um vídeo atribui ao FFmpeg todos os cores disponíveis, porque é assim que o FFmpeg processa um vídeo. O memory_limit do próprio PHP está definido como 512M na configuração do projeto. Estes valores acumulam-se durante uma única tarefa, além da memória usada pelo sistema operativo e pelo servidor Web.

Por isso, um VPS com 1 GB começa a usar swap no primeiro documento real e depois entra em thrashing. Quando a memória esgota, o OOM killer do kernel termina o processo com o maior tamanho residente. Normalmente, esse processo é o soffice.bin, e o utilizador vê uma conversão que falhou sem uma mensagem útil. Por vezes, é o apache2, e todo o site fica indisponível. Confirme o que aconteceu posteriormente com dmesg -T | grep -i "killed process".

Isto é uma orientação de dimensionamento, não um benchmark: 4 GB de RAM e dois cores são suficientes para uma equipa pequena, e 2 GB com um ficheiro de swap funcionam se a carga consistir em documentos e imagens e aceitar o tempo de espera. Um ficheiro de swap não torna uma conversão mais rápida. Faz com que um pico de carga seja lento em vez de fatal, o que corresponde à diferença entre uma página bloqueada e uma indisponibilidade. Reserve mais espaço em disco do que parece necessário, porque a imagem de 3 GB, um limite de upload elevado e o resultado convertido ocupam todo o disco muito antes de esgotar qualquer outro recurso.

As conversões são naturalmente irregulares. Duas pessoas a carregar vídeos ao mesmo tempo utilizam todos os cores, e o pedido seguinte fica à espera. Não existe uma fila de tarefas à frente deste processo, por isso o único controlo disponível são os limites.

Defina limites para impedir que um único upload encha o disco

Comece por reduzir os valores do PHP. Algo como upload_max_filesize = 512M, post_max_size = 512M e max_file_uploads = 20 é um ponto de partida razoável para um servidor partilhado com 4 GB. Tenha em atenção que max_execution_time = 1200 permite que um pedido PHP seja executado durante vinte minutos. Isso é realmente necessário para uma conversão de vídeo longa, mas também significa que um upload lento mantém um worker ocupado durante vinte minutos.

Depois, imponha o tamanho e a taxa no proxy, antes de o pedido chegar ao PHP:

limit_req_zone $binary_remote_addr zone=convert:10m rate=6r/m;

server {
    listen 443 ssl;
    server_name convert.example.com;

    client_max_body_size 512M;
    client_body_timeout 300s;

    location / {
        limit_req zone=convert burst=4 nodelay;
        proxy_pass http://127.0.0.1:8080;
        proxy_read_timeout 1200s;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

client_max_body_size tem de ser pelo menos igual ao maior ficheiro que pretende converter. Caso contrário, o nginx responde com 413 Request Entity Too Large e o PHP nunca recebe o upload. proxy_read_timeout tem de ser superior à sua conversão mais longa. Caso contrário, um job que esteja a executar corretamente atrás do proxy devolve 504 Gateway Time-out ao browser. O restante desse server block, incluindo a terminação TLS (transport layer security), é explicado em uma configuração de reverse proxy nginx explicada linha a linha.

Eliminar os ficheiros convertidos

Cada conversão deixa uma cópia de um ficheiro sensível num diretório que o servidor Web consegue ler. A limpeza é o que distingue um conversor de um arquivo com tudo o que alguém já converteu nele.

$DeleteThreshold em Resources/config.php é a idade, em minutos, após a qual uma sessão expira, e o valor predefinido é 60. Reduza-a para 15 quando o conteúdo for sensível. A própria limpeza é um argumento da linha de comandos do núcleo:

sudo -u www-data php /path/to/HRConvert2/convertCore.php -c
sudo -u www-data php /path/to/HRConvert2/convertCore.php -c=15

-c limpa as sessões expiradas nas duas localizações de dados, usando o limite configurado. -c=15 usa quinze minutos apenas nessa execução. -c=now elimina todas as sessões, independentemente da idade, incluindo a sessão que um utilizador esteja a usar para converter um ficheiro nesse momento, por isso reserve-o para manutenção. Os mesmos argumentos funcionam dentro do contentor através de docker exec.

Agende a limpeza com um temporizador para que nunca dependa de alguém carregar uma página. Uma linha em /etc/cron.d/hrconvert2 é suficiente:

*/10 * * * * www-data php /path/to/HRConvert2/convertCore.php -c

Verifique alguns minutos depois com ls /DATA/HRConvert2 e monitorize o desaparecimento dos diretórios de sessões antigos. Como o utilizador do servidor Web é proprietário desse diretório, essa conta teria exatamente os privilégios que um analisador explorado obteria. Por isso, não deve ser proprietária de mais nada que seja importante. Contas de utilizador com privilégios mínimos num VPS apresenta o padrão geral, que se aplica ainda mais neste caso.

Coloque-o atrás de autenticação, a menos que o objetivo seja torná-lo público

A instalação padrão não tem contas, por conceção. Qualquer pessoa que consiga aceder à página pode carregar um ficheiro e executar os seus binários de conversão. Os limites de taxa apenas atrasam essa atividade. Por isso, determine em que situação se encontra.

Se for para si e para alguns colegas, não o exponha de forma alguma. Vincule o contentor ao loopback, como mostrado acima, e aceda a ele através de uma rede privada ou de um túnel SSH. Nada na Internet pública poderá enviar-lhe um ficheiro. Isso elimina toda a superfície de ataque, em vez de apenas a filtrar.

Se tiver de estar acessível a partir de um navegador, coloque a autenticação à frente do proxy. A autenticação básica requer dois comandos e mantém o formulário de carregamento longe de desconhecidos:

sudo apt install -y apache2-utils
sudo htpasswd -c /etc/nginx/.htpasswd alice

location / {
    auth_basic "Converter";
    auth_basic_user_file /etc/nginx/.htpasswd;
    proxy_pass http://127.0.0.1:8080;
}

Recarregue o nginx e carregue a página. Um pedido de autenticação significa que está a funcionar. A ausência de pedido significa que o bloco location que editou não é o que está a processar o pedido. Para utilizar contas reais em vez de uma palavra-passe partilhada, termine a autenticação num fornecedor de início de sessão único: um servidor SSO Authentik autoalojado fornece autenticação de encaminhamento à frente de uma aplicação que não tem autenticação própria.

Se o objetivo for um conversor verdadeiramente público, aceite as implicações e planeie em conformidade. Parta do princípio de que a sandbox será sondada. Mantenha a tag da imagem fixada, mantenha a política do ImageMagick restritiva, mantenha baixos os limites de carregamento e execute-o numa VPS que não aloje mais nada de importante.

Modos de falha e as mensagens que verá

Todas as conversões falham imediatamente. Não é possível criar o sandbox. Numa instalação normal, a causa é o perfil AppArmor. No Docker, é o --security-opt seccomp=unconfined em falta. A aplicação indica-o: A sandbox blocks the required syscalls unless it was started with the correct options. e aponta para See --Require Sandbox-- & --Require Sandbox On Docker-- in config.php.

Apenas as conversões de imagens falham. Bubblewrap is missing or non functional, so this image conversion cannot be isolated! significa que bwrap está ausente ou não está acessível no PATH disponível para o utilizador do servidor Web.

Um formato falha e os restantes funcionam. Trata-se de um binário em falta, indicado claramente por: ImageMagick may not be installed, or may not be reachable on the system path used by the web server user. A mesma mensagem existe para FFmpeg e LibreOffice. Execute convertCore.php -v para ver o que a instalação consegue localizar e lembre-se de que o PATH do processo do Apache não é o PATH da sua shell de login.

O processamento de PDF falha com um erro de política. attempt to perform an operation not allowed by the security policy 'PDF' vem do policy.xml do ImageMagick, não do HRConvert2.

Os uploads grandes devolvem 413. O client_max_body_size do nginx é inferior ao tamanho do ficheiro. Existem três limites na cadeia: um no nginx e dois no PHP. Prevalece o menor.

As conversões param e nada parece ter mudado. The device where data is stored has an insufficient amount of storage space available. Verifique o espaço livre e confirme que a limpeza periódica está realmente a ser executada.

A limpeza gera mensagens no log. Could not clean the temporary location! e Could not clean the convert location! são problemas de propriedade. O utilizador do servidor Web tem de ser o proprietário do diretório indicado por $ConvertLoc.

FAQ

É seguro expor um conversor de ficheiros autoalojado à Internet?

É suficientemente seguro apenas se o tratar como um analisador exposto a desconhecidos. Cada carregamento é entregue ao LibreOffice, ImageMagick, FFmpeg ou Ghostscript, e a pessoa que faz o carregamento escolhe qual deles será usado. O HRConvert2 executa essas ferramentas dentro de um namespace do bubblewrap sem rede e com um diretório de entrada apenas para leitura. Também recusa qualquer conversão que não consiga colocar numa sandbox, o que é uma predefinição robusta. Ainda assim, é preferível exigir autenticação, manter os limites de carregamento baixos e executá-lo num VPS que não contenha mais nada de valor.

Porque falha todas as conversões numa instalação nova do Ubuntu 24.04?

O Ubuntu 24.04 e o Debian 12 restringem os user namespaces não privilegiados, e o bubblewrap precisa de um para criar a sandbox. Como a aplicação recusa converter sem uma sandbox, todos os trabalhos falham em vez de apenas alguns. Escreva um perfil AppArmor para /usr/bin/bwrap com flags=(unconfined), carregue-o com sudo apparmor_parser -r /etc/apparmor.d/bwrap e confirme com bwrap --ro-bind / / --dev /dev /bin/true.

Porque falham as conversões no Docker, mas funcionam numa instalação normal?

O perfil seccomp predefinido do Docker bloqueia as chamadas de sistema usadas pelo bubblewrap, pelo que a sandbox não pode ser criada dentro do contentor. Inicie-o com --security-opt seccomp=unconfined, que é o comando de execução usado pelo próprio projeto. Tenha em atenção que $RequireSandboxOnDocker é FALSE por predefinição, pelo que um contentor sem essa flag pode converter sem qualquer sandbox. Defina-o como TRUE depois de ativar a flag seccomp.

De quanta RAM precisa um servidor de conversão de ficheiros?

Em repouso, o consumo é baixo, mas uma conversão em execução não é. O LibreOffice inicia um runtime Java, o ImageMagick usa 256 MiB de memória e um mapa de 512 MiB segundo a política fornecida, e o limite do próprio PHP é 512M. Num VPS com 1 GB, essa combinação começa a usar swap e o out of memory killer termina soffice.bin ou apache2. Conte com 4 GB e dois cores para uma equipa pequena e verifique dmesg -T | grep -i "killed process" sempre que uma conversão terminar sem mensagem.

Para onde vão os ficheiros convertidos e quando são eliminados?

Vão para o diretório de trabalho indicado por $ConvertLoc em Resources/config.php, que por predefinição é /DATA/HRConvert2. $DeleteThreshold define a idade, em minutos, a partir da qual uma sessão expira, e o valor predefinido é 60. A limpeza é executada na linha de comandos: php convertCore.php -c elimina as sessões expiradas e -c=now elimina imediatamente todas as sessões, incluindo as ativas. Coloque -c numa entrada do cron ou num temporizador do systemd para que a eliminação não dependa de alguém visitar o site.