Сервис Crashplan предотвращает приостановку

После долгого процесса проб / ошибок я наконец-то определил службу аварийного закрытия как причину, по которой мой ноутбук не зависал после закрытия крышки. У меня есть два разных ноутбука с Ubuntu, оба страдают от этой проблемы ...

Я считаю, что будет сложно повлиять на план аварийного изменения, чтобы изменить это поведение, но мне было интересно, можно ли добавить действие, чтобы остановить аварийный план, когда крышка закрыта, и запустить его снова, когда она снова включена.

Есть мысли? Спасибо!

4
задан 4 June 2015 в 05:13

1 ответ

Прямой ответ на Ваш вопрос:

Можно использовать переключатель крышки для инициирования сценария, который останавливает услуги Crashplan. См. Сценарии Крышки и Прикрепления Ноутбука на Справке Wiki.

Также см. комментарии и ответы крышки Выгоды близко и открытых событий.

Существует также набор примеров для сценариев, записанных для различных видов людей событий, требуемых для инициирования с переключателем крышки на Форумах Ubuntu - немного хаотичный, но примеры могли быть полезными, поскольку Вы пишете Ваш.

Однако это не может на самом деле быть Crashplan, который является проблемой.

Если Ваш диск подкачки шифруется, который мог бы на самом деле быть тем, что вмешивается в спящий режим. (В некотором смысле, Crashplan, возможно, косвенно был причиной - я объясню больше...), Вы не могли сознательно настроить зашифрованный диск подкачки; это происходит автоматически, когда Вы принимаете решение зашифровать свой корневой каталог во время установки Ubuntu 9.10 и выше.

Кроме того, Вы никогда не могли замечать, что Ваш раздел подкачки был зашифрован, потому что у Вас все еще будет способность быть в спящем режиме, если Ваш fstab определит Вашу область подкачки UUID.

Это только становится проблемой, когда Ваша подкачка подвозит заливки (который она очень вероятно, возможно, сделала при выполнении Crashplan так как многие его процессы как восстановления файла являются долгими и ресурс / интенсивно использующими память). Когда полный, все о зашифрованной подкачке перезаписывается, включая UUID, таким образом, после попытки проснуться от спящего режима, Ваша система не знала бы, где найти Ваш диск подкачки - это будет искать UUID, который больше не существовал.

Таким образом, Вы, возможно, не должны писать "сервисный сценарий" остановки, активированный переключателем крышки вообще. Вы, возможно, просто должны иметь дело со своей подкачкой.

Две возможности:

  1. Изменение настроек так, чтобы диск подкачки был определен /dev/sdXX вместо UUID и также система предоставляется случайным образом сгенерированным ключом при необходимости (/dev/urandom). См. этот ответ для явных инструкций. Это включает редактирование crypttab и fstab, оба из которых необходимо создать резервную копию перед изменением.

  2. Выбор незашифрованной подкачки. Очевидно, последний не является рекомендуемым решением, но лично я думаю, что для среднего пользователя, это не огромное соглашение иметь незашифрованный раздел подкачки. Можно читать больше об этом и решить для себя. Посмотрите здесь для получения инструкций относительно того, как сделать это.

Также посмотрите Справку Ubuntu Wiki на протестах зашифрованного дома и как спящий режим затронут.

Примечание: Этому вопросу 2 года, поэтому даже при том, что было бы лучше получить больше информации перед ответом, я думал, что было маловероятно, что OP ответит, таким образом, я шел вперед и отправил ответ.

1
ответ дан 1 December 2019 в 10:41

Другие вопросы по тегам:

Похожие вопросы: