"getpwnam() failed" in /bin/sh only when called from cron

Question

Here's the content of my crontab file:

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO="[email protected]"

*/5 * * * * sh /robot/1/master.sh >/dev/null 2>&1
*/5 * * * * sh /robot/2/master.sh >/dev/null 2>&1
*/5 * * * * sh /robot/3/master.sh
*/5 * * * * sh /robot/4/master.sh >/dev/null 2>&1
*/5 * * * * sh /robot/5/master.sh >/dev/null 2>&1

This is the error that keeps showing in /var/log/cron when it tries to run:

crond[669]: (sh) ERROR (getpwnam() failed)

If I run any of these files manually, they work without any issues.

What's wrong with the crontab file?

Solution 1

It surprises me that nobody has the correct answer to this. Today i faced exactly the same problem and google didn't help.

After 2 hours i found that when placing a file in /etc/cron.d the schedule line has to contain an extra option.....

I allways use this for my crontab -e

# Minute   Hour Day of Month     Month          Day of Week     Command    
# (0-59)  (0-23)   (1-31)  (1-12 or Jan-Dec)  (0-6 or Sun-Sat)  /my/fancy/script.sh            

So it contains 6 items.

When placing this in a file inside /etc/cron.d the cron needs an extra option, being the user to run your fancy/script.

# Minute   Hour Day of Month     Month          Day of Week     Who   Command    
# (0-59)  (0-23)   (1-31)  (1-12 or Jan-Dec)  (0-6 or Sun-Sat)  root  /my/fancy/script.sh            

This is documented in man crontab(5). For example https://linux.die.net/man/5/crontab . It says:

Jobs in /etc/cron.d/

The jobs in cron.d are system jobs, which are used usually for more than one user. That's the reason why is name of the user needed. MAILTO on the first line is optional.

Solution 2

The sixth position is reserved for username running the job. You specified a user called sh which is most probably not present on the machine.

Solution 3

simple answer on your crontab you need to specify the USER to run the command

example to run as ROOT is:-

0,10,20,30,40,50 * * * * root /path_to_script/script_name

or to run as user FRED

0,10,20,30,40,50 * * * * fred /path_to_script/script_name

default with no USER specified is to run as user CRON and that user would not have permissions to execute the script

Comments

[Charles Duffy]

Aside: sh is not bash (even if it's a symlink to bash, it operates in compatibility mode, turning of numerous features). Don't tag your questions bash if you aren't actually using bash.

[Daniel Cortés]

Are you trying to run the cron every half minute or every 5 minutes? The */5 means that it will run every minute with a step of 5.

[Charles Duffy]

anyhow, getpwnam() failed is pretty straightforward, in general. What's your system's directory service/store? If it's configured to talk to something that requires Kerberos authentication, for example, then your cron jobs may not have a valid ticket.

[Charles Duffy]

...that is to say: The problem doesn't actually have to do with your crontab file, but it has to do with how your system's directory service -- which provides the information getpwnam() queries for -- is configured. That's going to mean digging around in your system's config a bit.

[Andrew]

@DanielCortés */5 means it'll run every 5 minutes.

[Andrew]

@CharlesDuffy Looking into it right now, thanks!

[Charles Duffy]

Incidentally, I can't speak for whatever /bin/sh you happen to be using, but bash will recover gracefully from a getpwnam failure (err, sorta gracefully; it'll assume your user is called I have no name!, has a home directory of /, and has a default shell of /bin/sh). You might try setting SHELL=bash in your crontab, and using bash instead of sh explicitly.

[Charles Duffy]

Heh. Good point -- if you've got a system crontab with a missing field, we'd be looking for a user named sh, and that would certainly cause a getpwnam() failure.

[oldboy]

not even the sys admins for my VPS have any clue what's causing it lol. btw, why have you used the path /etc/cron.d/ and not /etc/crontab?

[hetOrakel]

I use the directory /etc/cron.d because i can create one file with a descriptive name per task. Because i like it that way.... /etc/crontab is a file which is never modified by me.

[Nemo]

@Anthony: Also this is the natural way to add crontab entries owned by a package. (Which is how I ran into this problem today.) This should be the accepted answer.