[Distro/Desktop] Otimizando o systemd - 8 passos (adic. 5 passos e removido 1) 07/09/20

07/09/20
Atualização sobre lvm

Revisão: 02/09/20

  • adicionado link para otimizar initramfs
  • adiconado procedimento com xubuntu em um celeron

Revisão: 31/08/20

  • Passo quatro remnovido
  • Adicionado mais 5 passos, do nono ao décimo terceiro
  • Adicionado links de pesquisa

Este conteúdo faz parte de uma série de tópicos que decidi criar, por causa de um bate-papo no fórum.

Primeiro tutorial que faço de modo offline, achei que ficou mais fácil a visualização.

Fontes pesquisadas para este tópico: (tem outras que no momento não encontro, mas vou colocar depois)

Os passos que serão citados são pequenas configurações que podem otimizar o systemd. O ganho de memória e tempo de boot depende da sua máquina. Assuntos de compilação de kernel e outros meios não vou falar, pois hoje o ganho é quase nulo e é trabalhoso. Lembre-se que podemos remover ou desativar recursos e serviços. Caso venha utilizar eles no futuro terá que ativá-los. E também vamos configurar serviços e opções nativas do systemd.

Dependendo da máquina o melhor ganho é colocar ambientes desktop leves.

Otimizando systemd

Recomendo otimizar o systemd, e não só o ambiente desktop. Quanto antes acabar o carregamento do sistema mais rápido terminará e subirá o Wayland ou X11.
O ganho vai depender de serviços que rodam nele. Quanto mais serviços, e se o serviço for pesado, mais memória consumirá e mais tempo demorará para subir o desktop.
Não existe distro mais pesada que outra, lembre-se que os serviços e arquivos utilizados são os mesmos. Há uma padronização de instalação que cada distro escolhe , direcionados para notebooks ou não, e dependendo da distro você terá que instalar e configurar um determinado tipo de serviço pós-instalação, pode ser para economizar energia, compartilhar arquivos e outras tarefas.
Contudo podemos otimizar desativando serviços, customizando consoles e outros procedimentos.
Para se ter uma noção, instalando somente serviço de conexão e gerenciador de login em uma instalação com a distro Arch executada no virt-manager com 4GB de memória e 2 CPU demora 3 segundos para subir o sistema e 9 segundos para subir o ambiente Gnome.
O caminho é saber o que realmente precisa para ser inicializado no boot. Não recomendo tirar o que não sabe, procure saber antes de desativar. Para isso vou criar um tópico no fórum dedicado a isso.

Exemplos de máquinas que uso:

Procedimento com xubuntu em um celeron : [Distro/Desktop] Otimizando o systemd - 8 passos (adic. 5 passos e removido 1) 07/09/20
Configuração:

  • Intel® Core™ i7-4770 CPU @ 3.40GHz
  • 16GB de RAM
  • Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
  • SSD Kingston HyperX de 120GB – leitura 555MB e escrita 510MB

Antes demorava em torno de 35 segundos para iniciar Wayland no openSUSE com o usuário conectando automaticamente no gdm ao ambiente.
Resultado com sistema Arch e ambiente Gnome: [Distro/Desktop] Otimizando o systemd - 8 passos (adic. 5 passos e removido 1) 07/09/20

Resultado pelo systemd-analyze no openSUSE:
Como não sei se todos conhecem a leitura deste recurso, vai uma breve explicação da leitura.

Resultado do systemd-analyze com as modificações

~ $ systemd-analyze
Startup finished in 1.503s (kernel) + 2.889s (initrd) + 3.911s (userspace) = 8.303s
graphical.target reached after 3.899s in userspace

~ $ systemd-analyze –user
Startup finished in 500ms (userspace)
default.target reached after 500ms in userspace

~ $ systemd-analyze --user blame | grep -i wayland
5.313s gnome-shell-wayland.service

O primeiro é o tempo de inicialização do sistema até graphical.target. Isso pode ser visto pelo comando:

