Cron job from 'crontab -u www -e' doesn't run?

[Aknot]

I can't get cron jobs to run, when adding them with user www (nologin account):

crontab -u www -e
* * * * * /usr/local/bin/php /www_master/sites/support/artisan schedule:run >> /dev/null 2>&1

But if I edit /etc/crontab and add this line with the user www before the command, everything is working:

* * * * * www /usr/local/bin/php /www_master/sites/support/artisan schedule:run >> /dev/null 2>&1

Am I missing something?

 

[covacat]

check cron.log also redirect stdout and stderr to /tmp/something until you figure it out

 

[cracauer@]

Use a cronjob like `touch /tmp/l` to see whether anything runs at all.

 

[mer]

man -S 5 crontab seems to indicate that the line format is:
Each line in system crontab ( /etc/crontab, /etc/cron.d,
/usr/local/etc/cron.d ) has five time and date fields, followed by a
valid user name (with optional ``:<group>'' and ``/<login-class>''
suffixes), followed by a command

So perhaps you still need to add the user "www" even if you are editing the crontab for user www.

 

[sko]

The user needs a valid login shell in which cron can run the command.

If run from /etc/crontab (or roots crontab) as per your second example, 'su' is used to switch to the user, keeping the current shell.

Since it's usually a very bad idea to give www a login shell, just run the command from roots crontab (i.e. your second example). This is also not ideal, especially when running some doubious php code, but still better than giving www a login shell. (everything using php belongs in a jail or at least chroot anyways...)

 

[covacat]

The user needs a valid login shell in which cron can run the command.

If run from /etc/crontab (or roots crontab) as per your second example, 'su' is used to switch to the user, keeping the current shell.

Since it's usually a very bad idea to give www a login shell, just run the command from roots crontab (i.e. your second example). This is also not ideal, especially when running some doubious php code, but still better than giving www a login shell. (everything using php belongs in a jail or at least chroot anyways...)

no it does not (at least it works for me with /usr/sbin/nologin). also man page says /bin/sh is used if the crontab file does not say otherwise

Sep 21 15:09:09 z crontab[22778]: (root) END EDIT (www)
Sep 21 15:10:00 z /usr/sbin/cron[2421]: (www) RELOAD (tabs/www)
Sep 21 15:10:00 z /usr/sbin/cron[22803]: (www) CMD (/bin/ls />> /tmp/x12)
Sep 21 15:10:31 z crontab[22809]: (root) DELETE (www)
# grep www /etc/passwd
www:*:80:80:World Wide Web Owner:/nonexistent:/usr/sbin/nologin
# grep nologin /etc/shells
# ls -l /tmp/x12
-rw-r--r--  1 www wheel 124 Sep 21 15:10 /tmp/x12
# cat /tmp/x12
COPYRIGHT
bin
boot
dev
entropy
...
sys
tmp
usr
var

 

[ShelLuser]

Not enough info to go on, OP: you definitely need to check your logfiles: /var/log/cron, but just in case I'd also check /var/log/messages.

So perhaps you still need to add the user "www" even if you are editing the crontab for user www.

Absolutely not. crontab(5) clearly showcases this: 5 mandatory fields (m h dm mo dw), followed by a command:

Each user cron line has five time and date fields, followed by a command.

The user needs a valid login shell in which cron can run the command.

Also not quite true, but it does depend on your definition of "valid". The only service that reacts to /etc/shells like that is ftpd(8), but not Crontab. By default the shell for www is /sbin/nologin which isn't included, but this has 0 influence in the way in which cron handles things.

On my server all web statistics are generated using the www credentials and that works out of the box. So... 'nologin' as login shell despite the fact that it's not part of /etc/shells.

 

[sko]

TBH I've never digged further into this as this was always the standard explanation I got/found when trying to run php scripts failed from the www users crontab. I.e. I've been running cronjobs for www like e.g. for nextcloud, paperless and other web applications from /etc/crontab (and specifying the www user there) since forever...
A quick test on a nextcloud instance confirms that using www's crontab to run the cron script fails if www has /sbin/nologin set but works if /bin/sh is set.
However, trying to run the script via # su www -c 'php -f ...' also fails if /sbin/nologin is set for www (-> "This account is currently not available."). So there seems to be more to that.

/var/log/cron in both cases only logs

/usr/sbin/cron[39107]: (www) CMD (php -f /usr/local/www/nextcloud/cron.php)

but when called from www's crontab it isn't executed sucessfully according to the nextcloud log...


Now I'm also curious what the real culprit is...

 

[mer]

Absolutely not. crontab(5) clearly showcases this: 5 mandatory fields (m h dm mo dw), followed by a command:

Fair enough, I missed the sentence around "user crontab"

 

[covacat]

php definitely works from a restricted shell cron

# crontab -l -u www
* * * * * /usr/local/bin/php -i >/tmp/php.txt 2>&1

# head /tmp/php.txt
phpinfo()
PHP Version => 8.4.25

System => FreeBSD z.bollocks.gov 14.4-RELEASE-p9 FreeBSD 14.4-RELEASE-p9 releng/14.4-n273766-53c5c1935320 GENERIC amd64
Build Date => Sep  8 2026 01:11:38