Вопросы Теги

как захватить приостанавливание резюме из сценария удара

Это похоже на намеренную конфигурацию в Дуге Linux. Посмотрите это для обсуждения со ссылками на решения.

Лучшая подсказка там, кажется, добавляет "ДИСПЛЕЙ XAUTHORITY" к к "env_keep" значениям по умолчанию в /etc/sudoers.

Fedora имеет в /etc/sudoers следующее и это позволяют sudo somexapp успешно выполняться.

Defaults    env_reset
Defaults    env_keep =  "COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS"
Defaults    env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE"
Defaults    env_keep += "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES"
Defaults    env_keep += "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE"
Defaults    env_keep += "LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY"

2
17.04.2011, 15:25
2 ответа

Вы ищете сигналы SIGTSTP и SIGCONT. Попробуйте это:

trap onsuspend TSTP
trap onresume  CONT
4
27.01.2020, 22:01
  • 1
    Но обратите внимание, что Вы не можете поймать SIGSTOP, который является SIGKILL кому: SIGTSTP SIGTERM. (Другими словами, SIGTERM “умрите”, SIGKILL “Вы мертвы”, SIGTSTP “приостановите” и SIGSTOP “Вы временно отстранены”.) –  Gilles 'SO- stop being evil' 17.04.2011, 15:26
  • 2
    @Gilles да, но никакая нормальная программа отправит SIGCONT. Это также не позволяет терминальным программам очищать экран, потому что это не может быть обработано. Я никогда не видел его кроме тех случаев, когда я отправил его сам. Я, с другой стороны, видел, что программы обычно в способе сценариев завершения работы отправляют SIGKILL. –  penguin359 17.04.2011, 20:16
  • 3
    вышеупомянутое решение работает правильно, если я отправляю, уничтожает-SIGTSTP PID или SIGCONT. однако sigtstp, и sigcont, кажется, не отправляется, когда, например, Вы закрываете mbp крышку и открываете ее позже. Вы знаете то, что сигнализирует, что необходимо захватывать для тех? ноутбук –  Pradeep 17.04.2011, 22:26
  • 4
    приостанавливает / в спящем режиме, действительно событие в масштабе всей системы. Отдельные процессы не становятся уведомленными обычно. Могло бы быть udev/hal/dbus событие, за развитием которого можно следить, но это намного более сложно, чем ловля сигнала процесса. У Вас также не может быть времени, чтобы сделать что-либо, у меня нет большого опыта в этой области. –  penguin359 18.04.2011, 00:42
  • 5
    @Gilles @Pradeep я имел в виду SIGSTOP. Я никогда не видел, что любой процесс активно отправляет тот сигнал, только SIGTSTP. –  penguin359 18.04.2011, 00:46

Так как программа просто приостановлена и не надежно сказана, я вместо этого настроил бы именованный канал и породил бы сценарий сигнальной метки.

Это просто циклично выполнило бы каждые 5 или 15 минут, пишущий штамп текущего времени в именованный канал и затем спало бы.

Вы могли затем читать из того канала и сделать математику между чтениями - если время переходит больше чем один или два ping, то Вы спали.

В зависимости от того, как точный Вам требуются времена, Вы могли затем выследить файл /private/var/log/system.log (и потенциально/private/var/log/system.0.log.gz) для последнего сна / Стандартное время острова Уэйк, зарегистрированное ядром.

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

Шесть из один, полдюжины из другого.

0
27.01.2020, 22:01

Теги

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