[CRON]Geen mail bij succesvolle run, wel mail bij een error

[van.der.schulting]

Ik heb de volgende cronjob:

code:

12 *    * * *   /var/scripts/db/remove_temp_DB_backups.sh -I_am_aware_this_will_remove_files

De mail aan root forward ik naar mijn mailadres.
Echter geeft dit scriptje ook wat output over wat hij aan het doen is. Handig als ik hem handmatig drtaai, maar op de mail hoef ik dat niet te weten. Per mail wil ik alleen op de hoogte gebracht worden van errors.

Nu las ik dat je dat kan doen door > /dev/null toe te voegen.
Mijn crontab ziet er nu dus zo uit:

code:

12 *    * * *   /var/scripts/db/remove_temp_DB_backups.sh -I_am_aware_this_will_remove_files > /dev/null

Alleen de Cron-deamon blijft keurig om -.12 de output mailen als het goed gaat (dus geen errors)
Wat ik in feite doe is de crontab aanpassen via commando 'crontab -e'

Nu komt het meest vreemde:
Aan een andere regel die om -.37 loopt had ik al eerder '> /dev/null' toegevoegd. Deze regel heeft nog een tijdje doorgemaild, maar is er nu opeens wel mee gestopt, met mailen. Dat is wel wat ik wil, maar hoe kan dat zo opeens?

Doe ik iets fout.... Het lijkt wel alsof de crontab niet 'geinstalled' wordt, maar dan zou ik toch ook niet een regel zoals onderstaand moeten zien als ik 'crontab -l' doe:

code:

12 *    * * *   /var/scripts/db/remove_temp_DB_backups.sh -I_am_aware_this_will_remove_files > /dev/null

Wie weet wat ik fout doe?

[Demo]

Met > /dev/null gooi je alle output van je script weg Je moet eens gaan googlen naar 2>&1 daarmee kan je zorgen dat de standaard output (STDOUT) weggegooid wordt, maar foutmeldingen (STDERR) er uit gefilterd worden en die kan je dan doorsturen naar een ander commando.

[van.der.schulting]

Ik heb het even geprobeerd op de CLI. maar met de toevoeging '2>&1' geeft hij ook de gewone output naar STDOUT weer... Ik dacht dat dat er juist uitgefilterd werd, of alleen als de cronjob hem uitvoert??

[Sendy]

Nee, 2>&1 stuurt data die normaal naar stderr gaat naar stdout instead. Je kan dan bijvoorbeeld stderr en stdout naar dezelfde file leiden: prog 2>&1 >file schrijf de uitvoer van prog op stderr en stdout naar de file.

Ik dat dat TS zijn cron moet herstarten.

[ Voor 33% gewijzigd door Sendy op 02-04-2012 17:06 . Reden: Niet >2, maar 2> ]

[webfreakz.nl]

12 *    * * *    /var/scripts/db/remove_temp_DB_backups.sh -I_am_aware_this_will_remove_files 1>/dev/null 2>/bin/mail

Zoiets?

[van.der.schulting]

Sendy schreef op zondag 01 april 2012 @ 15:00:
Ik dat dat TS zijn cron moet herstarten.

Doet crontab -e dat niet automatisch als je hem opslaat??

[Elijan9]

webfreakz.nl schreef op zondag 01 april 2012 @ 15:50:

12 *    * * *    /var/scripts/db/remove_temp_DB_backups.sh -I_am_aware_this_will_remove_files 1>/dev/null 2>/bin/mail

Zoiets?

Nee! Dan ben je je mail applicatie kwijt, als je tenminste schrijfrechten hebt op /bin/mail... In principe zou (voor zover ik weet) alles wat op stderr komt automatisch gemailed moeten worden, stdout doorsluizen naar /dev/null zou genoeg moeten zijn, zolang eventuele errors naar stderr geschreven worden...

Je kunt natuurlijk ook het script herschrijven om stil te zijn wanneer alles goed gaat?

[blaataaps]

Sendy schreef op zondag 01 april 2012 @ 15:00:
Nee, 2>&1 stuurt data die normaal naar stderr gaat naar stdout instead. Je kan dan bijvoorbeeld stderr en stdout naar dezelfde file leiden: prog >2&1 >file schrijf de uitvoer van prog op stderr en stdout naar de file.

