O que é necessário para uma inicialização do systemd mínima para iniciar o getty em um console virtual?

Question

Para o SysV init , preciso que /etc/inittab responda entradas do getty, o /sbin/init binario, os binários e bibliotecas compartilhadas para o shell, login , o getty , o material PAM / security / shadow, e alguns arquivos de dispositivos.

Para upstart , preciso basicamente dos mesmos requisitos, mas em vez de /etc/inittab , tenho alguns arquivos *.conf em /etc/init : um * .conf que start on startup define um nível de execução com telinit , e um * .conf para cada tty que inicie / respawn getty nesse tty nos runlevels apropriados.

Quais configurações e binários eu preciso para systemd init ?

A documentação que encontro parece estar focada em como usar um sistema já instalado para iniciar e parar serviços.

Uma lista mínima de arquivos para copiar (exceto o kernel / initrd) de uma instalação em execução Arch ou fedora funcionaria bem, mas parece que não consigo encontrar esse tipo de informações sobre systemd .

O que eu gostaria de saber é que, para systemd , quais arquivos são necessários e o que eles devem conter para iniciar um shell de login após um initramfs, ele faz switch_root para systemd /sbin/init .

Exemplo para upstart , os binários e dois *.conf arquivos:

Arquivo /etc/init/whatever.conf :

start on startup
emits runlevel
task
script
  telinit 2
end script

Arquivo /etc/init/tty1.conf :

start on runlevel [12345]
respawn
exec /sbin/agetty -8 --noclear 38400 tty1 linux

Exemplo para sysvinit , os binários e 1 arquivo conf chamado /etc/inittab :

id:2:initdefault:
c1:12345:respawn:/sbin/agetty 38400 tty1 linux

Agora estou atrás do equivalente systemd .

Suponho que pelo menos 1% do arquivo*.service seja necessário em algum lugar, com uma entrada [Service] contendo ExecStart=-/sbin/agetty --noclear %I linux e Restart=always , mas o que mais é necessário?

    

Answer 1

Primeiro, systemd não é um unix tradicional init . O Systemd é muito mais, então é um pouco injusto comparar os dois.

Para responder à pergunta, o que parece ser necessário são alguns binários e os seguintes arquivos de configuração:

/usr/lib/systemd/system/default.target
/usr/lib/systemd/system/basic.target
/usr/lib/systemd/system/sysinit.target
/usr/lib/systemd/system/getty.target
/usr/lib/systemd/system/[email protected]
/usr/lib/systemd/system/console-getty.service

A emissão de systemctl enable console-getty.service [email protected] cria esses links simbólicos:

/etc/systemd/system/default.target.wants/[email protected] -> /lib/systemd/system/getty@service
/etc/systemd/system/getty.target.wants/console-getty.service -> /lib/systemd/system/console-getty.service

OBSERVAÇÃO : Para utilizar os recursos especiais do systemd para iniciar agetty dinamicamente, sob demanda ao pressionar Alt + F3 e assim por diante, parece que você também deve ter pelo menos esses dois arquivos:

/etc/systemd/logind.conf
/lib/systemd/system/[email protected]

onde [email protected] é um link simbólico para [email protected] .

Conteúdo dos arquivos de configuração:

Os arquivos default.target , getty.target , sysinit.target podem estar vazios, exceto pela tag [Unit] e (provavelmente) Description=xxx .

basic.target também contém informações de dependência:

[Unit]
Description=Basic System
Requires=sysinit.target
Wants=sockets.target timers.target paths.target slices.target
After=sysinit.target sockets.target timers.target paths.target slices.target

Não tenho certeza se as referências a destinos que não existem como arquivos são necessárias ou não. Eles são descritos na página do manual systemd.special(7) .

console-getty.service : (caso especial para agetty no console)

[Unit]
Description=Console Getty
After=systemd-user-sessions.service plymouth-quit-wait.service
Before=getty.target

[Service]
ExecStart=-/sbin/agetty --noclear --keep-baud console 115200,38400,9600 $TERM
Type=idle
Restart=always
RestartSec=0
UtmpIdentifier=cons
TTYPath=/dev/console
TTYReset=yes
TTYVHangup=yes
KillMode=process
IgnoreSIGPIPE=no
SendSIGHUP=yes

[Install]
WantedBy=getty.target

[email protected] : (configuração genérica para todos os serviços getty, exceto console)

[Unit]
Description=Getty on %I
After=systemd-user-sessions.service plymouth-quit-wait.service
Before=getty.target
IgnoreOnIsolate=yes
ConditionPathExists=/dev/tty0

[Service]
ExecStart=-/sbin/agetty --noclear %I $TERM
Type=idle
Restart=always
RestartSec=0
UtmpIdentifier=%I
TTYPath=/dev/%I
TTYReset=yes
TTYVHangup=yes
TTYVTDisallocate=no
KillMode=process
IgnoreSIGPIPE=no
SendSIGHUP=yes

