Parece que falhou ao iniciar:
jan 20 15:48:14 pedro-Aspire-E1-431 systemd[1]: Starting PEDRO swapoff antes do shutdown...
jan 20 15:48:15 pedro-Aspire-E1-431 systemd[1]: Failed to start PEDRO swapoff antes do shutdown.É. Falhou.
Vou olhar o arquivo de novo.
Mas pode mostrar o status dele com
systemctl status pedro_swapoff
● pedro_swapoff.service - PEDRO swapoff antes do shutdown
Loaded: loaded (/lib/systemd/system/pedro_swapoff.service; enabled; vendor preset: enabled)
Active: inactive (dead)Pedrão !
Desculpa incomodar mais uma vez. Mas para entender o motivo da falha, eu precisaria do resultado de :
type swapoff
type logger
ls -l /lib/systemd/system/pedro_swapoff.service
e
cat /lib/systemd/system/pedro_swapoff.service
Não precisa ser agora. Pode ser quando você tiver um tempo.
pedro@pedro-Aspire-E1-431:~$ type swapoff
swapoff é /sbin/swapoff
pedro@pedro-Aspire-E1-431:~$ type logger
logger é /usr/bin/logger
pedro@pedro-Aspire-E1-431:~$ ls -l /lib/systemd/system/pedro_swapoff.service
-rw-r--r-- 1 root root 276 jan 20 15:46 /lib/systemd/system/pedro_swapoff.service
pedro@pedro-Aspire-E1-431:~$ cat /lib/systemd/system/pedro_swapoff.service
[Unit]
Description=PEDRO swapoff antes do shutdown
Before=shutdown.target
DefaultDependencies=No
[Service]
Type=oneshot
ExecStart=/usr/bin/swapoff -a
ExecStart=/usr/bin/logger "PEDRO swapoff emitido..."
TimeoutStartSec=0
TimeoutStopSec=20
[Install]
WantedBy=shutdown.target
pedro@pedro-Aspire-E1-431:~$Ahhh !
Era o path do swapoff
A linha
ExecStart=/usr/bin/swapoff -a
Tem que ser
ExecStart=/sbin/swapoff -a
Agora parece que deu certo:
jan 20 16:17:55 pedro-Aspire-E1-431 systemd[1]: Starting PEDRO swapoff antes do shutdown...
jan 20 16:18:00 pedro-Aspire-E1-431 root[155958]: PEDRO swapoff emitido...
jan 20 16:18:00 pedro-Aspire-E1-431 systemd[1]: Finished PEDRO swapoff antes do shutdown.Ok.
Lembre-se que isso é uma “gambiarra” que nem sei se vai funcionar. Se estiver funcionando, o único jeito de voltar a investigar o problema (deixando ele ocorrer) é desabilitando esse serviço com :
systemctl disable pedro_swapoff
Aí, se o problema ocorrer, ver se aparece aquela mensagem que eu te falei.
É um RTA (Recursos Técnicos Alternativos) 
perdão não resisti… 
Ok. Mas se resolver, acho que por mim já está bom pra caramba. Vou ficar de olho nessa mensagem caso aconteça de novo. Obrigado!!
EDIT:
Assim que eu respondi aqui eu resolvi testar de novo e desligar. Acabou dando kernel panic de novo:
Tá complicado esse erro. Bom, pelo menos eu consegui dar uma olhada pra ver se aparecia a mensagem que você falou e não apareceu não (se apareceu foi rapido demais pra ler).
EDIT2:
Eu aproveitei e já rodei o comando journalctl -b -1 > journalsalvo.txt : The easiest way to host your text
EDIT3:
Tava olhando por cima, e na linha 2654 tá assim:
jan 20 19:05:32 pedro-Aspire-E1-431 systemd[1]: swapfile.swap: Failed with result 'exit-code'.
EDIT4:
Acho que eu descobri o problema. Parece que foi só o argumento do swapoff. Tem que trocar -a por --all.
EDIT5:
Não tenho certeza sobre essa troca. Nem parece fazer sentido, pelo que vi no man swapoff, pois são equivalentes, mas tem uma linha acusando que o argumento é inválido…
jan 20 19:05:31 pedro-Aspire-E1-431 swapoff[938788]: swapoff: /swapfile: swapoff falhou: Argumento inválido
Estou com o mesmo problema. Eu ia abrir o mesmo tópico aqui. Todo Linux Mint que eu instalo a parti do Mint 19.1 dá esse erro de na hora de desligar congela, só consigo desligar a máquina mantendo pressionado o botão de power. Testei o Lubuntu, Manjaro, Xubuntu, Zorin e Linux Lite todos com XFCE e o único que apresenta esse problema é o Mint da versão 19.1 pra cima. Eu consigo usar o Mint 19 aqui sem problemas, ele nunca deu esse erro, já usei quase um ano direto e sempre funcionou uma maravilha.
Comigo eu usei o 19.2 e 19.3, ambos com XFCE, pra mim foi uma das melhores experiências que tive com o Linux. Troquei pelo Xubuntu só pra experimentar, e fiquei por uns 6 meses, mas tinha uns bugs envolvendo a aceleração gráfica, que zuava as cores de alguns apps (dava pra resolver usando um comando na hora de lançar o app). Acabei voltando pro Mint, na versão 20, esperando que ia ter a mesma experiência que tive com os anteriores. Pra começar, eles desligaram o suporte de snaps, uma bela mancada (tive que habilitar manualmente), depois o bug da tela preta quando retorna de uma suspensão (dá pra digitar a senha e entrar na interface de volta mesmo com a tela preta, mas não deixa de ser irritante). E agora esse kernel panic. Pior que não escolhi o Mint atoa, é uma distro bem vista e considerada estável. Achei super estranho isso estar acontecendo.
Eu cheguei a usar todas essas distros que eu havia citado, mas o Linux Mint tem mesmo um diferencial. Espero que esses erro seja corrigido nas versões à frente. Gosto muito do Mint mas como tá, fica quase impossível de usar ele para trabalhar aqui.
Esse swapoff que deu erro aí, foi o emitido pelo próprio serviço de swap. Ele referencia especificamente o arquivo /swapfile que o nosso serviço sequer sabe que existe.
Você pode conferir dando duas vezes seguidas o comando
swapoff /swapfile
Na primeira, vai funcionar.
Na segunda, vai dar esse erro, porque o arquivo não está mais listado em
/proc/swaps
O problema nos dois logs que você mandou é que o sistema começa a fechar a session-c2.scope e 10 segundos depois, ele decide que não dá mais para esperar. Não vi onde configurar esse tempo, mas ainda estou me virando por aqui.
As mensagens no último log mostram bem essa situação. Às 19:05:15, ele sinaliza o fim da sessão. E às 19:05:25 ele sinaliza o time out.
jan 20 19:05:15 pedro-Aspire-E1-431 systemd-logind[892]: System is powering down.
jan 20 19:05:15 pedro-Aspire-E1-431 systemd[1]: Stopping Session c2 of user pedro.
:
:
jan 20 19:05:25 pedro-Aspire-E1-431 systemd[1]: session-c2.scope: Stopping timed out. Killing.
jan 20 19:05:25 pedro-Aspire-E1-431 systemd[1]: session-c2.scope: Killing process 1919 (rambox) with signal SIGKILL.
:
Mais um monte de kill
No primeiro, a situação é bem semelhante. Muda só a hora e a ordem na qual os serviços vão terminando. Mas 10 segundos depois, começa o massacre.
O fato é. Não é exatamente a área de swap. Esta é devidamente desabilitada pelo sistema. E mesmo que não fosse, o serviço que criamos força que seja, ainda durante a vigência da sessão.
Mas alguma situação acontece quando você desabilita o swap antes de iniciar o shutdown. E isso resulta em um shutdown normal. Quer dizer, não sei se é normal. Talvez fosse interessante você disponibilizar um log com o shutdown que não dá problema, também.
Estou desconfiado do serviço bamfdaemon. Durante o shutdown, ele fica reiniciando repetidas vezes (talvez porque o bus que ele queria ativo tenha dançado, ou coisa parecida).
Para testar essa hipótese, você precisaria editar o arquivo
/usr/lib/systemd/user/bamfdaemon.service
e comentar a última linha, colocando um “jogo-da-velha” no começo. Ela ficaria assim.
#Restart=on-failure
EM RESUMO
-
Parece existir um tempo de 10 segundos (que pode ser fixo ou ter algum modo de alterar) para a sessão do usuário terminar.
-
Decorrido esse tempo, ocorre a matança indiscriminada dos processos relacionados à sessão.
-
De algum modo que não está claro, isso resulta em um kernel panic
E é isso que está acontecendo com o teu sistema.
O que você poderia fazer
- disponibilizar um log de um shutdown normal
- testar o RTA (digo, a gambiarra) sugerido para o serviço bamfdaemon
Como eu disse lááááá no início, só investigando. E isso toma tempo, mesmo.
Entendi. Vou desligar agora e disponibilizar um log de um shutdown normal.
EDIT:
Aqui está o log para um shutdown normal: -- Logs begin at Thu 2020-12-17 21:32:12 -03, end at Thu 2021-01-21 07:23:54... - 6cc09583
Acabei de fazer o RTA ( ), qualquer novidade eu aviso.
Por incrível que pareça, o shutdown que termina normal não difere em nada do que termina bugado.
O time out ocorre da mesma maneira e a sequência de “Killing process …” também é executada.
O porquê de um resultar em kernel panic e outro não, é um mistério (por enquanto).
Bom, mais uma vez deu kernel panic.
Log: The easiest way to host your text
Antes de eu criar o tópico aqui, eu andei lendo tópicos de pessoas que tiveram um problema parecido com o meu. Eu topei com um tópico que apresentou um kernel panic muito parecido com o meu: Linux Mint não desliga - #15 by Deleterium .
Aparentemente ele resolveu o problema desinstalando o prelink, preload e o virtualbox. Só não testei a solução dele no dia que vi, porque fiquei com a impressão de que ele havia instalado esses programas por conta própria. Mas hoje fui checar no apt e vi que esses mesmos programas estão instalados no meu sistema. Imagino que no meu caso o virtualbox não tenha culpa, pois instalei ele depois dos kernel panics começarem. Mas vou testar a solução que ele encontrou, de repente resolve.
EDIT:
Poxa vida, acho que me enganei… Eles não estão instalados não. Rodei o apt purge e não encontrou. Só o virtualbox, claro, mas esse eu tinha instalado.
Pesquisando aqui eu achei esse tópico no VOL, pelo que parece funcionou com o autor do tópico, não sei se ai vai resolver também:
Linux Mint xfce não desliga o notebook [RESOLVIDO] [Linux Mint] (vivaolinux.com.br)
[SOLVED] Kernel panic - not syncing (Linux Mint 15) - Linux Mint Forums
Antes de mais nada, pode voltar o bamfdaemon.service para sua definição original, retirando aquele #
Eu também reparei que a lista de processos que são “assassinados” é praticamente a mesma, nos vários logs que você disponibilizou.
Em um shutdown normal, o que acontece é que o systemd manda o sinal SIGTERM para os processos que ainda estão rodando. Cada um precisa receber esse sinal e terminar normalmente.
Depois de um tempo, o systemd perde a paciência e manda um SIGKILL para os processos que não terminaram da forma natural.
Talvez o problema seja um desses caras. A verdadade mesmo é que a gente sequer identificou a causa do problema.
Mas existem alguns testes que você pode fazer.
- testar shutdown sem ninguém logado
não dar o shutdown dentro da sessão. Ao contrário, fazer logoff e dar o shutdown na tela de login. A justificativa é que, provavelmente os processos ativos serão obrigados a terminar. Mesmo assim, pode ser que algum fique pendurado.
- definir mais detalhes no log
A gente pode descer um pouco o nível colocando a opção
systemd.log_level=debug
Lá nos parâmetros de boot. O journal vai ficar consideravelmente maior, uma vez que a gente vai ver o que o systemd está fazendo com mais detalhes.
- salvar lista de serviços ativos no shutdown
A gente pode criar o seguinte script no usuário pedro.
#!/bin/sh
systemd-cgls > /home/pedro/listadecgroups.txt
E salvá-lo como, por exemplo, pedro_cgls.sh
Tem que dar permissão para execução
chmod 755 pedro_cgls.sh
Láááá naquele serviço que a gente criou, mudar a linha
ExecStart=/usr/sbin/swapoff -a
para
ExecStart=/home/pedro/pedro_cgls.sh
No próximo boot, dar uma verificada no conteúdo do listadecgroups.txt.
Quem sabe assim a gente possa ter uma ideia de quais serviços ainda estão ativos antes do systemd usar sua bomba de nêutrons na galera.