Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have this cronjob set :

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

And it is not working. But I can run it in a shell and it works. I don't understand what could be not working.

EDIT Redirecting error output to /tmp/error gives this :

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

My question is then : Are cronjobs run as a special user (cron for example), which would explain that my user can run the command, but not cron itself?

Additional explanation :

  • This is a minimal example to show a problem I have in a script (that makes more sense than the single command provided here)

  • systemctl is part of systemd. I think reboot, shutdown, suspend are working with a non-root user with systemd. Anyway, it is working on my system.

  • Finally, I use Arch Linux and /bin, /usr/sbin, /sbin are all symlinks to /usr/bin.

share|improve this question
1  
What exactly are you trying to do here? What does the command do when you run it in the shell? –  terdon Sep 16 '13 at 1:08
    
It suspends my computer –  Gradient Sep 16 '13 at 2:01
    
And do you want that to happen every minute? Your systemctl is in /usr/bin and it accepts suspend like that? What *nix are you using? –  terdon Sep 16 '13 at 2:02
    
No, it is an example. It is actually in a script that suspends when battery power is low. But this is the part in my script that is not working. I tried to give a minimal example of the problem (even if this seems to make no sense). –  Gradient Sep 16 '13 at 2:06
1  
OK,since this question is collecting close-votes, please edit it to add this extra info. Your distro is important (systemctl suspenddoesn't work on Debian or RedHat distros) and so is explaining that you don't actually want to do what you're showing :). Also, try adding 2> /tmp/error or something to capture any errors you might be getting. Finally, tell us which user is running this crontab. –  terdon Sep 16 '13 at 2:11

2 Answers 2

I can't really answer as such but I think I can point you in the right direction. I found this in the Arch Wiki page of 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

This suggests to me the following possibilities:

  1. You have another user logged in. Perhaps you have logged in via a tty?

  2. cron runs its commands using /bin/sh. By default, on Arch this is a symlink to /bin/bash. This would mean that cron is starting a non-interactive bash shell which then detects that there is another user session running (yours), so it does not have the right to run systemctl despite running as your user.

So, if your problem is because cron is not allowed to run systemctl because you are already logged in, you might be able to get around that by playing with polkit but I have no experience there so I can't help.

share|improve this answer
    
Thank you! The first option can be eliminated as I am able to execute the command in a shell. But I will do some more research about the second option. –  Gradient Sep 16 '13 at 4:29

If you're using the system crontab, then you forget the user field. Try:

* * * * * root /usr/bin/systemctl suspend
share|improve this answer
    
Are you sure there is a user field? I have never seen a cronjob with it before. Anyway, the command works when I run it as a user in a shell. –  Gradient Sep 16 '13 at 2:07
2  
@Gradient there is a user field if you are using /etc/crontab, is this a crontab you created with cron -e as your normal user? –  terdon Sep 16 '13 at 2:45
    
It is a crontab I created with crontab -e as a normal user. –  Gradient Sep 16 '13 at 2:49
    
your normal user account probably doesn't have permission to run systemctl suspend without sudo. –  cas Sep 16 '13 at 3:17

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.