systemd-analyze plot > sistema.svg

Apenas a leitura da opção time é o suficiente, já que cada um inicia em um determinado tempo e termina na graphical.target. Logo temos:

8.303 + 3.899 = 12.202s

Analisando a sessão do usuário pela opção –user, vemos que tudo começa junto depois que default.target é iniciado. Repare que o valor é o mesmo.
Pode ser visto com a opção plot com –user.

systemd-analyze --user plot > usuários.svg

Logo adicionamos o tempo que o gnome-shell é inicializado, então:

0.500 + 5.313 = 5.813s

Para o cálculo final somamos o tempo das duas sessões:

12.202 + 5.813 = 18.015s

Agora leva 18.015s para inciar o Wayland.

Primeiro passo: Mascarando serviços não encontrados

Primeiro passo:

Mascarar unidades não instaladas. Para saber as unidades, execute:

Para sessão do sistema

systemctl -a -t not-found

Para sessão do usuário

systemctl –user -a -t not-found

Após descobrir todos os not-founds, vamos mascarar. Para isso execute os comandos:
Para sessão do sistema

sudo systemctl mask unidades-not-found

Para sessão do usuário

systemctl –user mask unidades-not-found

**Obs: **Caso queira desmascarar alguma unidade, use **unmask **.

Com isso já ganhamos algum tempinho. Pois o systemd não perderá tempo checando a unidade.

Segundo passo: Utilizando a automontagem de partições

Segundo passo:

Para otimizar o tempo de boot é interessante colocar as partições /boot ou /boot/efi, e também a partição /home (geralmente a maior) em modo automount. Você ganha de 1 a 4 segundos dependendo da máquina.
Para este processo adicione em /etc/fstab as opções de montagem nestas partições:
,noauto,x-systemd.automount
Exemplo: (não esqueça da vírgula)

/dev/sdb3 /home xfs defaults,noauto,x-systemd.automount 0 0
Nota: Podemos instalar sistemas Linux em uma só partição, mas para ter uma melhor performance é recomendado dividir com as partições /boot, /,e /home (caso use SSD também a /var)

Terceiro passo: Desativando rotação escalonada

Terceiro passo:

Rotação escalonada

Alguns hardwares implementam a rotação escalonada, o que faz com que o sistema operacional analise as interfaces ATA em série, o que pode aumentar a rotação dos drives um a um e reduzir o uso de energia de pico. Isso diminui a velocidade de inicialização e, na maioria dos hardwares de consumidor, não oferece nenhum benefício, pois as unidades já funcionam imediatamente quando a energia é ligada. Para verificar se o SSS está sendo usado:
dmesg | grep SSS
Se não foi usado durante a inicialização, não haverá saída.
Para desativar adicione na linha do kernel do grub o parâmetro:
libahci.ignore_sss=1
Para modo permanete modifique o arquivo /etc/default/grub.
Na linha
GRUB_CMDLINE_LINUX_DEFAULT=“adicione aqui dentro das aspas”
Salve e atualize o grub.
Cada distro tem um comando, pesquise para saber qual usar:
Exemplos:
**Ubuntu **
sudo update-grub
**Arch **
sudo grub-mkconfig -o /boot/grub/grub.cfg

[details=“Quarto passo: Utilizando o início precoce para serviço” ] Atenção: efeito contrário.

## Quarto passo:

Início precoce para serviços

Um recurso central do systemd é o D-Bus e ativação de soquete. Isso faz com que os serviços sejam iniciados quando eles são acessados pela primeira vez e geralmente é uma coisa boa. No entanto, se você sabe que um serviço (como o upower) sempre será iniciado durante a inicialização, o tempo geral de inicialização pode ser reduzido iniciando-o o mais cedo possível. Isso pode ser alcançado (se o arquivo de serviço estiver configurado para ele, o que na maioria dos casos é) emitindo:

systemctl enable upower

[/details]

Quinto passo: Desabiltando todos consoles tty ou não

