pm-suspend vs systemctl suspend?

Para las distribuciones de Linux que usan systemd, ¿hay alguna diferencia práctica entre estos dos comandos?

• systemctl suspend
• pm-suspend

¿Cuál debería usar o preferir?

En resumen, generalmente debería preferir el modo de suspensión integrado por su distribución. Para las distribuciones que envían systemd, eso es típicamente systemctl suspend.

Por ejemplo, la wiki de Arch Linux dice :

systemd proporciona comandos nativos para suspender, hibernar y una suspensión híbrida; consulte "Administración de energía con systemd" para obtener más detalles. Esta es la interfaz predeterminada utilizada en Arch Linux.

Y para Debian Jessie :

Con systemd, pm-utilsy sus ganchos ya no se usan, en su lugar hay systemd-suspend.

La razón por la que desea seguir con lo que usa su distribución es que sus paquetes que se preocupan por suspender / reanudar enviarán scripts de gancho que se integran con pm-utils( /usr/lib/pm-utils/sleep.d) o systemd( /usr/lib/systemd/system-sleep/), por lo que debe usar la misma interfaz para tener todo el correcto ganchos corren como se esperaba.

Además, las distribuciones normalmente conectarán el método de suspensión / hibernación adecuado en ACPI para eventos de hardware, entornos de escritorio (para botones de apagado que permiten suspender / hibernar), y con protectores / bloqueos de pantalla, etc.

Ambos pm-suspendy systemd-suspendusan típicamente las mismas interfaces para realmente poner la computadora en suspensión.

Ambos utilizan de manera predeterminada el controlador de suspensión del kernel (al escribir en /sys/power/state) y ambos admiten controladores de suspensión externos (como uswsusp, consulte aquí para obtener detalles sobre cómo conectarlo a systemd).

Ambos admiten archivos de configuración y scripts de enlace que se llaman en el proceso de suspensión o reanudación, la principal diferencia es la ubicación de los archivos (la API de los enlaces es muy similar):

• pm-utilslee su configuración de archivos /etc/pm/config.dy ejecuta enlaces desde ambos /etc/pm/sleep.dy /usr/lib/pm-utils/sleep.ddirectorios.
• systemd-suspendlee su configuración del /etc/systemd/sleep.confarchivo (o archivos en un sleep.conf.ddirectorio) y ejecuta enlaces desde /usr/lib/systemd/system-sleep/.

Entonces, desde ese punto de vista, ambos se ven muy similares ...

Pero systemd va más allá en su soporte para suspender / hibernar / reanudar, ya que:

• Puede conectar unidades systemd al proceso de suspensión / reanudación, por ejemplo ejecutándolas antes de suspender o después de reanudar. (Puedes encontrar excelentes recetas aquí ).
• systemd admite una interfaz D-Bus, por lo que se puede activar la suspensión mediante el uso de una llamada D-Bus en lugar de ejecutar un comando (aunque la ejecución systemctl suspendsigue siendo, por supuesto, una opción). útil desde un entorno de escritorio.
• systemd tiene una interfaz avanzada para notificar y hacer que las aplicaciones del espacio de usuario retrasen la suspensión mientras completan las operaciones, la interfaz inhibidora , que es más flexible y conveniente que las secuencias de comandos de enlace. (De hecho, systemd recomienda usar esta interfaz en lugar de guiones de enlace siempre que sea posible).

Así que, aunque ambos pm-utilsy systemd-suspendlograr el real de suspensión del sistema en aproximadamente la misma forma, la integración con los otros componentes del sistema hace que sea tan es que importe cuál se llama ... Y en las distribuciones systemd envío, entonces systemctl suspendes típicamente el derecho a llamar.