Je voorbeeld is op 2 manieren fout. Je bedoelt 2>&1 in plaats van >2&1 denk ik, en met de juiste syntax doet het niet wat je zegt. Met "2>&1 >file" krijg je alsnog stderr op je scherm, en alleen stdout in het bestand. Met ">file 2>&1", of "&> file" komen zowel stderr als stdout in het bestand.

[Sander]

Makkelijkste met dit soort dingen is wrapper scriptie eromheen die het opvangen van de output in een logfile verzorgt en daarna zelf de mail stuurt. Dan verder geen mail vanuit Cron.

[van.der.schulting]

De oplossing van Elijan9 werkt. Nu mijn volgende probleem:
Ik krijg nog steeds mailtjes van root, waarbij de cron het volgende script wil aanroepen:

code:

/var/scripts/db/temp__DB_full_SQL_backup.sh: No such file or directory

Deze regel heb ik hernoemd naar:

code:

/var/scripts/db/temp__DB_full_DB_backup.sh

Ik heb cron al meerdere malen herstart.
Waarom wil mijn crontab dan consequent de oude regel nog aanroepen?? Hij staat allang niet meer in mijn crontab....??

[Sendy]

blaataaps schreef op maandag 02 april 2012 @ 11:21:
[...]

Je voorbeeld is op 2 manieren fout. Je bedoelt 2>&1 in plaats van >2&1 denk ik, en met de juiste syntax doet het niet wat je zegt. Met "2>&1 >file" krijg je alsnog stderr op je scherm, en alleen stdout in het bestand. Met ">file 2>&1", of "&> file" komen zowel stderr als stdout in het bestand.

Ja, dat eerste was een typfoutje (altijd vervelend in dit soort statements), en je hebt geloof ik gelijk dat je die twee onderdelen in de andere volgorde moet zetten. Echter ik denk nu dat in mijn voorbeeld stderr op stdout komt en stdout in de file. Either way, dat redirecten is altijd leuk.

[van.der.schulting]

van.der.schulting schreef op maandag 02 april 2012 @ 14:52:
De oplossing van Elijan9 werkt. Nu mijn volgende probleem:
Ik krijg nog steeds mailtjes van root, waarbij de cron het volgende script wil aanroepen:

code:

/var/scripts/db/temp__DB_full_SQL_backup.sh: No such file or directory

Deze regel heb ik hernoemd naar:

code:

/var/scripts/db/temp__DB_full_DB_backup.sh

Ik heb cron al meerdere malen herstart.
Waarom wil mijn crontab dan consequent de oude regel nog aanroepen?? Hij staat allang niet meer in mijn crontab....??

Nobody?

[Elijan9]

van.der.schulting schreef op dinsdag 03 april 2012 @ 13:02:
[...]
Nobody?

