comando não está sendo executado no cron (systemctl suspender)

8

Eu tenho este conjunto de tarefas:

* * * * * /usr/bin/systemctl suspend

E não está funcionando. Mas eu posso executá-lo em um shell e funciona. Eu não entendo o que poderia não estar funcionando.

EDITAR Redirecionar a saída de erro para /tmp/error fornece isso:

Failed to issue method call: Access denied
Failed to issue method call: Access denied

Minha pergunta é: Os cronjobs são executados como um usuário especial ( cron , por exemplo), o que explicaria que meu usuário pode executar o comando, mas não cron em si?

Explicação adicional:

  • Este é um exemplo mínimo para mostrar um problema que tenho em um script (isso faz mais sentido do que o único comando fornecido aqui)

  • systemctl faz parte de systemd . Acho que reinicialização, desligamento, suspensão estão funcionando com um usuário não raiz com systemd . Enfim, está funcionando no meu sistema.

  • Por fim, uso o Arch Linux e /bin , /usr/sbin , /sbin são todos links simbólicos para /usr/bin .

por Gradient 16.09.2013 / 01:05

5 respostas

4

Eu não posso realmente responder como tal, mas acho que posso apontar você na direção certa. Eu encontrei isso na página do Wiki do Arch de systemd :

polkit is necessary for power management. If you are in a local systemd-logind user session and no other session is active, the following commands will work without root privileges. If not (for example, because another user is logged into a tty), systemd will automatically ask you for the root password.

[list of various systemctl commands]

systemctl suspend

Isto sugere-me as seguintes possibilidades:

  1. Você tem outro usuário logado. Talvez você tenha feito login através de um tty?

  2. cron executa seus comandos usando /bin/sh . Por padrão , no Arch este é um symlink para /bin/bash . Isso significaria que cron está iniciando um shell bash não interativo que detecta que há outra sessão de usuário em execução (sua), portanto, não tem o direito de executar systemctl apesar de ser executado como usuário.

Então, se o seu problema é porque cron não tem permissão para executar systemctl porque você já está logado, você pode ser capaz de contornar isso jogando com polkit mas não tenho experiência, por isso não posso ajudar.

    
por 16.09.2013 / 06:21
1

Citações de aqui :

The other answer is great! But it requires root cron.

If you want to hibernate from non-sudo cron, there are 2 options:

1. Using polkit

Make a file containing the following:

[Enable hibernate to be run via 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 in the directory /etc/polkit-1/localauthority/50-local.d/.

Explanation is given here.

2. Using visudo

Quoting from here:

If users should only be allowed to use shutdown commands, but not have other sudo privileges, then, as root, add the following to the end of /etc/sudoers using the visudo command.

user hostname =NOPASSWD: /usr/bin/systemctl poweroff,/usr/bin/systemctl halt,/usr/bin/systemctl reboot

Substitute user for your username and hostname for the machine's hostname.
Now your user can shutdown with sudo systemctl poweroff, and reboot with sudo systemctl reboot. Users wishing to power down a system can also use sudo systemctl halt.
Use the NOPASSWD: tag only if you do not want to be prompted for your password.

     

No meu caso, a linha exata é:

anmol ALL=NOPASSWD: /bin/systemctl hibernate
     

(Observe que a localização de systemctl pode ser diferente em seu sistema.)

     

Depois disso, você pode escrever sudo systemctl hibernate fron cron para   hibernar.

     

Observação: modificar diretamente /etc/sudoers é    ruim ;   em vez disso, crie um arquivo sudoers personalizado sob /etc/sudoers.d/ usando o   comando - sudo visudo -f /etc/sudoers.d/custom .

    
por 12.06.2016 / 23:49
0

Se você estiver usando o crontab do sistema, esquecerá o campo do usuário. Experimente:

* * * * * root /usr/bin/systemctl suspend
    
por 16.09.2013 / 02:26
0

Uma solução fácil é usar o crontab do root em vez do seu próprio. Edite-o com:

$ sudo crontab -e

em vez de:

$ crontab -e
    
por 10.03.2017 / 12:23
0

Você precisa usar o arquivo de configuração systemd em /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
    
por 12.09.2017 / 16:09