오랜 시행착오 과정 끝에 마침내 덮개를 닫은 후에도 노트북이 일시 중지되지 않는 이유가 충돌 계획 서비스 때문이라는 것을 확인했습니다. 저는 두 개의 서로 다른 Ubuntu 노트북을 가지고 있는데, 둘 다 이 문제를 겪고 있습니다...
이 동작을 변경하기 위해 충돌 계획에 영향을 주기는 어려울 것이라고 생각하지만, 덮개가 닫힐 때 충돌 계획을 중지하고 다시 켜면 다시 시작하는 작업을 추가할 수 있는지 궁금합니다.
이견있는 사람? 감사해요!
답변1
귀하의 질문에 대한 직접적인 답변:
덮개 스위치를 사용하여 Crashplan 서비스를 중지하는 스크립트를 트리거할 수 있습니다. 보다노트북 덮개 및 도크 스크립트도움말 위키에 있습니다.
의 댓글과 답변도 참조하세요.뚜껑 닫기 및 열기 이벤트 잡기.
사람들이 뚜껑 스위치로 트리거하고 싶어하는 다양한 종류의 이벤트에 대해 작성된 스크립트에 대한 예제도 많이 있습니다.우분투 포럼에서--약간 혼란스럽긴 하지만 예제를 작성하는 데 도움이 될 수 있습니다.
그러나 실제로 문제가 되는 것은 Crashplan이 아닐 수도 있습니다.
스왑 드라이브가 암호화된 경우 실제로 최대 절전 모드를 방해할 수 있습니다.(어떤 면에서는 Crashplan이 간접적으로 원인일 수도 있습니다. 더 설명하겠습니다...) 암호화된 스왑 드라이브를 고의로 설정하지 않았을 수도 있습니다. 이는 Ubuntu 9.10 이상을 설치하는 동안 홈 디렉터리를 암호화하도록 선택하면 자동으로 발생합니다.
또한 fstab이 UUID로 스왑 공간을 식별하는 경우 최대 절전 모드 기능을 사용할 수 있기 때문에 스왑 파티션이 암호화되었다는 사실을 전혀 눈치채지 못했을 수도 있습니다.
이는 스왑 드라이브가 가득 찼을 때만 문제가 됩니다(Crashplan을 실행하는 동안 수행했을 가능성이 매우 높습니다., 파일 복원과 같은 많은 프로세스는 시간이 오래 걸리고 리소스/메모리를 많이 사용하기 때문입니다. 가득 차면 UUID를 포함하여 암호화된 스왑에 관한 모든 내용을 덮어쓰므로 최대 절전 모드에서 깨어나려고 하면 시스템은 스왑 드라이브를 찾을 위치를 알 수 없습니다. 즉, 더 이상 존재하지 않는 UUID를 검색하게 됩니다. .
따라서 덮개 스위치로 활성화되는 "서비스 중지" 스크립트를 작성할 필요가 전혀 없을 수도 있습니다. 스왑을 처리해야 할 수도 있습니다.
두 가지 가능성은 다음과 같습니다.
스왑 드라이브가
/dev/sdXXUUID 대신에 식별되고 필요할 때 무작위로 생성된 키가 시스템에 제공되도록 설정을 수정합니다(/dev/urandom). 보다이 답변명시적인 지시를 위해. 여기에는 crypttab 및 fstab 편집이 포함되며, 둘 다 변경하기 전에 백업해야 합니다.암호화되지 않은 스왑을 선택합니다. 분명히 후자는 권장되는 솔루션은 아니지만 개인적으로 일반 사용자에게는 암호화되지 않은 스왑 파티션을 갖는 것이 큰 문제가 아니라고 생각합니다. 이에 대해 자세히 읽어보고 스스로 결정할 수 있습니다. 보다여기그 방법에 대한 지침을 확인하세요.
또한우분투 도움말 위키암호화된 집의 주의 사항과 최대 절전 모드가 어떻게 영향을 받는지에 대해 알아보세요.
참고: 이 질문은 2년 된 질문이므로 답변하기 전에 더 많은 정보를 얻는 것이 가장 좋겠지만 OP가 응답할 가능성은 거의 없다고 생각하여 답변을 게시했습니다.