Caixa Seca

Havia um antigo post aqui no blog, lá dos primórdios, não recomendando partição swap. Com a popularização dos arquivos de swap, o texto foi expandido, aceitando-os a contra gosto. Só que isso foi antes de tecnologias recentes do Linux, que resolveram problemas associados ao uso de swap: melhorias no kernel e, principalmente, daemons que monitoram informações de pressão de memória, E/S e CPU do kernel ( Pressure Stall Information , PSI, disponível a partir da versão 4.20) e agem antes . O mais usado é o systemd-oomd [1] . Para ser eficiente em instalações desktop, precisa que os aplicativos sejam postos cada um num cgroup diferente , o que é feito via systemd --user pelo GNOME e KDE. Em ambientes que não o façam, como o XFCE, não é recomendado habilitá-lo. Mesmo assim, o kernel não é mais tão burro como antigamente . Minha restrição às partições swap continua: são pouco flexíveis. Logo, use sim arquivos de swap! Btrfs: # btrfs filesystem mkswapfile -...

Um dos maiores trunfos do Linux é podermos usar instalações realmente pequenas para funções específicas. Tratarei aqui de um mecanismo de backup automático, sem intervenção do usuário: ao plugar um HDD externo, o mesmo será montado, uma pasta será copiada com o rsync e, por fim, o disco será desmontado e desconectado. A distribuição usada é o openSUSE Leap 15.2, porém pode ser adaptado para qualquer outra [1] . Identifique o dispositivo onde será feito o backup: # blkid /dev/sdb1 /dev/sdb1: LABEL="BACKUP123" UUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" TYPE="ext4" PARTUUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" Crie a regra para o udev: /etc/udev/rules.d/99-hdd-externo.rules ACTION=="add", SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="ext4", ENV{ID_FS_LABEL}=="BACKUP123", TAG+="systemd", ENV{UDISKS_IGNORE}="1", ENV{SYSTEMD_WANTS}+="meubackup@%N.service" ENV{UDISKS_IGNORE}=...

Útil complemento ao verbo edit (218+) do comando systemctl foi adicionado no systemd 230: revert . Pegue o exemplo do post systemctl cat/edit . Se quiséssemos desfazer as modificações locais, era preciso remover manualmente os drop-in e/ou overrides . Ficou mais fácil agora: # systemctl revert bacana.service Removed /etc/systemd/system/bacana.service.d/override.conf. Removed /etc/systemd/system/bacana.service.d. Caso tenhamos usado systemctl edit --full : # systemctl revert bacana.service Removed /etc/systemd/system/bacana.service. systemctl daemon-reload não é necessário, pois a configuração é automaticamente recarregada. revert trabalha apenas em /etc . Drop-ins em /usr não são removidos, visto que é considerado território do gerenciador de pacotes. CentOS 8.0 virá com systemd 239. 😉 Relacionado: Modificar parâmetros dos arquivos de unidade do systemd Básico dos arquivos de unidade do systemd Olho de Cylon do systemd Ordenação no systemd systemctl cat/edit ...

https://lists.freedesktop.org/archives/systemd-devel/2017-December/040054.html https://github.com/systemd/systemd/commit/d31b0033b7743393562a2e9d3c1e74afea981c13 Agora você, que ainda usa um 486, precisa achar uma distribuição que gere seus binários com o conjunto de instruções do velho processador, o que está cada vez mais difícil. A instrução CPUID existe desde a safra final dos 486 da Intel (os com alimentação de 3,3V, acho...).

Pontos de montagem autofs são úteis para compartilhamentos de rede. Com o systemd, basta adicionar, em /etc/fstab , x-systemd.automount nas opções. Exemplo: //192.168.0.10/Arquivos /mnt/Arquivos cifs credentials=/etc/senha-servidor,uid=marcos,gid=marcos,file_mode=0600,dir_mode=0700,x-systemd.automount 0 0 Isso evita que precisemos habilitar um serviço que implemente network-online.target , como NetworkManager-wait-online.service ou systemd-networkd-wait-online.service . Assim, não há atraso durante a inicialização. Apenas quando o ponto de montagem for acessado será montado. Porém, durante o desligamento, a desmontagem sempre dava timeout e causava atraso com o NetworkManager ao usar conexões sem fio. Analisando a cadeia de dependências, nada achei de errado. Estava em outro lugar o problema. O nm-applet , aquele programinha que fica no tray, salva conexões sem fio [1] , pelo menos ao usar o plugin nativo keyfile , com o parâmetro connection.permissions configurado para o us...

