1

I know that my question was asked several times, but there is no solution for my problem. In my Company there is an Application running on a RedHat Mashine. Users connect a text Based GUI via ssh to this Server. This Application does not support Pasword aging resetting password.

I made a script checking password aging time and sending an eMail to each user.

The script is running fine from shell but not working in crontab. Several tests (touch testfile) showed that crontab is working and all scripts are executed. I verified that with a simple echo command at the beginning of the new script.

deeper investigating with several echos showed me that there is a problem with assigning a command to a variable.

This worked for years and in several crontabs

 VAR = `ls`

i tested other versions:

VAR = $(ls)
VAR = `/bin/ls`
VAR = $(/bin/ls)

Snippet from Script:

(... generating user/email array ...)
echo "----------------START "$LOGDATE" ---------------" >> $LOGFILE

for ((i=0; i<${#USER[*]} ; i++))

do

USERNAME=${USER[$i]}

EMPFAENGERNAME=${EMPFAENGER[$i]}

TEMP1=`chage -l $USERNAME | grep 'Kennwort läuft ab'|cut -d ":" -f2`

(... sending email to user telling him to change password ...)

Crontab: (root)

00 12 * * 1-5 /root/pw_warning.sh

That script is so simple and its working as root and with sudo, its nothing really complicated but i dont get the point what i am doing wrong.

Update:

Tested PATH=(..) in crontab and in script as suggested. No changes at all.

Again: crontab is working and executing scripts. Every command in the script is working for itself but not when it should be assigned to a variable.

Update2: Adding path to shell did not work:

   0 0 * * * /bin/bash /path/to/script.sh

Update3:

Working Workaround:

0 0 * * * ssh root@localhost "/path/to/script"
Magnus
  • 29
  • 1
  • 7
  • 2
    Possible duplicate of [Why is my crontab not working, and how can I troubleshoot it?](http://serverfault.com/questions/449651/why-is-my-crontab-not-working-and-how-can-i-troubleshoot-it) – Dennis Nolte Jan 13 '16 at 15:29
  • no dublicate. there is only a standard troubleshoot answer... everything done without solution. My crontab IS working, it runs several WORKING scripts – Magnus Jan 14 '16 at 06:14

1 Answers1

2

Cron passes a minimal set of environment variables to your jobs.

A common "gotcha" here is the PATH environment variable being different.

To get around that, just set your own PATH variable at the top of the script. E.g.

#!/bin/bash
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# rest of script follows

You can also set the PATH variable in the crontab file, which will apply to all cron jobs. E.g.

PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

15 1 * * * backupscript --incremental /home /root

from here

Also, judging by variables assignments you're using, you script won't work in /bin/sh, make sure your first line is correct:

#!/bin/bash

Or better run your script as 

0 0 * * * /bin/bash /path/to/script.sh

instead of just /path/to/script.sh

Finally, you may try to put the following hacky code in your crontab, since it should work exactly as if you had run the script from the shell yourself:

 15 1 * * * ssh root@localhost "/path/to/script.sh"

The problem is with your script, though. Try using some bash script template this or this, which should eliminate any variable-assignment related problems.

Community
  • 1
Anubioz
  • 3,597
  • 17
  • 23
  • shedbang is correct, and /bin/bash was never needed in my life but i will try it. i will post a complete answer later. im not at that company at the moment. I have also tried settingh path in script and in cron. no effect. full path to command should do the same. even shell builtin commands did not work if i want to assign the output to a variable. the command itself works when i t runs in the script but when i want to start a subshell and want to assign the output to varaible the varaible stays empty output through cron shows correct path */5 * * * * echo $PATH >> testfile.txt – Magnus Jan 14 '16 at 06:19
  • Bonus crunchtest: can you start is with `screen -d -m /path/to/script.sh` in your cron please? – Anubioz Jan 14 '16 at 08:19
  • Also, can you test global `/etc/crontab`, the one where you should write usernames before command like `0 0 * * * root /bin/bash /path/to/script.sh`? Does it fail too that way? – Anubioz Jan 14 '16 at 08:31
  • there is no screen command. its a server without GUI i tried it in system crontab with username. it produce the same results. .commands worked except assigning Next i will try same script on different Server and distribution. – Magnus Jan 14 '16 at 09:53
  • GNU Screen has nothing to do with GUI, it's used for maintaining persistent terminal sessions. Can you please install it with [this guide](https://www.linode.com/docs/networking/ssh/using-gnu-screen-to-manage-persistent-terminal-sessions)? – Anubioz Jan 14 '16 at 09:55
  • Also, before migrating to another distro, [try another cron first](https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Migration_Planning_Guide/sect-Migration_Guide-Networking-Cron.html) – Anubioz Jan 14 '16 at 09:56
  • it is a company and i am not allowed to install "not allowed" software. This has to be approved (2 to 5 days) it am allowed to change cron if i can maintain functionality. This will take some time. i have never installed or changed cron so i have to do it first on some test mashines to learn how to do it. i only want to test the script in other distro. Migration is not possible. – Magnus Jan 14 '16 at 10:09
  • @magnus Oh, I see, then try this command please: `ssh root@localhost "/path/to/script.sh"`. Does it work that way? – Anubioz Jan 14 '16 at 10:12
  • that commad worked. i tried the script on very old testserver (opensuse 10.2) with same effects. i had to change some commands because of older shell – Magnus Jan 14 '16 at 10:37
  • Now that's what you call a hacky solution! Anyway, glad it had helped, though you should try to rewrite your script so it won't require such desperate measures :) – Anubioz Jan 14 '16 at 10:40
  • Thank you very much. i dont like hacky solutions but my employer is satisfied. I added a note in the report. – Magnus Jan 14 '16 at 11:01
  • So what's the actual solution here. Is the problem anything to do with cron ? – user9517 Jan 14 '16 at 11:28
  • now the solution / Workaround is in both posts. with the workaround cron starts an ssh shell and the script is executet in this shell. i will try the other suggestions with the script templates and installing different cron. – Magnus Jan 14 '16 at 11:37