Скрипт в /usr/lib/systemd/system-sleep не выполняется автоматически

[nok128]

Нужно запустить скрипт после выхода из ждущего режима. Прочитал, что это можно сделать с помощью systemd, который до и после ждущего режима автоматически выполнит все находящиеся в /usr/lib/systemd/system-sleep скрипты. Для тестирования данной возможности добавил в /usr/lib/systemd/system-sleep файл myscript.sh следующего содержания:

Код: Выделить всё

#!/bin/bash

notify-send "test"

Добавил файлу право исполняемости.
Но уведомление не выводится ни до входа в ждущий режим, ни после выхода из него. При этом если запустить его напрямую (./myscript.sh), уведомление выводится.

В чём может быть причина?

[rogoznik]

В чём может быть причина?

В том что в этом случае скрипты выполняются от суперпользователя, а у него к пользовательской X-сессии доступа нет

[nok128]

в этом случае скрипты выполняются от суперпользователя

А есть ли в таком случае возможность запустить команду внутри такого скрипта от имени пользователя? Я пробовал sudo -u <username> notify-send "test", но это не сработало.

[Sova]

В чём может быть причина?

Причина в том, что эти скрипты должны быть написаны определенным образом - зависит от того, должна ли выполняться команда (или команды) до входа в ждущий, после или в обоих случаях. Плюс, notify-send через Системду работаетет как-то иначе, чем просто из консоли. Попробуйте вот такой скрипт для проверки:

Код: Выделить всё

#!/bin/sh
case $1/$2 in
  pre/*)
    notify-send "Перед ждущим"
    ;;
  post/*)
    notify-send "После ждущего"
    ;;
esac

[slant]

А есть ли в таком случае возможность запустить команду внутри такого скрипта от имени пользователя? Я пробовал sudo -u <username> notify-send "test", но это не сработало.

И не должно.
Чтобы достучаться до чужих иксов, а для root иксы запущенные пользователем - чужие, и попытки изменить самого активного пользователя через sudo здесь никак не помогут, т.к. это будет НОВАЯ сессия другого пользователя, а не та где идет вывод на экран, нужно обращаться к dbus. В частности - есть dbus-launch. Там надо будет указать, к какой сессии цеплять запущенную программу.

[nok128]

Причина в том, что эти скрипты должны быть написаны определенным образом

Не соглашусь. Для примера скрипт следующего содержания:

Код: Выделить всё

#!/bin/bash
echo 'hello, world!' > ~/hello.txt

После выхода из ждущего режима в каталоге /root обнаруживается файл hello.txt с содержимым hello, world!

[nok128]

Причина в том, что эти скрипты должны быть написаны определенным образом

Не соглашусь. Для примера скрипт следующего содержания:

Код: Выделить всё

#!/bin/bash
echo 'hello, world!' > ~/hello.txt

После выхода из ждущего режима в каталоге /root обнаруживается файл hello.txt с содержимым hello, world!.

Тот вариант, что Вы предложили, ожидаемо не сработал.

[nok128]

Чтобы достучаться до чужих иксов, а для root иксы запущенные пользователем - чужие, и попытки изменить самого активного пользователя через sudo здесь никак не помогут, т.к. это будет НОВАЯ сессия другого пользователя, а не та где идет вывод на экран, нужно обращаться к dbus. В частности - есть dbus-launch. Там надо будет указать, к какой сессии цеплять запущенную программу.

Понял. Благодарю!

[yarichin]

echo 'hello, world!' > ~/hello.txt

А если так ?
echo 'hello, world!' > /home/$USER/hello.txt

[rogoznik]

А если так ?

Не сработает. Т.к. $USER вернет root

[slant]

Не сработает. Т.к. $USER вернет root

..либо вообще ничего, т.к. это переменная пользовательского окружения (интерактивного сеанса), а при вызове из под systemd далеко не обязательно эти переменные устанавливаются. Тут проверять надо, т.к. это в разных дистрибутивах по разному сделано.

[rogoznik]

slant, думал об этом, но не стал озвучивать, т.к. уже достаточно того, что вернет не то что ожидалось автором сообщения

[nok128]

А если так ?
echo 'hello, world!' > /home/$USER/hello.txt

Так проблема не в том, как записать файл в домашнюю директорию пользователя. Это как раз сделать не проблема. Запуск такого скрипта я продемонстрировал, чтобы доказать, что для запуска какого-либо скрипта из каталога /user/lib/systemd/system-sleep/ не требуется, чтобы скрипт был написан по какому-то установленному шаблону, как написали выше:

Причина в том, что эти скрипты должны быть написаны определенным образом