9.1. Engegada del sistema
Quan s'inicia l'ordinador, els molts missatges que apareixen a la consola mostren moltes inicialitzacions i configuracions automàtiques que s'estan executant. A vegades es pot voler alterar lleugerament com funciona aquesta etapa, cosa que significa que cal entendre-la bé. Aquest és el propòsit d'aquesta secció.
On systems with a BIOS, first, the BIOS takes control of the computer, initializes the controllers and hardware, detects the disks, and bridges everything together. Then it looks up the Master Boot Record (MBR) of the first disk in the boot order and loads the code stored there (first stage). This code then launches the second stage and finally executes the bootloader.
In contrast to the BIOS, UEFI is more sophisticated, it knows filesystems and can read the partition tables. The interface searches the system storage for a partition labeled with a specific globally unique identifier (
GUID) that marks it as the
EFI System Partition (
ESP), where the bootloaders, boot managers, UEFI shell, etc., are located, and launches the desired bootloader. If Secure Boot is enabled, the boot process will verify authenticity of the EFI binaries there by signature (thus
grub-efi-arch-signed is required in this case). The UEFI specification also defines support for booting in legacy BIOS mode. This is called the
Compatibility Support Module (
CSM). If CSM is enabled, it will attempt to boot from a drive's MBR. However, many new systems do no longer support the CSM mode.
In both cases then the actual bootloader takes over, finds either a chained bootloader or the kernel on the disk, loads, and executes it. The kernel is then initialized, and starts to search for and mount the partition containing the root filesystem, and finally executes the first program — init. Frequently, this “root partition” and this init are, in fact, located in a virtual filesystem that only exists in RAM (hence its name, “initramfs”, formerly called “initrd” for “initialization RAM disk”). This filesystem is loaded in memory by the bootloader, often from a file on a hard drive or from the network. It contains the bare minimum required by the kernel to load the “true” root filesystem: this may be driver modules for the hard drive, or other devices without which the system cannot boot, or, more frequently, initialization scripts and modules for assembling RAID arrays, opening encrypted partitions, activating LVM volumes, etc. Once the root partition is mounted, the initramfs hands over control to the real init, and the machine goes back to the standard boot process.
9.1.1. El sistema d'inici de systemd
Aquest “init real” és proveït actualment per systemd i aquesta secció documenta aquest sistema d'inici.
Systemd executa diversos processos, que es fan càrrec de la configuració del sistema: teclat, controladors, sistemes de fitxers, xarxa, serveis. Ho fa mantenint una visió global del sistema en el seu conjunt i dels requisits dels components. Cada component és descrit per un “arxiu d'unitat” o «unit file» (i de vegades més d'un); la sintaxi general es deriva de la sintaxi àmpliament usada dels fitxers “*.ini”, amb parells clau =valor agrupats entre capçaleres[secció]. Els arxius d'unitats s'emmagatzemen sota /lib/systemd/system/ i /etc/systemd/system/; hi ha diferents variants, però aquí ens centrarem en els de “serveis” i “objectius” (o «targets»).
A systemd “.service file” describes a process managed by systemd. It contains roughly the same information as old-style init-scripts, but expressed in a declaratory (and much more concise) way. Systemd handles the bulk of the repetitive tasks (starting and stopping the process, checking its status, logging, dropping privileges, and so on), and the service file only needs to fill in the specifics of the process. For instance, here is the service file for SSH:
[Unit]
Description=OpenBSD Secure Shell server
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run
[Service]
EnvironmentFile=-/etc/default/ssh
ExecStartPre=/usr/sbin/sshd -t
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/usr/sbin/sshd -t
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartPreventExitStatus=255
Type=notify
RuntimeDirectory=sshd
RuntimeDirectoryMode=0755
[Install]
WantedBy=multi-user.target
Alias=sshd.service
The [Unit] section contains generic information about the service, like its description and manual page resources, as well as relations (dependency and order) to other services. The [Service] part contains the declarations related to the service execution (starting, stopping, killing, restarting), directories and configuration file(s) used. The last section, [Install], again carries generic information into which targets to install the service and, in this case, the alias that can be used instead of the service name. As you can see, there is very little code in there, only declarations. Systemd takes care of displaying progress reports, keeping track of the processes, and even restarting them when needed. The syntax of these files is fully described in several manual pages (e.g. systemd.service(5), systemd.unit(5), systemd.exec(5), etc.).
A systemd “.target file” describes a state of the system where a set of services are known to be operational. It can be thought of as an equivalent of the old-style runlevel. One of the pre-defined targets is local-fs.target; when it is reached, the rest of the system can assume that all local filesystems are mounted and accessible. Other targets include network-online.target and sound.target (for a full list of special targets see systemd.special(7)). The dependencies of a target can be listed either within the target file (in the Requires= line), or using a symbolic link to a service file in the /lib/systemd/system/targetname.target.wants/ directory. For instance, /etc/systemd/system/printer.target.wants/ contains a link to /lib/systemd/system/cups.service; systemd will therefore ensure CUPS is running in order to reach printer.target.
Com que els arxius d'unitats són declaratius en lloc de scripts o programes, no es poden executar directament, i només s'interpreten per systemd; diverses utilitats permeten a l'administrador interaccionar amb systemd i controlar l'estat del sistema i de cada component.
La primera utilitat d'aquest tipus és systemctl. Quan s'executa sense cap argument, llista tots els fitxers d'unitat coneguts per systemd (excepte els que han estat anul·lats), així com el seu estat. systemctl status ofereix una millor visió dels serveis, així com els processos relacionats. Si se li dona el nom d'un servei (com amb systemctl status ntp.service), retorna encara més detalls, així com les últimes línies de registre relacionades amb el servei (com es detallarà més endavant).
Engegar un servei manualment és simplement qüestió d'executar systemctl start nom-del-servei.service. Com es pot deduir, per aturar el servei es fa amb systemctl stop nom-del-servei.service; altres subordres inclouen reloadi restart.
Per controlar si un servei està activat (és a dir, si s'iniciarà automàticament en arrencar), utilitzeu systemctl enable nom-del-servei.service (o disable). is-enabled permet comprovar saber si està activat o no.
Una característica interessant de systemd és que inclou un component enregistrador anomenat journald. És un complement a sistemes de registre més tradicionals com ara syslogd, però aporta característiques interessants com un enllaç formal entre un servei i els missatges que genera, i la capacitat de capturar missatges d'error generats per la seva seqüència d'inicialització. Els missatges es poden mostrar més endavant, amb una mica d'ajuda de l'ordre journalctl. Sense cap argument, simplement mostrarà tots els missatges de registre generats des de l'arrencada del sistema; rarament s'utilitzarà d'aquesta manera. La majoria de vegades s'utilitzarà amb un identificador de servei:
# journalctl -u ssh.service
-- Logs begin at Tue 2015-03-31 10:08:49 CEST, end at Tue 2015-03-31 17:06:02 CEST. --
Mar 31 10:08:55 mirtuel sshd[430]: Server listening on 0.0.0.0 port 22.
Mar 31 10:08:55 mirtuel sshd[430]: Server listening on :: port 22.
Mar 31 10:09:00 mirtuel sshd[430]: Received SIGHUP; restarting.
Mar 31 10:09:00 mirtuel sshd[430]: Server listening on 0.0.0.0 port 22.
Mar 31 10:09:00 mirtuel sshd[430]: Server listening on :: port 22.
Mar 31 10:09:32 mirtuel sshd[1151]: Accepted password for roland from 192.168.1.129 port 53394 ssh2
Mar 31 10:09:32 mirtuel sshd[1151]: pam_unix(sshd:session): session opened for user roland by (uid=0)
Una altra opció útil de la línia d'ordres és -f, que indica a journalctlque continui mostrant els missatges nous a mesura que s'emeten (de manera similar a cat -f fitxer).
Si un servei no sembla estar funcionant com s'esperava, el primer pas per resoldre el problema és comprovar que el servei s'està executant amb systemctl status; si no ho està, i informació donada per l'anterior ordre no són suficients per diagnosticar el problema, es pot comprovar els registres recollits per journald sobre aquest servei. Per exemple, assumint que el servidor SSH no funciona:
# systemctl status ssh.service
● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled)
Active: failed (Result: start-limit) since Tue 2015-03-31 17:30:36 CEST; 1s ago
Process: 1023 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
Process: 1188 ExecStart=/usr/sbin/sshd -D $SSHD_OPTS (code=exited, status=255)
Main PID: 1188 (code=exited, status=255)
Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a
Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state.
Mar 31 17:30:36 mirtuel systemd[1]: ssh.service start request repeated too quickly, refusing to start.
Mar 31 17:30:36 mirtuel systemd[1]: Failed to start OpenBSD Secure Shell server.
Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state.
# journalctl -u ssh.service
-- Logs begin at Tue 2015-03-31 17:29:27 CEST, end at Tue 2015-03-31 17:30:36 CEST. --
Mar 31 17:29:27 mirtuel sshd[424]: Server listening on 0.0.0.0 port 22.
Mar 31 17:29:27 mirtuel sshd[424]: Server listening on :: port 22.
Mar 31 17:29:29 mirtuel sshd[424]: Received SIGHUP; restarting.
Mar 31 17:29:29 mirtuel sshd[424]: Server listening on 0.0.0.0 port 22.
Mar 31 17:29:29 mirtuel sshd[424]: Server listening on :: port 22.
Mar 31 17:30:10 mirtuel sshd[1147]: Accepted password for roland from 192.168.1.129 port 38742 ssh2
Mar 31 17:30:10 mirtuel sshd[1147]: pam_unix(sshd:session): session opened for user roland by (uid=0)
Mar 31 17:30:35 mirtuel sshd[1180]: /etc/ssh/sshd_config line 28: unsupported option "yess".
Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a
Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state.
Mar 31 17:30:35 mirtuel sshd[1182]: /etc/ssh/sshd_config line 28: unsupported option "yess".
Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a
Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state.
Mar 31 17:30:35 mirtuel sshd[1184]: /etc/ssh/sshd_config line 28: unsupported option "yess".
Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a
Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state.
Mar 31 17:30:36 mirtuel sshd[1186]: /etc/ssh/sshd_config line 28: unsupported option "yess".
Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a
Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state.
Mar 31 17:30:36 mirtuel sshd[1188]: /etc/ssh/sshd_config line 28: unsupported option "yess".
Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a
Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state.
Mar 31 17:30:36 mirtuel systemd[1]: ssh.service start request repeated too quickly, refusing to start.
Mar 31 17:30:36 mirtuel systemd[1]: Failed to start OpenBSD Secure Shell server.
Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state.
# vi /etc/ssh/sshd_config
# systemctl start ssh.service
# systemctl status ssh.service
● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled)
Active: active (running) since Tue 2015-03-31 17:31:09 CEST; 2s ago
Process: 1023 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
Main PID: 1222 (sshd)
CGroup: /system.slice/ssh.service
└─1222 /usr/sbin/sshd -D
#
Després de comprovar l'estat del servei («failed»), es passa a comprovar els registres; indiquen un error en el fitxer de configuració. Després d'editar el fitxer de configuració i esmenar l'error, es reinicia el servei, i després es verifica que efectivament s'està executant.
9.1.2. El sistema d'inici de System V
The System V init system (which we'll call init for brevity) executes several processes, following instructions from the /etc/inittab file. The first program that is executed (which corresponds to the sysinit step) is /etc/init.d/rcS, a script that executes all of the programs in the /etc/rcS.d/ directory.
Entre aquests, trobareu successivament programes encarregats de:
configurar el teclat de la consola;
carregar controladors: la majoria dels mòduls del nucli són carregats per ell mateix a mida que es detecta el maquinari; controladors addicionals són carregats automàticament quan els mòduls corresponents es llisten a /etc/modules;
verificar la integritat dels sistemes de fitxers;
muntar particions locals;
configurar la xarxa;
muntar sistemes de fitxers en xarxa (NFS).
Després d'aquesta etapa, init pren el control i inicia els programes habilitats en el nivell d'execució (o «runlevel») per defecte (que normalment és el nivell d'execució 2). Executa /etc/init.d/rc 2, un script que inicia tots els serveis que estan llistats a /etc/rc2.d/ i els noms dels quals comencen amb la lletra “S”. El número de dues xifres que segueix s'havia utilitzat històricament per definir l'ordre en què els serveis havien d'iniciar-se, però actualment el sistema d'arrencada per defecte utilitza insserv, que ho planifica tot automàticament basant-se en les dependències dels scripts. Així, cada script d'arrencada declara les condicions que s'han de complir per iniciar o aturar el servei (per exemple, si ha de començar abans o després d'un altre servei); init després les executa en l'ordre que compleix aquestes condicions. La numeració estàtica dels scripts ja no es té en compte (però sempre han de tenir un nom que comenci amb “S” seguit de dos dígits i el nom real de l'script utilitzat per a les dependències). En general, els serveis bàsics (com ara l'enregistrament amb rsyslog, o l'assignació de ports amb portmap) són iniciats primer, seguits pels serveis estàndard i la interfície gràfica (gdm3).
Aquest sistema d'arrencada basat en dependències fa possible automatitzar la “re-numeració”, que podria ser bastant tediosa si s'hagués de fer manualment, i limita els riscos de l'error humà, ja que la planificació es duu a terme d'acord amb els paràmetres indicats. Un altre avantatge és que els serveis poden ser engegats en paral·lel quan són independents els uns dels altres, la qual cosa pot accelerar el procés d'arrencada.
init distingeix diversos nivells d'execució, de manera que pot canviar d'un a un altre amb el comandament telinit nou-nivell. Immediatament, init executa /etc/init.d/rc de nou amb el nou nivell d'execució. Aquest script iniciarà els serveis que falten i aturarà els que ja no es volen. Per fer això, es refereix al contingut del /etc/rcX.d (on X representa el nou nivell d'execució). Els scripts que comencen amb “S” (de l'anglès «Start») són els serveis que s'iniciaran; els que comencen amb “K” (de l'anglès «Kill») són els serveis que s'aturaran. L'script no inicia cap servei que ja estigués actiu en el nivell d'execució anterior.
Per defecte, l'init de System V a Debian utilitza quatre nivells d'execució diferents:
El nivell 0 només s'utilitza temporalment, mentre l'ordinador s'està apagant. Com a tal, només conté scripts “K”.
El nivell 1, també conegut com a mode “mono-usuari”, correspon al sistema en mode degradat; inclou només serveis bàsics, i està destinat a operacions de manteniment on la interaccions amb usuaris ordinaris no són desitjades.
El nivell 2 és el nivell d'operació normal, que inclou serveis de xarxa, una interfície gràfica, inicis de sessió d'usuari, etc.
El nivell 6 és similar al nivell 0, però s'utilitza durant la fase d'aturada que precedeix un reinici.
Hi ha altres nivells, com ara del 3 al 5. Per defecte estan configurats per operar de la mateixa manera que el nivell 2, però l'administrador pot modificar-los (afegint o suprimint scripts als corresponents /etc/rcX.d) per adaptar-los a necessitats particulars.
All the scripts contained in the various /etc/rcX.d directories are really only symbolic links — created upon package installation by the update-rc.d program — pointing to the actual scripts which are stored in /etc/init.d/. The administrator can fine tune the services available in each runlevel by re-running update-rc.d with adjusted parameters. The update-rc.d(1) manual page describes the syntax in detail. Please note that removing all symbolic links (with the remove parameter) is not a good method to disable a service. Instead you should simply configure it to not start in the desired runlevel (while preserving the corresponding calls to stop it in the event that the service runs in the previous runlevel). Since update-rc.d has a somewhat convoluted interface, you may prefer using rcconf (from the rcconf package) which provides a more user-friendly interface.
Finalment, init inicia programes de control per a diverses consoles virtuals (getty). Mostra un indicador, esperant un nom d'usuari, i després executa login usuari per iniciar una sessió.