Quinto passo:

Desabilitar todos consoles tty ou não e habilitar somente 1
tty básico

  • Pode-se alternar do tty1 até tty6 usando Ctrl + Alt + F [1-6] .
  • Isso continua até tty6, ou seja, o número padrão de consoles tty permitidos são 6. ttys são gerenciados pelo systemd.
  • Consoles tty são criados durante o acesso.
  • O número permitido de consoles pode ser configurado no arquivo /etc/systemd/logind.conf .
    Desative todos os consoplymouth-quit-wait.serviceles tty

NAutoVTs - Defina-o com um número desejado para que o systemd seja capaz de gerar muitos consoles tty. O padrão é 6. Quando definido como 0, a geração automática de serviços autovt é desabilitada.
ReserveVT - Pega um número inteiro positivo. Identifica um terminal virtual que deve ser incondicionalmente reservado para ativação autovt @ .service . O padrão é 6 (em outras palavras, sempre haverá um “getty” disponível no Alt-F6.). Quando definido como 0, a reserva VT é desativada.
Nota : N é o número de tty que você deseja ativar. Aceita um valor inteiro positivo. As ttys serão utilizadas por boot, desktop não serão desativadas.

Habilitar um console tty

  1. Para habilitar um único console tty, defina os parâmetros abaixo no arquivo /etc/systemd/logind.conf .
    sudo nano /etc/systemd/logind.conf

NAutoVTs = 0
ReserveVT = 1
Se quiser reservar a 3 e ela não é utilizada por nenhum outro serviço. É o que uso. Deixo pelo menos uma se eu precisar.
sudo nano /etc/systemd/logind.conf
NAutoVTs = 0
ReserveVT = 3

