I can only report what I see.
My conclusion (may be wrong): The reason why the service command fails: cron doesn't use the $PATH, that would be used when executing pihole -g
(user is pi). I've read the default path is hardcoded in the cron binary, and doesn't include what we need.
Adding the full path to the script solves the problem, although this may not be the best solution.
I've been looking at methods to ensure cron also knows about the $PATH variable, a regular user uses. One of the methods found, refers to to /etc/crontab (the system-wide crontab). This file has an additional shell and path command, that includes /usr/sbin
I would never have caught this error, if I didn't split the cron command
59 1 * * 7 root PATH="$PATH:/usr/local/bin/" pihole updateGravity >/var/log/pihole_updateGravity.log || cat /var/log/pihole_updateGravity.log
into
59 1 * * 7 root PATH="$PATH:/usr/local/bin/" pihole updateGravity >/var/log/pihole_updateGravity.log
9 2 * * 7 root PATH="$PATH:/bin/cat/" cat /var/log/pihole_updateGravity.log
The reason I have to do this: I've configured my system to send mails, when using cron, mails are sent by default, unless >/dev/null 2>&1
is added.
Because pihole updateGravity is restarting (or should be) pihole-FTL, the system cannot resolve the mailserver domain, defined in my MSMTP config file, the mail is never send (pihole-FTL doesn't resolve yet, not fully ready). By delaying the cat command (the output is send as a mail) this problem is solved.
Anyhow, the problem is temporarily solved, by changing the script, just wondering how many other users aren't even aware they have a problem...