pm-suspend vs systemctl suspend?

Pour les distributions Linux utilisant systemd, existe-t-il une différence pratique entre ces deux commandes?

• systemctl suspend
• pm-suspend

Que dois-je utiliser ou préférer?

En bref, vous devriez généralement préférer le mode de suspension intégré par votre distribution. Pour les distributions qui expédient systemd, c'est généralement systemctl suspend.

Par exemple, le wiki Arch Linux dit :

systemd fournit des commandes natives pour suspendre, mettre en veille prolongée et une suspension hybride, voir "Gestion de l'alimentation avec systemd" pour plus de détails. Il s'agit de l'interface par défaut utilisée dans Arch Linux.

Et pour Debian Jessie :

Avec systemd, pm-utilset ses crochets ne sont plus utilisés, à la place systemd-suspend.

La raison pour laquelle vous voulez vous en tenir à ce que votre distribution utilise est que leurs packages qui se soucient de suspendre / reprendre expédieront des scripts de hook qui s'intègrent avec pm-utils( /usr/lib/pm-utils/sleep.d) ou systemd( /usr/lib/systemd/system-sleep/), vous devez donc utiliser la même interface afin d'avoir toutes les bonnes les crochets fonctionnent comme prévu.

De plus, les distributions connectent généralement la bonne méthode de suspension / mise en veille prolongée à ACPI pour les événements matériels, les environnements de bureau (pour les boutons d'arrêt qui permettent la suspension / mise en veille prolongée), et avec les économiseurs d'écran / verrous, etc.

Les deux pm-suspendet systemd-suspendutilisent généralement les mêmes interfaces pour réellement mettre l'ordinateur en veille.

Les deux utilisent par défaut le pilote de suspension du noyau (en écrivant à /sys/power/state) et prennent en charge les pilotes de suspension externes (tels que uswsusp, voir ici pour plus de détails sur la façon de le connecter à systemd.)

Ils prennent tous les deux en charge les fichiers de configuration et les scripts de hook qui sont appelés dans le processus de suspension ou de reprise, la principale différence étant l'emplacement des fichiers (l'API des hooks est très similaire):

• pm-utilslit sa configuration à partir des fichiers /etc/pm/config.det exécute les hooks des répertoires /etc/pm/sleep.det /usr/lib/pm-utils/sleep.d.
• systemd-suspendlit sa configuration à partir du /etc/systemd/sleep.conffichier (ou des fichiers d'un sleep.conf.drépertoire) et exécute les hooks à partir de /usr/lib/systemd/system-sleep/.

Donc, de ce point de vue, les deux se ressemblent beaucoup ...

Mais systemd va plus loin dans son support pour suspendre / hiberner / reprendre, car:

• Vous pouvez connecter des unités systemd au processus de suspension / reprise, par exemple en les exécutant avant la suspension ou après la reprise. (Vous pouvez trouver d'excellentes recettes ici .)
• systemd prend en charge une interface D-Bus, donc on peut déclencher la suspension en utilisant un appel D-Bus plutôt qu'en exécutant une commande (bien que l'exécution systemctl suspendsoit toujours une option.) Déclencher la suspension via D-Bus plutôt qu'en exécutant une commande est généralement utile à partir d'un environnement de bureau.
• systemd a une interface avancée pour notifier et faire suspendre les applications de l'espace utilisateur pendant la fin des opérations, l' interface inhibitrice , qui est plus flexible et pratique que les scripts de hook. (En fait, systemd recommande d'utiliser cette interface plutôt que les scripts de hook dans la mesure du possible.)

Donc, même si les deux pm-utilset systemd-suspendréalisent la suspension réelle du système de la même manière, l'intégration avec les autres composants du système fait en sorte qu'il importe que l'on s'appelle ... Et sur les distributions expédiant systemd, alors systemctl suspendest généralement le droit d'appeler.