[Install]
WantedBy=getty.target
DefaultInstance=tty1

Finalmente, você provavelmente precisará de alguns desses binários especiais (eu não tentei quais são cruciais):

/lib/systemd/systemd (/sbin/init usually points to this)
/lib/systemd/systemd-logind
/lib/systemd/systemd-cgroups-agent
/lib/systemd/systemd-user-sessions
/lib/systemd/systemd-vconsole-setup
/lib/systemd/systemd-update-utmp
/lib/systemd/systemd-sleep
/lib/systemd/systemd-sysctl
/lib/systemd/systemd-initctl
/lib/systemd/systemd-reply-password
/lib/systemd/systemd-ac-power
/lib/systemd/systemd-activate
/lib/systemd/systemd-backlight
/lib/systemd/systemd-binfmt
/lib/systemd/systemd-bootchart
/lib/systemd/systemd-bus-proxyd
/lib/systemd/systemd-coredump
/lib/systemd/systemd-cryptsetup
/lib/systemd/systemd-fsck
/lib/systemd/systemd-hostnamed
/lib/systemd/systemd-journald
/lib/systemd/systemd-journal-gatewayd
/lib/systemd/systemd-journal-remote
/lib/systemd/systemd-localed
/lib/systemd/systemd-machined
/lib/systemd/systemd-modules-load
/lib/systemd/systemd-multi-seat-x
/lib/systemd/systemd-networkd
/lib/systemd/systemd-networkd-wait-online
/lib/systemd/systemd-quotacheck
/lib/systemd/systemd-random-seed
/lib/systemd/systemd-readahead
/lib/systemd/systemd-remount-fs
/lib/systemd/systemd-resolved
/lib/systemd/systemd-rfkill
/lib/systemd/systemd-shutdown
/lib/systemd/systemd-shutdownd
/lib/systemd/systemd-socket-proxyd
/lib/systemd/systemd-timedated
/lib/systemd/systemd-timesyncd
/lib/systemd/systemd-udevd
/lib/systemd/systemd-update-done

Para resumir o processo de inicialização do systemd, acho que funciona assim:

1. systemd localiza basic.target (ou todos os *.target arquivos?)
2. as dependências são resolvidas com base nas diretivas WantedBy= , Wants= , Before= , After= ... na seção [Install] dos arquivos de configuração *.service e *.target .
3. *.service s que devem iniciar (que não são serviços "especiais"), tem uma seção [Service] com uma diretiva ExecStart= , que indica que o executável deve ser iniciado.

Answer 2

systemd cria automaticamente um getty quando você alterna para os terminais, até um determinado número máximo. O padrão é 6 (assim você obtém automaticamente um getty para alt + f1 para alt + f6). Se você quiser alterar este parâmetro, você pode editar /etc/systemd/logind.conf para alterar o parâmetro NAutoVTs para algum outro número (max 12)

Se você quiser que um getty seja gerado, mesmo que você não alterne manualmente, você pode adicionar um link simbólico para /usr/lib/systemd/system/[email protected] ao diretório /etc/systemd/system/getty.target.wants/ :

ln -sf /usr/lib/systemd/system/[email protected] /etc/systemd/system/getty.target.wants/[email protected]

isso resultará no getty.target exigindo mais um getty@ service. Um destino é uma coleção de serviços que precisam ser gerados, substituição de níveis de execução que suportam dependências. O destino padrão depende de getty.target

Veja em FAQs do systemd no ArchWiki

editar: Eu pesquisei um pouco mais na documentação .

Na inicialização, o daemon systemd carrega todos os sistemas no default target e suas dependências. Um alvo é definido pelos arquivos

/etc/systemd/system/default.target
/usr/lib/systemd/system/default.target

Um alvo tem uma lista de serviços anexados especificados por links simbólicos nos diretórios

/etc/systemd/system/default.target.wants
/usr/lib/systemd/system/default.target.wants

A versão /etc substitui os padrões de distribuição em /usr/lib . Apenas um dos arquivos .target é necessário, enquanto nenhum diretório é necessário

getty é apenas um dos serviços, entre outros, que podem ser executados por scripts de inicialização. Na distribuição que eu verifiquei (fedora, arch) getty é executado de duas maneiras diferentes:

1. Iniciado por scripts específicos para cada terminal (links para o arquivo /usr/lib/systemd/system/[email protected] no qual o nome tty é substituído por systemd do nome do arquivo de link )
2. Criada automaticamente conforme necessário pelo logind quando o usuário alterna para um terminal virtual (semelhante à maneira como o% inetd trouxe os serviços somente quando chega uma solicitação). logind é um daemon diferente distribuído com systemd e lê sua configuração do arquivo /etc/systemd/logind.conf .

Espero que isso seja satisfatório.