pm-suspender vs systemctl suspender?

Em resumo, você geralmente deve preferir o modo de suspensão integrado pela sua distribuição. Para distribuições que enviam systemd, normalmente é systemctl suspend.

Por exemplo, o wiki do Arch Linux diz :

systemd fornece comandos nativos para suspensão, hibernação e suspensão híbrida, consulte "Gerenciamento de energia com systemd" para obter detalhes. Esta é a interface padrão usada no Arch Linux.

E para o Debian Jessie :

Com o systemd, pm-utilse seus ganchos não são mais usados, em vez disso, há systemd-suspend.

A razão pela qual você quer ficar com o que sua distro usa é que seus pacotes que se preocupam com suspender/retomar enviarão scripts de gancho que se integram com pm-utils( /usr/lib/pm-utils/sleep.d) ou systemd( /usr/lib/systemd/system-sleep/), então você deve usar a mesma interface para ter todas as ganchos são executados conforme o esperado.

Além disso, as distribuições normalmente conectam o método de suspensão/hibernação adequado na ACPI para eventos de hardware, ambientes de área de trabalho (para botões de desligamento que permitem suspender/hibernar) e com protetores/bloqueios de tela, etc.

Ambos pm-suspende systemd-suspendnormalmente usam as mesmas interfaces para realmente colocar o computador em suspensão.

Ambos usam como padrão o driver de suspensão do kernel (escrevendo em /sys/power/state) e ambos suportam drivers de suspensão externos (como uswsusp, veja aqui para obter detalhes sobre como conectá-lo ao systemd.)

Ambos suportam arquivos de configuração e scripts de gancho que são chamados no processo de suspensão ou retomada, sendo a principal diferença a localização dos arquivos (a API dos ganchos é muito semelhante):

• pm-utilslê sua configuração de arquivos /etc/pm/config.de executa ganchos de ambos /etc/pm/sleep.de /usr/lib/pm-utils/sleep.ddiretórios.
• systemd-suspendlê sua configuração do /etc/systemd/sleep.confarquivo (ou arquivos em um sleep.conf.ddiretório) e executa ganchos de /usr/lib/systemd/system-sleep/.

Então, desse ponto de vista, ambos parecem muito semelhantes...

Mas o systemd vai mais longe em seu suporte para suspender/hibernar/retomar, pois:

• Você pode conectar unidades do systemd no processo de suspensão/retomada, por exemplo, executando-as antes de suspender ou após a retomada. (Você pode encontrar ótimas receitas aqui .)
• O systemd suporta uma interface D-Bus, portanto, pode-se acionar a suspensão usando uma chamada D-Bus em vez de executar um comando (embora a execução systemctl suspendainda seja uma opção). útil a partir de um ambiente de desktop.
• O systemd possui uma interface avançada para notificar e fazer com que os aplicativos do espaço do usuário atrasem a suspensão enquanto estão concluindo as operações, a interface do inibidor , que é mais flexível e conveniente do que os scripts de gancho. (Na verdade, o systemd recomenda usar essa interface em vez de scripts de gancho sempre que possível.)

Então, mesmo que ambos pm-utilse systemd-suspendalcancem a suspensão real do sistema quase da mesma maneira, a integração com os outros componentes do sistema faz com que seja importante qual deles é chamado systemctl suspend... certo para chamar.