A partir do systemd 220, a opção --now poupa uma invocação adicional do systemctl quando queremos habilitar e iniciar, ou desabilitar e parar uma unidade. # systemctl enable <nome>.<tipo> # systemctl start <nome>.<tipo> | v # systemctl enable --now <nome>.<tipo> # systemctl disable <nome>.<tipo> # systemctl stop <nome>.<tipo> | v # systemctl disable --now <nome>.<tipo> # systemctl mask <nome>.<tipo> # systemctl stop <nome>.<tipo> | v # systemctl mask --now <nome>.<tipo> Melhor de tudo: a equipe da Red Hat backportou o recurso para a versão 219 do RHEL 7.2. Relacionado: Modificar parâmetros dos arquivos de unidade do systemd Básico dos arquivos de unidade do systemd Olho de Cylon do systemd Ordenação no systemd systemctl cat/edit systemctl revert

Como ativar todos os núcleos do seu processador no boot do Ubuntu (Diolinux) O mau cheiroso script /etc/init.d/rc nem é executado no boot: Mask /etc/init.d/rc and /etc/init.d/rcS from initscripts Trata-se de entulho remanescente do tempo das cavernas. Rode aí: (Ubuntu 16.04) $ systemctl is-enabled rc.service masked Um serviço masked está super ultra desabilitado . Tem influência no desempenho o serviço ondemand.service . Por padrão, o kernel do Ubuntu configura o escalonador de frequência de todos os núcleos com performance [1] , que os mantêm sempre na frequência máxima nominal — faz sentido durante o boot, para usar ao máximo o hardware, sem preocupar-se com consumo elétrico. O serviço, depois de 60 segundos, altera todos os núcleos para ondemand , com objetivo de aproveitar os recursos SpeedStep, Cool'n'Quiet e similares. Até o Ubuntu 16.04, esse serviço é na verdade um script SysV ( /etc/init.d/ondemand ), suportado pelo systemd através do sysv-generato...

Até o Squid 3.5, o comportamento do daemon é incompatível com inits modernos e exige gambiarras ou funcionalidade limitada ( -N ). Recapitulando como é até a versão 3.5: PID1 \_ MASTER/PARENT \_ WORKER <--- PROCESSO PAI DE FATO (ARQUIVO PID) \_ FILHO 1 \_ FILHO 2 ... No Squid 4, beta enquanto escrevo, é assim: PID1 \_ MASTER/PARENT <--- PROCESSO PAI DE FATO (ARQUIVO PID) \_ WORKER \_ FILHO 1 \_ FILHO 2 ... Ou seja, o processo a ser monitorado (e sinalizado) passou a ser filho direto do init, que agora pode fazê-lo via SIGCHLD. Portanto, usando Type=forking e rodando o daemon sem a opção -N , temos uma configuração funcional. Continua não bloqueando ao receber SIGTERM; o systemd, mesmo assim, aguarda o processo principal terminar, sendo finalizado corretamente. E, sem -N , o modo de múltiplos processos funciona. Desde a versão 3.5.11, o daemon não morre mais se receber SIGHUP antes de completar a...

Não faz muito saímos do systemd 208 do CentOS 7.0 e 7.1 para o 219 do 7.2. A nova versão traz dois novos verbos no systemctl : cat (209) e edit (218). O primeiro, apesar de simples, é muito útil. Serve para mostrar a íntegra do arquivo de unidade em questão e também eventuais drop-ins e overrides . # systemctl cat bacana.service # /usr/lib/systemd/system/bacana.service [Unit] Description=Serviço bacana [Service] ExecStart=/usr/bin/sleep 10000000 [Install] WantedBy=multi-user.target Suponhamos que precisemos modificar bacana.service e ordená-lo após , por exemplo, crond.service . Usamos: # systemctl edit bacana.service Será aberto num editor um arquivo ( drop-in ) de nome override.conf dentro do diretório /etc/systemd/system/bacana.service.d (será criado se necessário). Para escolher qual editor usar, as variáveis de ambiente SYSTEMD_EDITOR , EDITOR e VISUAL (nessa ordem) são interpretadas. Se não existir nenhuma delas, são tentados em ordem: nano , vim e vi . Col...