Obs: O GDM roda em algumas distros na vt7, isso continuará assim, o desktop roda no vt2, isso continuará assim.
Mais informações
`man logind.conf

Sexto passo: Desabilitando serviços do boot que não for utilizar

Sexto passo:

**Desabilitar serviços **
ATENÇÃO: Isso é apenas uma sugestão

Para desabilitar do boot

sudo systemctl disable o-nome-da-unidade

NetworkManager-wait-online.service serve para acessar automaticamente recursos remotos.

sssd.service utilizado para logins com usuários de rede. Serviço relacionado ao ldap. Se você não faz login por rede pode desabilitar.

lvm2-monitor.service gerencia unidades configuradas em LVM. Se você não usa LVM pode desabilitar.
dvboxrv.service, vboxballoonctrl-service.service, vboxautostart-service.service, vboxweb-service.service serviços relacionados ao VirtualBox. É seguro desabilitar.

abrtd.service ferramenta de relatório de crash do sistema. Pode ser desabilitado para não rodar na inicialização.

avahi-daemon.service permite descobrir automaticamente os recursos de rede e se conectar a eles.

geoclue.service é um serviço D-Bus que fornece informações de localização. O objetivo do projeto Geoclue é tornar a criação de aplicativos com reconhecimento de localização o mais simples possível. ( só desativa se mascarar)

cron.service é um agendador. Se não for utilizar desative. Os serviços timer do systemd já fazem isso.

plymouth-quit-wait.service como o próprio nome já diz, espera serviços para finalizar. Se usa SSD recomendo desativar, para HDD pode tamb;em ganhar algum tempo. Não atrapalha em nada desativá-lo.

smb e nmb – Você realmente usa a rede. Usa somente para compartilhar impressora. Recomendo compartilhar via cups. (pode ganhar uns 4 segundos)

Para Windows é só colocar o caminho

Exemplo: ip da máquina que está a impressora

http://192.168.2.2:631/printers/Deskjet_2510

      Para Linux é o mesmo processo, mas usa ipp

ipp://192.168.2.2:631/printers/Deskjet_2510

Mas claro, você tem que entrar na configuração do cups no navegador e marcar a opção compartilhar e abrir a porta tcp 631 do firewall se estiver habilitado.

Caso queira ativar temporariamente o serviço do samba

sudo systemctl start smb nmb

Atenção: Recomendo ver o nome do serviço da sua distro para este processo.

fstrim – serviço de trim para SSD. Se não tem, pode desativar.

Bluetooth – se não tem , pode desativar.

Sétimo passo: Limitando o tamanho do registro journal

Limite no tamanho do registro do journal
Se o journal é persistente (não volátil), seu tamanho limite é definido para um valor padrão de 10% do tamanho do respectivo sistema de arquivos, mas limitado a 4 GB. Por exemplo, com o /var/log/journal localizado em uma partição de 20 GB, o journal pode usar até 2 GB. Em uma partição de 50 GB, ela usaria no máximo até 4 GB.
O tamanho máximo do journal persistente pode ser controlado removendo o comentário e alterando o seguinte: ( definido para 50 ,100 ou outro valor)
/etc/systemd/journald.conf
SystemMaxUse=100M
Reinicie o systemd-journald.service após alterar essa configuração para aplicar imediatamente o novo limite.
sudo systemctl restart systemd-journald.service

Oitavo passo: Habilitando cliente NTP nativo do systemd

**OBS: **O Gnome se não tem nenhum outro serviço instalado utiliza este.

systemd-timesyncd é um daemon que foi adicionado para sincronizar o relógio do sistema na rede. Ele implementa um cliente SNTP. Em contraste com implementações NTP, como **chrony **ou o servidor de referência **NTP * *, isso apenas implementa um lado do cliente e não se preocupa com a complexidade total do NTP, focando apenas em consultar o tempo de um servidor remoto e sincronizar o relógio local para ele. A menos que você pretenda servir NTP para clientes em rede ou deseja se conectar a relógios de hardware locais, este cliente NTP simples deve ser mais do que apropriado para a maioria das instalações. O daemon é executado com privilégios mínimos e foi conectado ao networkd para operar apenas quando a conectividade de rede estiver disponível. O daemon salva o relógio atual no disco toda vez que uma nova sincronização NTP é adquirida e usa isso para possivelmente corrigir o relógio do sistema no início da inicialização, a fim de acomodar sistemas que não possuem um RTC, como o Raspberry Pi e dispositivos incorporados, e certifique-se de que o tempo progride monotonicamente nesses sistemas, mesmo que nem sempre seja correto. Para fazer uso deste daemon, um novo usuário do sistema e grupo “systemd-timesync” precisa ser criado na instalação do systemd.

Iniciar/habilitar systemd-timesyncd.service que está disponível com o systemd .
sudo systemctl start systemd-timesyncd.service
sudo systemctl enable systemd-timesyncd.service

Ao iniciar, o systemd-timesyncd lerá o arquivo de configuração /etc/systemd/timesyncd.conf, que se parece com este: Exemplo do openSUSE.
/etc/systemd/timesyncd.conf

[Time]
#NTP=
#FallbackNTP=0.opensuse.pool.ntp.org 1.opensuse.pool.ntp.org 2.opensuse.pool.ntp.org 3.opensuse.pool.ntp.org
#RootDistanceMaxSec=5
#PollIntervalMinSec=32
#PollIntervalMaxSec=2048

Para adicionar servidores de horário ou alterar os fornecidos, descomente a linha relevante e liste seus nomes do host ou ip separados por um espaço. Por exemplo, você pode usar qualquer servidor fornecido pelo projeto NTP pool:
pool.ntp.org: NTP Servers in Brazil, br.pool.ntp.org
/etc/systemd/timesyncd.conf

[Time]
NTP=0.br.pool.ntp.org 1.br.pool.ntp.org 2.br.pool.ntp.org 3.br.pool.ntp.org
FallbackNTP=0.opensuse.pool.ntp.org 1.opensuse.pool.ntp.org 2.opensuse.pool.ntp.org 3.opensuse.pool.ntp.org

**Informações **
NTP -> Uma lista separada por espaço de nomes de host de servidor NTP ou endereços IP. Durante o tempo de execução, esta lista é combinada com quaisquer servidores NTP por interface adquiridos de systemd-networkd.service (8). systemd-timesyncd entrará em contato com todos os servidores configurados do sistema ou com interface por vez até que seja encontrado um que responda. Quando a string vazia é atribuída, a lista de servidores NTP é redefinida e todas as atribuições anteriores a esta não terão efeito. Esta configuração é padronizada para uma lista vazia.

FallbackNTP -> Uma lista separada por espaço de nomes de host de servidor NTP ou endereços IP a serem usados ​​como servidores NTP de fallback (ou reserva). Quaisquer servidores NTP por interface obtidos de systemd-networkd.service (8) têm precedência sobre esta configuração, assim como qualquer servidor configurado via NTP = acima. Portanto, essa configuração é usada apenas se nenhuma outra informação do servidor NTP for conhecida. Quando a string vazia é atribuída, a lista de servidores NTP é redefinida e todas as atribuições anteriores a esta não terão efeito. Se esta opção não for fornecida, uma lista compilada de servidores NTP será usada. Normalmente esta opeção já vem preenchida com as configuraçòes da distro

Informaçòes do uso:
systemd-timesyncd - ArchWiki
systemd-timesyncd.service

Nono passo: Otimizando o apparmor

Apparmor é um sistema de controle de acesso obrigatório (ou MAC). Ele usa aprimoramentos de kernel do LSM para restringir programas a determinados recursos. O AppArmor faz isso com perfis carregados no kernel quando o sistema é iniciado. Apparmor tem dois tipos de modos de perfil, fiscalização e reclamação.
A instalaçào dele é recomendada. Algumas distros já vem com ele por padrão.

Ele pode demorar até 6s ou mais. Para otimizar usaremos o recurso de cache dele. Assim o carregamento ficará bem mais rápido.

Como o AppArmor precisa converter os perfis configurados em um formato binário, isso pode aumentar significativamente o tempo de inicialização. Você pode verificar o tempo de inicialização atual do AppArmor com:

$ systemd-analyze blame | grep apparmor

Para habilitar o cache AppArmor , descomente:

/etc/apparmor/parser.conf

## Turn creating/updating of the cache on by default
write-cache

Caso queira alterar a localização da pasta cache:

/etc/apparmor/parser.conf

cache-loc=/path/to/location

Reinicie ocomputador e faça novamente a verificação.

Décimo passo: Otimizando o agendador do kernel pela udev

Podemos configurar um tipo de agendador para cada tipo de dispositivo.
Cada distro tem um meio de configurar, openSuse já vem com está configuração por padrão.
Você terá que ver como habilitar o bfq para sua distro e se as opções mq-deadline e none existem

Para ver o agendador do momento:

cat /sys/block/sda/queue/scheduler
cat /sys/block/sdb/queue/scheduler
cat /sys/block/sdc/queue/scheduler

Isso é feito criando uma regra no udev: Aqui vamos habilitar o bfq para HDD, SSD mq-deadline e none para NVMe

/etc/udev/rules.d/60-scheduler.rules

Com o seguinte conteúdo:

    # definindo agendador para NVMe
    ACTION=="add|change", KERNEL=="nvme[0-9]*", ATTR{queue/scheduler}="none"
    # definindo agendador para  SSD e eMMC
    ACTION=="add|change", KERNEL=="sd[a-z]|mmcblk[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"
    # definindo agendador para discos rotativos
    ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq"

Reinicie e veja novamente o agendador usado.

Décimo primeiro passo: Otimizando o journal do systemd

Vimos no passo 7 que podemos limitar o tamanho.

Aqui vamos adicionar outras configurações, descomentado a opções em:

/etc/systemd/journald.conf

SystemMaxFiles=5 # manter no máximo 5 arquivos
MaxFileSec=1month # deletar logs velhos depois de 1 mês

Caso nào tenha, instale o logrotate, e descomente ou adicone as seguintes configurações em:

logrotate é projetado para facilitar a administração de sistemas que geram um grande número de arquivos de log. Ele permite rotação automática, compactação, remoção e envio de arquivos de log. Cada arquivo de log pode ser tratado diariamente, semanalmente, mensalmente ou quando fica muito grande.

/etc/logrotate.conf

maxsize 100M # tamanho máx do arquivo
size 100M # tamanho do arquivo
delaycompress # não comprime na primeira rotação .1

e habilite o timer no boot

sudo systemctl enable logrotate.timer
sudo systemctl start logrotate.timer

Décimo segundo passo: Desabilitando serviços do boot que já são inicializados por outro serviço

Alguns serviços já serão inicializados por outros e você pode ganhar algum tempo no boot desativando (não mascarar) pelo systemctl.
Já vi algumas distros colocando eles no boot. exemplos:
dbus.service
accounts-daemon.service
colord.service
udisk.service

Tem outros, terá que ver se inicializa.
Pode ser visto pelo:

systemd-analyze blame

Décimo terceiro passo: Desativando LVM se não utiliza

Caso não utilize o LVM, não tem porque deixar este serviço carregando no boot.
Comop obter os serviços:

systemctl list-unit-files | gre -i lvm

Exemplos:
lvm2-activation-early.service
lvm2-activation-net.service
lvm2-activation.service
lvm2-lvmetad.service
lvm2-lvmpolld.service
lvm2-monitor.service
lvm2-pvscan@.service

Para tirarmos do boot, precisamos mascarar.

sudo systemctl mask lvm2-activation-early.service lvm2-activation-net.service lvm2-activation.service lvm2-lvmetad.service lvm2-lvmpolld.service lvm2-monitor.service lvm2-pvscan@.service

Se quiser desmacarar use o unmask.
Para pegar os nomes dos arquivos mascarados:

systemctl list-unit-files --state masked

Recomendo ver com systemd-analyze blame se tem mais algum rodando.

Para desativar o lvmetad do gerenciador grub

/etc/lvm/lvm.conf

procure por

use_lvmetad = 1

e modifique para

use_lvmetad = 0

salve e execute a atualização do menu do grub

com

Ubuntu
update-grub

openSUSE e Fedora
grub2-mkgconfig -o /boot/grub2/grub.cfg

Arch
grub-mkgconfig -o /boot/grub/grub.cfg

Ficou com dúvida? Está complicado? Comente aqui!

Para quem quiser otimizar initramfs…
Recomendo ter 2 kernel no mínimo e só fazer o teste em um

13 Curtidas

Bravo, @swatquest!

Esta é a primeira abordagem “prática” (construtiva) que vejo, em vários anos.

A série vai ser só no Forum Diolinux Plus? Ou você tem um blog?

1 Curtida

Somente aqui…

Tem outros procedimentos, mas acho que no geral e menos trabalhoso adicionei aqui

:+1:

Levando em consideração o tempo e memória que pode ganhar.
Separei para não ficar muito grande e confuso em um único tópico.

3 Curtidas

Gostaria de seguir todas as suas postagens sobre este assunto, mas sou “novo” no Forum, não conheço todos os recursos.

Acabo de ver outra postagem sua, igualmente recente. Favoritei as 2, mas… como acompanhar outras que você vier a iniciar por aqui?

1 Curtida

Vou colocar o link para os outros tópicos no início da primeira mensagem.

Será uma série de 3 tópicos

3 Curtidas

Estou apanhando com a formatação do fórum, mas acho que agora está bom.

Se algum moderador quiser modificar a formatação ou texto. Pode fazer uma revisão sem problemas.

Até

2 Curtidas

Favoritei, vou testar com calma no Manjaro Gnome e coloco aqui as impressões - ainda mais que a minha máquina é bem mais antiga que a do @swatquest e roda com hd5400rpm, acredito que por ser mais lenta, as otimizações podem dar bom aqui

A meu Gnome está também otimizado.

Depois faço algumas atualizações e coloco a data no titulo do tópico

Por exemplo:

se não usa lvm

pode chamar a lvm pelo systemctl

systemctl list-unit-files | grep -i lvm

e mascarar todas…

sudo systemctl mask lvm…

talvez dependendo da distro tenha que fazerr uma modificação no arquivo de configuração do lvm…

Mas vou ver com calma e adiciono outro passo se necessário

1 Curtida

Por curiosidade o comando systemctl -a t not-found
Unknown operation t.
Gera essa saida, isso e normal?

Valeu… Vou corrigir

systemctl -a -t not-found

Corrigido

2 Curtidas

No caso do para mascarar os serviços mortos teria que ser um por um que mostrar ou e so copiar o comando e colar?

Exemplo

systemctl mask lvm2.service syslog.service…

Copia o nome e sai colando um ao lado do outro com espaço entre eles

Para ver depois todos os mascarados

systemctl list-unit-files --state masked

Qualquer dúvida, quando puder respondo

Boa noite

2 Curtidas

Parabéns @swatquest pelo conteúdo super detalhado.
Minha máquina atualmente fica pronta em 20 segundos :slight_smile: vamos ver quanto tempo eu consigo economizar com suas dicas.

:vulcan_salute:

1 Curtida

O q é o cliente nativo NTP?

É o serviço responsável por manter a data e a hora do sistema operacional (Linux) atualizada e certa, ele faz acesso a rede para isso. O nome do protocolo utilizado para isso é o NTP.

Instalei Debian numa VM só para testar :+1:

bem pessoal…

tirei este

accounts-daemon.service permite programas obterem e manipularem informações de contas de usuários. Acho um risco deixar ativado.

apesar de eu achar um risco, se você mascarar este serviços terá problemas para iniciar o gnome e outras desktops.

como fiz um poucoi direcionado para o gnome

no comando

~ $ systemd-analyze --user blame | grep -i wayland
5.313s gnome-shell-wayland.service

o melor seria

~ $ systemd-analyze --user blame | head -1
5.313s gnome-shell-wayland.service

basicamente pega a última unit ativada.

farei algumas atualizações … adicionar + 1 passo

1 Curtida

NTP serviço de sincronizaćào de hora e data para o sistema…

O cliente apenas sincroniza …

Contudos os serviços citados também fornecem como servidor…para sincronizar computadores da rede a partir do servidor da empresa

Hoje a noite devo colocar mais alguns passos…

E editar alguns já citados.

feita a primeira revisão:

Revisão: 31/08/20

Passo quatro remnovido
Adicionado mais 5 passos, do nono ao décimo terceiro
Adicionado links de pesquisa

O computador é o citado na primeira mensagem

Arch com GNOME

~ $ systemd-analyze
Startup finished in 1.661s (kernel) + 2.533s (userspace) = 4.194s
graphical.target reached after 2.532s in userspace

~ $ systemd-analyze --user
Startup finished in 527ms (userspace)
default.target reached after 527ms in userspace

~ $ systemd-analyze --user blame | head -1
3.771s gnome-shell-wayland.service

Serviços habilitádos no boot
~ $ systemctl list-unit-files --state enabled
org.cups.cupsd.path enabled disabled
apparmor.service enabled disabled
gdm.service enabled disabled
getty@.service enabled enabled
haveged.service enabled disabled
NetworkManager-dispatcher.service enabled disabled
NetworkManager.service enabled disabled
org.cups.cupsd.service enabled disabled
systemd-timesyncd.service enabled enabled
ufw.service enabled disabled
org.cups.cupsd.socket enabled disabled
remote-fs.target enabled enabled
fstrim.timer enabled disabled
logrotate.timer enabled disabled

Resultado
4,194+2,532+0,527+3,771=11,024s

11,024s para iniciar o ambiente gnome

Na pós-instalação sem vários serviços habilitados como, apparmor, levava emtorno de 21s.

até pessoal