Environment: RHEL7.9
Access: No root access. I have sudo access to some commands (no password)
Issue: my personal crontab calls a script with sudo, sudo isn't working.


I have a script.sh that calls sudo /usr/systemctl start service, it works from my SHELL but not from crontab -e.

This works: [mike@host] $ sudo /usr/systemctl start service
This works: [mike@host] $ ./script.sh #which has the command it

This fails: [mike@host] $ crontab -e

#MQ CRONS
SHELL=/bin/bash
*/15 * * * * bash -l -c '/export/local/mike/script.sh >> /tmp/log.log'


In more detail, the script runs fine and does every step. When it gets to the sudo command it just doesn't do it or something. Any ideas? is there a cron limitation? I tried source /path/to/mike/.bash_profile in the script and some cron things to no avail.

If you read the documentation (man pages) on sudo you will find that it does detect if it is running in interactive mode or not and behaves based upon the call and the mode. There are special parameters to use in scheculed scripting, or you could use a different escalation tool.

Did you turn on shell debugging in the script and log the run? Doing so should have resulted in more information you might have shared.
Did you check the sudo logs or system logs for sudo entries at execution time? There should be a trace of the call there, along with a more or less informative error entry.

Sadly debug output doesn't seem to help me. It rolls right through the script as it should. Basically it checks 3 preconditions and if they all are met etc. it just runs the sudo command last. I will dig into the sudo command a bit more.. what a PITA.

Debug:
+ echo 'Found [3] other servers, enough to continue with DB Start attempt on server01.'
+ sleep 2
++ date +%s
+ now=1650329226
+ get_time_stamp /tmp/TIME_STAMP_FILE.dat
+ file=/tmp/TIME_STAMP_FILE.dat
+ db_check_wait=0
+ '[' -f /tmp/TIME_STAMP_FILE.dat ']'
+ IFS=
+ read -r line
+ previous=0
+ delta=1650329226
+ echo 'now:1650329226 - previous:0 = delta:1650329226'
+ '[' 1650329226 -lt 3600 ']'
+ echo 'restarting => sudo /usr/bin/systemctl start mysql.service.'
+ sudo /usr/bin/systemctl start mysql.service
++ date
+ echo 'DB restart attempt made - Mon Apr 18 20:47:06 EDT 2022'

And was there a sudo log entry for that command?

In addition to the above questions, are you starting or restarting the database? The comment says restarting but the actual command says you are trying to start it instead.

you can check (in your shell script) if the sudo command was successful (see exit code).
How do you know it is failed?

Of course, the command works from the command line and when I run the script manually. Thanks for that quick thought but I have no issues with from a terminal.

As stated in the original post, the script and command work when I am running them in a terminal so no issues there. It is only when I put it in cron that it goes to hell.

I have written a lot of bash scripts, this is doing the following:

Start if stopped:

1 Check if the local port 3306 is not open and other things, if that fails.
2 Then check if the cluster size is still at least size two (or do nothing)
3 If it is then check when the last time this script was run, if it were < 1 hour do nothing.

4 If it gets through all of that, the final step is to attempt a start
sudo systemctl start mysql.service


So I can remove the script entirely and just run the start command in cron if that will help people understand the issue.

This is RHEL7.9, there may be something else going on:
https://unix.stackexchange.com/q/122616/108618

I believe wpeckham hit the nail on the tty. Your system is probably configured to require a tty to run sudo commands and cron is not associated with a terminal.

I believe your admin might have to add the following to the sudoers file
As an aside question why do you need to restart mysql?
Or why is it stopping?

1 members found this post helpful.

That was not the question. The question is if there is a log entry or error code return when the script runs under cron at the point when the sudo command executes. If it is not working, that would give you a clue as to WHY it is not working! If it is not working, it must error and return a code or log the problem, not just die silently.

OK I didn't see anything in the log file I was writing and I added the output status to the log, basically the output of the $? of 'sudo'

From cron:
DB restart attempt made (status: 1) - Tue Apr 19 12:08:59 EDT 2022
mysql.service -> NOT RUNNING


From the command line cron:
DB restart attempt made (status: 0) - Tue Apr 19 12:27:55 EDT 2022
mysql.service -> RUNNING

I'm thinking that the limitation is working as designed,

need to get an admin to do something like this: Defaults !requiretty in sudoers

Hi, I haven't heard anyone say anything about this in the thread except that I posted a link myself wondering if something was going on with that. Thanks for digging into it, I'll have to see what I can get done with the above.


Side topic on the DB:
The DB is a part of a cluster and they do not know why, I was simply providing a possible workaround that would help keep them going until they figured it out. They updated the software and after a period of a day or so 2 dbs will go down, then if not addressed the rest will eventually go and I have to bootstrap the cluster again. So my thought was to write a script that checks on each DB if it is down , check if two others are up and perform a start attempt 1x per time period. A few details need to be cared for such as current cluster size, randomizing the start time, and controlling how often it tries. Noobie scripters to often ignore these things and create underirable scenarios . I can share the script if you wanted.

Thanks all for your help!

So as an FYI, the issue was with SUDO and TTY

https://www.shell-tips.com/linux/sud...udo/#gsc.tab=0

I had an admin add the following to sudoers: Defaults !requiretty

* this def. has to be done on older RHEL I believe.


I stopped the service and the cron fixed it. Onlyplace sudo is used is in a the command in the script.

Correct output:
DB restart attempt made (status: 0) - Tue Apr 19 15:16:44 EDT 2022
mysql.service -> RUNNING