команда, не работающая в кроне (systemctl приостанавливают),

Это:

  • Копия: cp file_name <directory|file_name>
  • Перемещение: mv file_name <directory|file_name>
  • Удалите: rm file_name

Посетите их man страницы для получения дополнительной информации.

12
16.09.2013, 05:31
6 ответов

Я не могу действительно ответить как таковой, но я думаю, что могу указать на Вас в правильном направлении. Я нашел это на странице Arch Wiki systemd:

polkit необходим для управления питанием. Если Вы будете на локальном systemd-logind сеансе пользователя, и никакая другая сессия не активна, то следующие команды будут работать без полномочий пользователя root. Если не (например, потому что другой пользователь зарегистрирован в tty), systemd автоматически попросит у Вас пароля root.

[список различных команд systemctl]

systemctl приостанавливают

Это предлагает мне следующие возможности:

  1. У Вас есть другой зарегистрированный пользователь. Возможно, Вы зарегистрировали на пути tty?

  2. cron выполняет его использование команд /bin/sh. По умолчанию на Arch это - символьная ссылка на /bin/bash. Это означало бы это cron запускает неинтерактивную оболочку удара, которая затем обнаруживает, что существует другой сеанс пользователя, выполняющий (Ваш), таким образом, он не имеет права работать systemctl несмотря на выполнение как Ваш пользователь.

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

6
27.01.2020, 19:56
  • 1
    ! Первая опция может быть устранена, поскольку я могу выполнить команду в оболочке. Но я проведу еще некоторое исследование о второй опции. –  Gradient 16.09.2013, 07:29
  • 2
    @Gradient Вы обнаруживали, как зафиксировать это? Я борюсь с той же проблемой. круглые скобки –  AkiRoss 16.02.2015, 03:50
  • 3
    Вы могли объяснить вторую возможность более подробно? Там какой-либо путь состоит в том, чтобы подтвердить, что это - действительно проблема? Я выполнился w и uptime из скриптов, запущенных кроном. Их выводы, обозначенные, были только пользователем. Так, это означает, что существует некоторая другая проблема? –  Anmol Singh Jaggi 11.06.2016, 11:29

Если Вы используете систему crontab, то Вы забываете пользовательское поле. Попробуйте:

* * * * * root /usr/bin/systemctl suspend
0
27.01.2020, 19:56
  • 1
    Вы уверены, что существует пользовательское поле? Я никогда не видел cronjob с ним прежде. Так или иначе команда работает, когда я выполняю ее как пользователь в оболочке. –  Gradient 16.09.2013, 05:07
  • 2
    @Gradient там является пользовательским полем, если Вы используете /etc/crontab, это crontab, с которым Вы создали cron -e как Ваш обычный пользователь? –  terdon♦ 16.09.2013, 05:45
  • 3
    Это - crontab, с которым я создал crontab -e как обычный пользователь. –  Gradient 16.09.2013, 05:49
  • 4
    Ваша учетная запись обычного пользователя, вероятно, не имеет разрешения работать systemctl suspend без sudo. –  cas 16.09.2013, 06:17

Цитирую по здесь:

Другой ответ - это здорово! Но он требует root cron.

Если вы хотите впадать в спячку из не-судового cron, есть 2 варианта:

1. Используя polkit

Сделать файл, содержащий следующее:

[Разрешить запуск hibernate через cron]
Identity=unix-user:*
Action=org.freedesktop.login1.hibernate;org.freedesktop.login1.hibernate-multiple-sessions
ResultAny=yes 

named com.0.enable-hibernation-from-cron.pkla в каталоге /etc/polkit-1/localauthority/50-local.d/.

Объяснение дано here.

2. Использование visudo

Цитирую по. здесь:

Если пользователям должно быть разрешено только использовать команды выключения, но не иметь другие привилегии sudo, то, как root, добавьте следующее в конец файла /etc/sudoers используя команду visudo.

имя хоста пользователя =NOPASSWD: /usr/bin/systemctl poweroff,/usr/bin/systemctl halt,/usr/bin/systemctl reboot

Замените user на ваше имя пользователя и hostname на имя хоста машины.
Теперь ваш пользователь может выключить машину с помощью sudo systemctl poweroff, и перезагрузить ее с помощью sudo systemctl reboot. Пользователи, желающие выключить систему, могут также использовать sudo systemctl halt.
Используйте тег NOPASSWD: только в том случае, если вы не хотите, чтобы у вас запрашивали пароль.

В моем случае точная строка выглядит так:

anmol ALL=NOPASSWD: /bin/systemctl hibernate

(Обратите внимание, что расположение systemctl может быть другим в вашей системе).

После этого вы можете написать sudo systemctl hibernate fron cron, чтобы hibernate.

Примечание: Прямая модификация /etc/sudoers является. bad; вместо этого создайте пользовательский файл sudoers в /etc/sudoers.d/ используя команду - sudo visudo -f /etc/sudoers.d/custom.

1
20.08.2021, 13:05

Простым обходным решением является использование корневого файла crontab вместо вашего собственного. Отредактируйте его:

$ sudo crontab -e

вместо:

$ crontab -e
4
20.08.2021, 13:05

Вам нужно использовать файл конфигурации systemd в/etc/systemd/system

[Unit]
Description=Pimcore Events Processor

[Service]
WorkingDirectory=/var/www/html
ExecStart=/usr/bin/php run something
Restart=always
WatchdogSec=300 #in seconds
User=www-data
Group=www-data

[Install]
WantedBy=multi-user.target
-1
20.08.2021, 13:05

Существует гораздо более простое решение без sudo, с помощью systemd -run:

Важно то, что вы должны установить/экспортировать переменную окружения DBUS _SESSION _BUS _ADDRESS для соответствующего пользователя. Просто создайте скрипт с именем systemctl-suspendили что-то вроде этого со следующими строками:

#!/bin/bash
# This is a workaround script to be able to use 'systemctl suspend' in user-cron
PATH=/usr/bin
export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/"$(id -u "$LOGNAME")"/bus
systemd-run --user systemctl suspend

и сделайте его исполняемым, а затем скопируйте этот файл сценария в папку, например /usr/local/bin.

Наконец, запустите скрипт в пользовательском crontab вот так:

0 22 * * * /usr/local/bin/systemctl-suspend

Протестировано на Debian 10 (buster )...

1
20.08.2021, 13:05

Теги

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