Início / user-74516

vinc17's questions

Martin Hope
vinc17
Asked: 2024-05-26 06:57:38 +0800 CST
  • 5

Ao reiniciar minha máquina Debian, obtive um tempo limite de 90 anos do xdg-document-portalserviço:

May 25 22:52:02 qaa systemd[2230]: Stopping xdg-document-portal.service - flatpak document portal service...
[...]
May 25 22:52:04 qaa systemd[1]: Started plymouth-reboot.service - Show Plymouth Reboot Screen.
May 25 22:52:04 qaa systemd[1]: plymouth-switch-root-initramfs.service - Tell Plymouth To Jump To initramfs was skipped because no trigger condition checks were met.
May 25 22:53:32 qaa systemd[2230]: xdg-document-portal.service: State 'stop-sigterm' timed out. Killing.
May 25 22:53:32 qaa systemd[2230]: xdg-document-portal.service: Killing process 116031 (xdg-document-po) with signal SIGKILL.
May 25 22:53:32 qaa systemd[2230]: xdg-document-portal.service: Killing process 116037 (fusermount3) with signal SIGKILL.
May 25 22:53:32 qaa systemd[2230]: xdg-document-portal.service: Main process exited, code=killed, status=9/KILL
May 25 22:53:32 qaa systemd[2230]: xdg-document-portal.service: Failed with result 'timeout'.
May 25 22:53:32 qaa systemd[2230]: Stopped xdg-document-portal.service - flatpak document portal service.

(isto é do bug 1071919 do Debian ).

Os anos 90 são muito longos e gostaria de reduzir esse atraso. Como?

Obs: já tenho um /etc/systemd/system.conf.d/stop-timeout.confarquivo com

[Manager]
# Note[VL]: The default 90s timeout for stopping of units is much too long!
# In general, the timeout is reached, as some unit is frozen or does not
# react. So, let us decrease it to a value that would be less annoying.
DefaultTimeoutStopSec=20s

e pensei que isso fosse suficiente (não há outra configuração de tempo limite no /etc/systemddiretório). Mas como você pode ver, não é.

linux
Martin Hope
vinc17
Asked: 2023-09-11 20:58:13 +0800 CST
  • 5

O badblocksutilitário permite encontrar blocos defeituosos em um dispositivo e e2fsck -cadicionar esses blocos defeituosos ao inode do bloco defeituoso para que eles não sejam usados ​​para dados reais. Mas para SSD, sabe-se que setores defeituosos são normalmente realocados (remapeados) de forma transparente pela unidade (no entanto, somente quando ocorre uma gravação). Então, faz algum sentido usar badblocks/ e2fsck -cem um SSD?

eu suponho que

  • badblockspor si só pode fazer sentido obter informações sobre a saúde do SSD, por exemplo, considerando o número total de blocos defeituosos (não sei se o smartctlsmartmontools pode fazer a mesma coisa... talvez com um teste longo smartctl -t long, mas não consegui). não vi nenhuma documentação clara);
  • seu uso deve ser desencorajado e2fsck -c(que adiciona blocos defeituosos ao inode de bloco defeituoso), pois devido à possível realocação, os números associados (endereços lógicos?) podem se tornar obsoletos.

Mas não há nenhum aviso sobre o caso do SSD nas páginas de manual desses utilitários. Então estou me perguntando...

ssd