Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sometimes i have issues with cron jobs not running, and diagnosing why can be difficult. What would be useful is to switch to the same user as the cron jobs run under, so i can see if there's a permissions hassle or something. Can anyone tell me how to do this? My linux version, from uname -r, is 2.6.32-36-generic

cheers, max

EDIT - btw i know how to switch users! My question is more about finding out which user to switch to.

EDIT - in my current problem i have a line in the crontab which works when i paste it into a terminal (in any folder) but fails when run from cron. I'm trying to work out why. I'm giving the full path to any files used.

42 13 * * * cd /path/to/my/working/folder && /path/to/my/working/folder/script/runner 'MusicService.update_cached_data' -e staging

(The 42 13 time is there because that's the last time i tested it)

share|improve this question
    
cronjobs run as whatever user set the crontab up. They don't run as a special user. –  terdon May 28 '13 at 11:57
    
Thanks - How do i see which user set the crontab up? –  Max Williams May 28 '13 at 12:36
    
Hang on, if you have access to the crontab it is you who set it up. I don't see why you are wondering which user did it if you did it yourself! –  terdon May 28 '13 at 12:52
    
if you don't know who scheduled the job, have a look at the logs, eg /var/log/cron or /var/log/cron.log or /var/log/syslog, it should tell you who set up the cron entry. Then as terdon said, you can do crontab -l under the given user's profile –  Petkaux May 28 '13 at 12:52
    
If the exact same command works from the CLI and not from cron you may have some problems with variables not being exported. Try capturing the error output of the cron: [...] 'MusicService.update_cached_data' -e staging 2> ~/error –  terdon May 28 '13 at 12:54
show 1 more comment

2 Answers

up vote 5 down vote accepted

Cronjobs run as whatever user set the crontab up. They don't run as a special user. Usually, if you know a crontab exists, you know who set it up. You can see the crontabs of the current user by running

crontab -l

You can find user-specific crontabs in the directory /var/spool/cron/crontabs/. Each user who has created a crontab will have a file (whose name is the user's name) in that directory. By default, those files are only readable by the user who created them, so you cannot cat them without playing around with their permissions.

This little scriptlet will list all cron commands for each user:

for u in $(find /var/spool/cron/crontabs/ -type f); do 
 user=`basename $u`; 
 echo "------- $user ----"; 
 crontab -u  $user -l | grep -v "#"; 
done

That will list all cronjobs for each of the users that have a crontab file in /var/spool/cron/crontabs/.

Finally, you also have the system-wide crontabs that are in /etc/crontab which you can see by running cat /etc/crontab.


In answer to your comment, if you want to load specific variables that are defined in a given file, you can source that file in your crontab:

42 13 * * * . ~/.bashrc && cd /path/to/my/working/folder && /path/to/my/working/folder/script/runner 'MusicService.update_cached_data' -e staging

That is . followed by the file you want to load.


Finally, here is some relevant information from man 5 crontab :

   An active line in a crontab will be either  an  envi‐
   ronment  setting or a cron command.  The crontab file
   is parsed from top to bottom, so any environment set‐
   tings  will  affect only the cron commands below them
   in the file.  An environment setting is of the form,

       name = value

   where  the  spaces  around  the  equal-sign  (=)  are
   optional,  and  any  subsequent non-leading spaces in
   value will be part of the  value  assigned  to  name.
   The  value  string may be placed in quotes (single or
   double, but matching) to preserve leading or trailing
   blanks.  To  define an empty variable, quotes must be
   used. The value string is not parsed for  environmen‐
   tal  substitutions  or replacement of variables, thus
   lines like

       PATH = $HOME/bin:$PATH

   will not work as you might expect.

   An alternative for setting up the  commands  path  is
   using  the  fact  that  many  shells  will  treat the
   tilde(~) as substitution of $HOME, so if you use bash
   for your tasks you can use this:

        SHELL=/bin/bash
        PATH=~/bin:/usr/bin/:/bin

   [...]

   Several  environment  variables  are set up automati‐
   cally  by  the  cron(8)  daemon.   SHELL  is  set  to
   /bin/sh,  and  LOGNAME  and  HOME  are  set  from the
   /etc/passwd line of the crontab's owner. PATH is  set
   to  "/usr/bin:/bin".   HOME,  SHELL,  and PATH may be
   overridden by settings in the crontab; LOGNAME is the
   user  that  the  job  is running from, and may not be
   changed.

   [...]

   On the Debian GNU/Linux  system,  cron  supports  the
   pam_env  module,  and loads the environment specified
   by /etc/environment  and  /etc/security/pam_env.conf.
   It     also    reads    locale    information    from
   /etc/default/locale.  However, the  PAM  settings  do
   NOT  override  the  settings  described above nor any
   settings in the crontab file itself. Note in particu‐
   lar   that   if   you   want   a   PATH   other  than
   "/usr/bin:/bin", you will  need  to  set  it  in  the
   crontab file.
share|improve this answer
    
Thanks a lot @terdon. I have two users on this server: "root" and "deploy". I log in as "deploy" and i can see from your script that the "deploy" user owns the crontab which i'm editing with "crontab -e". So it should all be fine right? Is there a cron log where i could see commands which fail, or something? –  Max Williams May 28 '13 at 12:55
    
@MaxWilliams see updated answer. –  terdon May 28 '13 at 13:08
    
Cool - thanks a lot! –  Max Williams May 28 '13 at 15:07
add comment

Why don't you set the user to run that specific cronjob yourself? for example:

42 13 * * * root cd /path/to/my/working/folder && ...

this job will be run as root... If you entered job in /etc/crontab

share|improve this answer
add comment

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.