Se sua distribuição usar o dracut como gerador de initramfs e configurá-lo para usar o systemd (Fedora, openSUSE, etc ), você verá que, mesmo colocando 0 na sexta coluna ( fs_passno ) do /etc/fstab , o systemd-fsck ainda será executado no sistema de arquivos do diretório raiz. E no /usr caso esteja num volume separado — ver este link sobre esse cenário. Investigando um pouco, cheguei à resposta. A principal finalidade, quando não única, do initramfs é montar / e /usr , antes disso cuidando de porventura colocar arranjos RAID por software de pé, subir a rede para casos de sistemas que usem algo remotamente, etc. Demais volumes, que não sejam esses dois, não são montados no initramfs (exceção citada adiante). Restringindo o leque de possibilidades apenas a partições locais, a forma como dizemos qual sistema de arquivos deve ser montado é através de opções de boot; root= e mount.usr= servem para isso e são postas na configuração do bootloader pelo instalador (Anaconda, YaST...

É comum precisarmos ordenar unidades, sejam do tipo service , target , etc. O systemd oferece dois tipos de configuração para o propósito: ordenação ( After= , Before= ) e requerimento ( Wants= , Requires= ). As duas classes de dependências são independentes. Nota: existem outras opções menos usadas, porém não comentarei sobre elas aqui. After= e Before= dizem respeito à ordem, como esperado. São dependências de mão dupla: se você especificar After=yyy.service no serviço xxx.service , está implícita naquele uma dependência reversa Before=xxx.service . xxx.service yyy.service +--------------------+ +--------------------+ | | Implícito | | | After=yyy.service | ------------> | Before=xxx.service | | | | | +--------------------+ +--------------------+ Não tão claro é o papel de Wants= e Requires= . Suponhamos bbb.service ...

Como macaco velho que acompanha o nem mais tão novo assim systemd, já tive a oportunidade de ler muitas discussões/flames a respeito do mesmo. Um traço que chama a atenção é a falta de racionalidade de seus detratores. Entre as críticas, a tal "falta de liberdade". Essa é a que mais me espanta. Porque é um código livre, com uma documentação excelente (arrisco dizer que está entre os projetos open source mais bem documentados), programado por um time que conseguiu envidar esforços para resolver problemas . Talvez queiram dizer que a "liberdade" é aquela de trocar componentes fundamentais do sistema operacional à esmo e esperar que tudo funcione? Se dissessem que as ferramentas são "muito fáceis", "muito diferentes do que existia antes", ou que "é muito bugado", "consome recursos em excesso", daria para considerar — ressalvas à parte. A propósito dos bugs, não acho que seja um código muito bugado. Dois Três bugs realmente g...

...via systemctl poweroff e tal. Quando o polkit está instalado, alguns componentes do systemd consultam-o para liberar ou não para usuários normais a execução de diversas tarefas (se não estiver presente, ações que requeiram root não são permitidas). O que define o resultado retornado pelo polkit é a sua política. O systemd instala políticas padrão nos seguintes arquivos (considerando a versão 219 do CentOS 7): /usr/share/polkit-1/actions/org.freedesktop.hostname1.policy /usr/share/polkit-1/actions/org.freedesktop.import1.policy /usr/share/polkit-1/actions/org.freedesktop.locale1.policy /usr/share/polkit-1/actions/org.freedesktop.login1.policy /usr/share/polkit-1/actions/org.freedesktop.machine1.policy /usr/share/polkit-1/actions/org.freedesktop.systemd1.policy /usr/share/polkit-1/actions/org.freedesktop.timedate1.policy Cada um contendo a configuração relativa ao componente descrito no nome do arquivo. Os arquivos de /usr não devem ser editados, pois não sobreviverão a f...

No Fedora 21, Debian 8, o desligamento é extremamente rápido. Poderia parecer um recurso, mas na verdade é um bug introduzido na versão 209 do systemd: https://bugzilla.redhat.com/show_bug.cgi?id=1141137 https://bugzilla.redhat.com/show_bug.cgi?id=1170765 https://bugs.launchpad.net/bugs/1446982 https://bugs.launchpad.net/bugs/1448259 Nenhum sistema de arquivos corre risco. São todos desmontados corretamente. O bug consiste na sessão do usuário receber SIGKILL imediatamente após SIGTERM. Como o primeiro sinal vem praticamente ao mesmo tempo, os aplicativos não têm tempo de fazerem suas rotinas de desligamento. É por isso que, se você deixar o Firefox aberto e desligar ou reiniciar o sistema, na próxima inicialização, existe uma boa chance do navegador exibir aquela mensagem dizendo "isto é constrangedor" ou então restaurar automaticamente as abas anteriormente abertas: não teve tempo de processar SIGTERM. Enquanto escrevia o post sobre o Squid , achei estranho, mesmo...

Agora que o Debian conta com um init moderno , decidi usá-lo por um tempo para voltar a sentir uma distribuição baseada em DEB, o que não faço desde muito tempo quando larguei o Ubuntu e migrei para o Fedora e depois openSUSE. Instalação padrão usando o GNOME. Como esperado, várias inutilidades iniciadas por padrão. Que sina... # systemctl disable atd.service exim4.service gdomap.service minissdpd.service networking.service nfs-common.service pppd-dns.service rpcbind.service saned.service speech-dispatcher.service Synchronizing state for atd.service with sysvinit using update-rc.d... Executing /usr/sbin/update-rc.d atd defaults Executing /usr/sbin/update-rc.d atd disable insserv: warning: current start runlevel(s) (empty) of script `atd' overrides LSB defaults (2 3 4 5). insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `atd' overrides LSB defaults (0 1 6). Synchronizing state for exim4.service with sysvinit using update-rc.d... Executing /usr/sbin/upda...

O pessoal da Canonical adicionou na versão 219-git um novo daemon ao systemd, o systemd-fsckd . Na futura 220, será removido . Implementa um recurso que o Ubuntu tem (desde sempre?) de exibir durante o boot gráfico (Plymouth) o progresso da verificação dos sistemas de arquivos, além de oferecer ali opção para o usuário cancelar o processo. Está sendo removido por alguns motivos: - O systemd-fsck (sem o "d" no final), que roda o fsck genérico (que, por sua vez, roda o fsck de cada sistema, ufa!) e existe há muito tempo no projeto — sem integração com o Plymouth —, já é considerado um hack. Sistemas de arquivos que requerem fsck preen são tecnologia do passado. Btrfs não precisa, XFS nunca precisou. Falando no XFS, agora que o formato V5 está pronto , seu futuro é ser o máximo possível self-healing . - Oferecer opção para cancelar o fsck é arriscado. É dar aos usuários a arma engatilhada para o tiro no pé. - As verificações completas disparadas por intervalo de ...

O Squid pode operar em dois modos no que diz respeito à forma do daemon: com a opção -N ou sem ela. Com -N , não é feito o processo de daemonização. É o preferido em inits modernos. Deve ser usado sempre que possível com o Upstart ou systemd. Contudo, o modo de múltiplos processos do Squid não funciona com -N até agora (3.5) e as distribuições, portanto, não podem usar por padrão. Sem -N , ativa a daemonização. No systemd, isso significa um serviço Type=forking . À primeira vista, não haveria problema, pois existe compatibilidade. Não fosse o comportamento totalmente bugado do Squid ao funcionar dessa maneira. PID1 \_ MASTER/PARENT \_ WORKER <--- PROCESSO PAI DE FATO (ARQUIVO PID) \_ FILHO 1 \_ FILHO 2 ... Os problemas insolúveis são dois: - O processo que deve ser sinalizado (worker) não é filho direto do init. Isso impede o systemd monitorá-lo eficazmente via SIGCHLD. Ele lhe avisa com "squid.service: Supervising process XXX wh...

O journald atua como um concentrador de logs de todos os daemons do sistema, independente de usarem arquivos de unidade nativos ou scripts SysV. +----------+ +----------+ +----------+ | | | | | | | DAEMON 1 | | DAEMON 2 | | DAEMON 3 | ... | | | | | | +----------+ +----------+ +----------+ \ | / \ | / stdout/stderr \ | / syslog() \ | / sd_journal_*() v v v +------------------+ | | | systemd-journald |---> /var/log/journal/<machine-id> | | +------------------+ | v +------------+ | rsyslog, | | syslog-ng, |------> /var/log/messages, etc | etc | +------------+ Não pode ser desativado...

O Valério perguntou no FGdH se haveria um log unificado de erros no GNU/Linux. Tentarei responder aqui. Existem três maneiras de logar: 1) Usar a função syslog() da libc ou sd_journal_*() da libsystemd. Mensagens publicadas dessa forma serão processadas pelo daemon syslog (rsyslog, syslog-ng, etc.) ou pelo systemd-journald. 2) Enviar diretamente as mensagens para um arquivo. 3) Enviar as mensagens para stdout e/ou stderr . Na minha opinião, todo daemon deveria logar usando syslog e, apenas quando estritamente necessário, mandar mensagens adicionais para um arquivo (a ser rotacionado pelo logrotate). Exemplo: eu configuro o Squid para logar mensagens de status apenas via syslog (opção -s ) e deixo o log de acesso em /var/log/squid/access.log . É possível despejar o log de acesso no syslog também ou desabilitá-lo completamente caso desejado. Alguns daemons têm o hábito de logar para stdout/stderr. Em distribuições que usem o systemd você pode ter a certeza que tais mensag...

# hostnamectl Static hostname: debian Icon name: computer-vm Chassis: vm Machine ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Boot ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Virtualization: oracle Operating System: Debian GNU/Linux 8 (jessie) Kernel: Linux 3.16.0-4-amd64 Architecture: x86-64 # systemctl --version systemd 215 +PAM +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP -APPARMOR # ls -l /sbin/init lrwxrwxrwx 1 root root 20 Jan 21 10:31 /sbin/init -> /lib/systemd/systemd # getent --version getent (Debian GLIBC 2.19-13) 2.19 Copyright (C) 2014 Free Software Foundation, Inc. Este é um software free; leia os fontes para condicões de cópia. Não existe garantia; nem para comércio ou adequacão para propóstios particulares. Escrito por Thorsten Kukuk. # fdisk --version fdisk de util-linux 2.25.2 # ln --version ln (GNU coreutils) 8.23 Copyright (C) 2014 Free Software Foundation, Inc. Licença GPLv3+: GNU ...