Misschien wordt dat nog aangeroepen vanuit één van de andere cron bestanden? (/etc/crontab, /etc/cron.*/*)

[van.der.schulting]

Ik dacht dat de oplossing van Elijan9 werkte, maar helaas... de mail kwam in de spam terecht, waardoor ik het over het hoofd zag. Cron blijft de output van STDOUT mailen. Ik heb het vermoeden dat het aan het script ligt, maar ik kom er niet uit...
Voorbeeld:
Deze regel:

code:

12 *    * * *   /var/scripts/db/remove_temp_DB_backups.sh -I_am_aware_this_will_remove_files >/dev/null

Blijft dit mailen:
Subject: Cron <root@prod-db01> /var/scripts/db/remove_temp_DB_backups.sh -I_am_aware_this_will_remove_files

code:

Removal report of old backups made on: 2012-04-25_101201


Inside dir: /var/backups/db/temp_DB_backups Matching pattern: *backup*.gz


Files that will be removed:
/var/backups/db/temp_DB_backups/temp__DB__full__SQL_backup__scrapers_v1_production__2012-04-25_073703.sql.gz
/var/backups/db/temp_DB_backups/temp__DB__full__SQL_backup__torrent_scrapers_production__2012-04-25_073701.sql.gz


files were removed.

Het script ziet er als volgt uit:

code:

#!/bin/bash
#
# simple script to remove temporary DB (or file) backups *** use with care ***
# remove files between 2 and 3 hours old (or modified) from: ${STORAGE_DIR}
# that match with the pattern: ${PATTERN}

#
STORAGE_DIR="/var/backups/db/temp_DB_backups"
EMAIL_1="[e-mail]"
EMAIL_2="[e-mail]"
SUBJECT="Removal of temporary backups report on `date +%F\ %H:%M:%S`"
PATTERN='temp__DB*backup*.tgz'
#
# some example patterns below
#
PATTERN='*backup*.gz'
#PATTERN='*__inc__*.tgz'
#PATTERN='*__inc__*backup*.tgz'
#PATTERN='*__full__*.tgz'
#PATTERN='*__full__*backup*.tgz'
#
# select if you would like the backup report as a file attachment ( 0 => text .. 1 => file ) 
ATTACHMENT=0

#
# --Do NOT change any variables below this point unless you are creating a new type of backup removal script--
#
HOURS_AGO_MIN="120"
HOURS_AGO_MAX="180"
DATE="`date +%F_%H%M%S`"
REMOVE_LIST="/tmp/removal_of_temp_backups_list__${DATE}"
MAIL_REPORT="/tmp/removal_of_temp_backups_report__${DATE}"
DO_IT=0

function usage() {
    echo -e "\nusage: $0 -I_am_aware_this_will_remove_files\n"
    echo -e "   '-I_am_aware_this_will_remove_files' is currently the only available option\n"
    echo -e "\n The script will only delete files if you specify the option\n\n"
    exit 1 
}

if [ "$1" != "" ] 
then
    if [ "$1" == "-I_am_aware_this_will_remove_files" ]
    then
        DO_IT=1
    else
        usage
    fi
fi

# make sure ${MAIL_REPORT} is a new file
echo -e "Removal report of old backups made on: ${DATE}\n" |tee ${MAIL_REPORT}

# Provide feedback on the directory and pattern
echo -e "\nInside dir: ${STORAGE_DIR}\nMatching pattern: ${PATTERN}\n\n" |tee -a ${MAIL_REPORT}


# find the files created or modified that are in between DAYS_AGO_MIN and DAYS_AGO_MAX days old 
#find ${STORAGE_DIR} -xdev -type f -name "${PATTERN}" -cmin +${HOURS_AGO_MIN} -cmin -${HOURS_AGO_MAX} > ${REMOVE_LIST}  
find ${STORAGE_DIR} -xdev -type f -name "${PATTERN}" -cmin +${HOURS_AGO_MIN} > ${REMOVE_LIST}  

if [ "$DO_IT" == "0" ]
then
    echo "Files to remove:" | tee -a ${MAIL_REPORT}
    cat ${REMOVE_LIST} | tee -a ${MAIL_REPORT}
    echo | tee -a ${MAIL_REPORT}
else
    echo "Files that will be removed:" | tee -a ${MAIL_REPORT}
    cat ${REMOVE_LIST} | tee -a ${MAIL_REPORT}
    echo | tee -a ${MAIL_REPORT}
fi

if [ "$DO_IT" == "0" ]
then
    echo -e "\n*** Dry run ***\n\n" | tee -a ${MAIL_REPORT}
    #cat ${REMOVE_LIST} | while read file ; do echo "considered for removal: \"${file}\"" ; done | tee -a ${MAIL_REPORT}
    cat ${REMOVE_LIST} | while read file ; do echo "considered for removal: `ls -lc \"${file}\"`" ; done | tee -a ${MAIL_REPORT}
else
    echo -e "\nfiles were removed.\n" | tee -a ${MAIL_REPORT}
    cat ${REMOVE_LIST} | while read file ; do rm -f "${file}" ; done | tee -a ${MAIL_REPORT}
    # the line above does the actual deleting, the line below is for testing purposes
    #cat ${REMOVE_LIST} | while read file ; do echo "rm -f \"${file}\"" ; done | tee -a ${MAIL_REPORT}
fi

# mail the report to ${EMAIL_1} and ${EMAIL_2}
if [ $(date +%H) == 03 ]
then
    if [ "$ATTACHMENT" == "0" ] 
    then
        cat ${MAIL_REPORT} | mail -s "${SUBJECT}" ${EMAIL_1} -c ${EMAIL_2} 
    else
        uuencode ${MAIL_REPORT} ${MAIL_REPORT} | mail -s "${SUBJECT}" ${EMAIL_1} -c ${EMAIL_2} 
    fi
fi

[CyBeR]

Bash:

# mail the report to ${EMAIL_1} and ${EMAIL_2}
if [ $(date +%H) == 03 ]
then
    if [ "$ATTACHMENT" == "0" ] 
    then
        cat ${MAIL_REPORT} | mail -s "${SUBJECT}" ${EMAIL_1} -c ${EMAIL_2} 
    else
        uuencode ${MAIL_REPORT} ${MAIL_REPORT} | mail -s "${SUBJECT}" ${EMAIL_1} -c ${EMAIL_2} 
    fi
fi

Ja, duh

[van.der.schulting]

CyBeR schreef op woensdag 25 april 2012 @ 11:24:

Bash:

# mail the report to ${EMAIL_1} and ${EMAIL_2}
if [ $(date +%H) == 03 ]
then
    if [ "$ATTACHMENT" == "0" ] 
    then
        cat ${MAIL_REPORT} | mail -s "${SUBJECT}" ${EMAIL_1} -c ${EMAIL_2} 
    else
        uuencode ${MAIL_REPORT} ${MAIL_REPORT} | mail -s "${SUBJECT}" ${EMAIL_1} -c ${EMAIL_2} 
    fi
fi

Ja, duh

Neenee, das alleen om 3 uur 's nachts
Kijk maar:

code:

if [ $(date +%H) == 03 ]

Het probleem komt elk uur voor.....

[ Voor 3% gewijzigd door van.der.schulting op 25-04-2012 11:35 ]

[CyBeR]

Ah, excuseer. Ik moest weg dus ik had niet verder gelezen dan 't commentaar eigenlijk

[Elijan9]

Als je

code:

|tee -a ${MAIL_REPORT}

vervangt door

code:

>> ${MAIL_REPORT}

wordt het script een stuk stiller, nu stuurt "tee" het mailrapport naar ${MAIL_REPORT} en naar stdout...

[van.der.schulting]

Thanks it works. Hij mailt alleen bij een error

alleen nu het volgende probleem. Als ik het scriptje op de CLI uitbvoer wil ik wel graag output zien. Dus heb ik aan het einde van het scriptje de volgende regel toegevoegt:

code:

cat ${MAIL_REPORT}

Damn, dan krijg ik nog steeds een mailtje van de output van deze regel. Hoe kan ik ervoor zorgen dat hij wel de STDOUT naar de CLI schrijft, maar niet gaat mailen bij een succesvulle cron?

Nu mailt hij 'cat ${MAIL_REPORT}' en dat wil ik juist niet... Ik heb het maar eventjes weggehaald, maar nu krijg ik dus ook niet te zien als ik het script handmatig uitvoer...

BTW dit werkt niet

code:

echo ${MAIL_REPORT}

${MAIL_REPORT} is nl. een file

[ Voor 6% gewijzigd door van.der.schulting op 26-04-2012 14:30 ]

[CyBeR]

Bash:

test -t 0 && exit 0

[ Voor 9% gewijzigd door CyBeR op 26-04-2012 14:38 ]

[Borromini]

Demoniac schreef op zondag 01 april 2012 @ 11:38:
Met > /dev/null gooi je alle output van je script weg Je moet eens gaan googlen naar 2>&1 daarmee kan je zorgen dat de standaard output (STDOUT) weggegooid wordt, maar foutmeldingen (STDERR) er uit gefilterd worden en die kan je dan doorsturen naar een ander commando.

1> (ook 'afgekort' als >) dirigeert STDOUT. 2> (niet afgekort) STDERR. 2>&1 en dergelijke zorgen ervoor dat beide op eenzelfde locatie terechtkomen.

[van.der.schulting]

CyBeR schreef op donderdag 26 april 2012 @ 14:37:

Bash:

test -t 0 && exit 0

okidoki, thanks

Ik snap alleen het nu van 'test -t 0' niet helemaal. Waarom zou ik dat willen?

[CyBeR]

Dat checkt of de standard input een terminal is of niet.