Overblog
Editer l'article Suivre ce blog Administration + Créer mon blog

          Global Informatique Securite

Global Informatique Securite

Suivez les dernières actualités, sécurité informatique "Bugs & failles". Tenez-vous Informé des dernières Technologies et Optimisation système


Linux ! Nettoyage de votre processus de démarrage

Publié par Yomane sur 19 Mai 2019, 11:33am

Catégories : #Spécial Linux, #configurations, #débutant Linux

Article pour débutant Linuè °

La distribution Linux à usage général moyenne lance toutes sortes de choses au démarrage, y compris de nombreux services qu'il n'est pas nécessaire d'exécuter. Bluetooth, Avahi, ModemManager, ppp-dns…

Quelles sont ces choses et qui en a besoin?

systemd linux service démarrage init systeme exploitation os optimisation

Systemd fournit de nombreux outils pour voir ce qui se passe lors du démarrage de votre système et contrôler ce qui commence au démarrage. Dans cet article, je vais vous montrer comment désactiver le démarrage cruel sur les distributions Systemd.

Voir les services de démarrage

Dans l'ancien temps, vous pouviez facilement voir quels services étaient lancés au démarrage en regardant dans /etc/init.d . Systemd fait les choses différemment. Vous pouvez utiliser l'incantation suivante pour répertorier les services de démarrage activés:

systemctl list-unit-files --type=service | grep enabled
accounts-daemon.service                    enabled 
anacron-resume.service                     enabled 
anacron.service                            enabled 
bluetooth.service                          enabled 
brltty.service                             enabled
[...]

Et, près du sommet, se trouve mon ennemi personnel: le Bluetooth. Je ne l'utilise pas sur mon PC et je n'ai pas besoin de le faire fonctionner. Les commandes suivantes l’arrêtent puis l’empêchent de démarrer au démarrage:

$ sudo systemctl stop bluetooth.service
$ sudo systemctl disable bluetooth.service

Vous pouvez confirmer en vérifiant le statut:

$ systemctl status bluetooth.service
 bluetooth.service - Bluetooth service
  Loaded: loaded (/lib/systemd/system/bluetooth.service; disabled; vendor preset: enabled)
  Active: inactive (dead)
    Docs: man:bluetoothd(8)

Un service désactivé peut être démarré par un autre service. Si vous le voulez vraiment, sans le désinstaller, vous pouvez le masquer pour l'empêcher de démarrer quelles que soient les circonstances:

$ sudo systemctl mask bluetooth.service
 Created symlink from /etc/systemd/system/bluetooth.service to /dev/null.

Une fois que vous êtes convaincu que la désactivation d’un service n’a pas d’effets secondaires néfastes, vous pouvez choisir de le désinstaller.

Vous pouvez générer une liste de tous les services:

$ systemctl list-unit-files --type=service                       
UNIT FILE                                  STATE   
accounts-daemon.service                    enabled 
acpid.service                              disabled
alsa-restore.service                       static    
alsa-utils.service                         masked 

Vous ne pouvez pas activer ou désactiver les services statiques, car ceux-ci sont des dépendances d'autres services systemd et ne sont pas conçus pour être exécutés par eux-mêmes.

Puis-je me débarrasser de ces services?

Comment savez-vous ce dont vous avez besoin et ce que vous pouvez désactiver en toute sécurité? Comme toujours, cela dépend de votre configuration particulière.

Voici un échantillon de services et leur utilité. De nombreux services sont spécifiques à la distribution. Gardez donc votre documentation de distribution à portée de main (Google et Stack Overflow, par exemple).

  • accounts-daemon.service est un risque potentiel pour la sécurité. Il fait partie de AccountsService, qui permet aux programmes d'obtenir et de manipuler les informations de compte d'utilisateur. Je ne peux pas penser à une bonne raison d'autoriser ce genre d'opération derrière le dos, alors je le masque.
  • avahi-daemon.service est censé fournir une découverte de réseau sans configuration et rendre très facile la recherche d'imprimantes et d'autres hôtes sur votre réseau. Je le désactive toujours et ne le manque pas.
  • brltty.service prend en charge les périphériques braille, par exemple les afficheurs braille.
  • debug-shell.service ouvre une faille de sécurité énorme et ne doit jamais être activé, sauf lorsque vous l'utilisez. Ceci fournit un shell root sans mot de passe pour aider au débogage des problèmes de systemd.
  • ModemManager.service est un démon activé par DBus qui contrôle les interfaces large bande mobile (2G / 3G / 4G). Si vous ne disposez pas d'une interface haut débit mobile - intégrée, couplée à un téléphone portable via Bluetooth ou un dongle USB - vous n'en avez pas besoin.
  • pppd-dns.service est une relique du passé sombre. Si vous utilisez Internet par ligne commutée, conservez-le. Sinon, vous n'en avez pas besoin.
  • rtkit-daemon.service semble effrayant, comme rootkit, mais vous en avez besoin, car il s'agit du planificateur de noyau en temps réel.
  • whoopsie.service est le service de rapport d'erreurs Ubuntu. Il collecte les rapports d'incident et les envoie à https://daisy.ubuntu.com . Vous pouvez le désactiver en toute sécurité ou vous pouvez le supprimer définitivement en désinstallant apport.
  • wpa_supplicant.service est nécessaire uniquement si vous utilisez une interface réseau Wi-Fi.

Que se passe-t-il pendant le démarrage?

Systemd a quelques commandes pour aider à résoudre les problèmes de démarrage. Cette commande reproduit tous vos messages de démarrage:

$ journalctl -b

-- Logs begin at Mon 2016-05-09 06:18:11 PDT, 
end at Mon 2016-05-09 10:17:01 PDT. --
May 16 06:18:11 studio systemd-journal[289]: 
Runtime journal (/run/log/journal/) is currently using 8.0M.
Maximum allowed usage is set to 157.2M.
Leaving at least 235.9M free (of currently available 1.5G of space).
Enforced usage limit is thus 157.2M.
[...]

Vous pouvez consulter les bottes précédentes avec journalctl -b -1 , qui affiche le démarrage précédent; journalctl -b -2 montre il y a deux bottes, et ainsi de suite.

Cela génère une quantité gigantesque de résultats, ce qui est intéressant mais peut-être pas si utile. Il a plusieurs filtres pour vous aider à trouver ce que vous voulez. Regardons le PID 1, qui est le processus parent pour tous les autres processus:

$ journalctl _PID=1

May 08 06:18:17 studio systemd[1]: Starting LSB: Raise network interfaces....
May 08 06:18:17 studio systemd[1]: Started LSB: Raise network interfaces..
May 08 06:18:17 studio systemd[1]: Reached target System Initialization.
May 08 06:18:17 studio systemd[1]: Started CUPS Scheduler.
May 08 06:18:17 studio systemd[1]: Listening on D-Bus System Message Bus Socket
May 08 06:18:17 studio systemd[1]: Listening on CUPS Scheduler.
[...]

Cela montre ce qui a été démarré ou tenté de démarrer.

L'un des outils les plus utiles est Systemd-Analyze Blame ,ou Systemd-Analyze critical-chain qui indiquent quels services prennent le plus de temps à démarrer ou sont critique en tant de démarrage.

$ systemd-analyze blame
         8.708s gpu-manager.service
         8.002s NetworkManager-wait-online.service
         5.791s mysql.service
         2.975s dev-sda3.device
         1.810s alsa-restore.service
         1.806s systemd-logind.service
         1.803s irqbalance.service
         1.800s lm-sensors.service
         1.800s grub-common.service

Cet exemple particulier ne montre rien d'inhabituel, mais s'il existe un goulot d'étranglement au démarrage, cette commande le trouvera..

$ systemd-analyze critical-chain 
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @6min 11.677s
└─multi-user.target @6min 11.677s
 └─getty.target @44.070s
   └─getty@tty1.service @44.069s
     └─systemd-user-sessions.service @37.383s +21ms 
       └─nss-user-lookup.target @30.315s
         └─nscd.service @24.966s +5.123s 
           └─basic.target @24.828s
             └─sockets.target @24.828s
               └─avahi-daemon.socket @24.828s
                 └─sysinit.target @24.741s
                   └─sys-fs-fuse-connections.mount @4min 50.752s +12ms 
                     └─systemd-modules-load.service @5.047s +374ms 
                       └─systemd-journald.socket
                         └─-.mount
                           └─systemd-journald.socket
                             └─...

-----------------------------------------------------------------------------------------------------------------------------

De plus, si vous êtes intéressé par la lecture de tels articles, veillez à suivre ce blog en cliquant sur le bouton "S'abonner". 

Commentez ci-dessous ou partagez-le avec nous sur Groupe Facebook , Page Facebook Twitter  Canal Discord 

 Utilisateur PC et  macOS , : News Républic est disponible dans votre store pour suivre notre actualité  "Global Informatique

Pour être informé des derniers articles, inscrivez vous :

Commenter cet article

Archives

Nous sommes sociaux !

Articles récents