Les réponses ci-dessus sont la manière standard / "correcte" de le faire.
Une autre approche plus simple d'un point de vue plus «utilisateur final» consiste à faire en sorte que toute tâche planifiée ou en arrière-plan écrive sa sortie dans un fichier «journal». Le fichier peut se trouver n'importe où sur votre système, mais si la tâche s'exécute en tant que root (à partir de cron
, etc.), alors quelque part sous /var/log
est un bon endroit pour le mettre.
J'ai créé le /var/log/maint
répertoire et l' ai rendu lisible par tout le monde et j'ai un fichier lisible sous celui appelé "sauvegarde" où je journalise la sortie de mes scripts de sauvegarde.
J'ai créé mon propre répertoire afin que mes fichiers ne soient pas mélangés avec les éléments générés par le système.
Pour y mettre des trucs (en bash):
BACKUP="/var/log/maint/backup"
echo "my message" >> "${BACKUP}"
Le >>
fait que les messages sont ajoutés au fichier au lieu de le remplacer à chaque fois.
Si mon script a beaucoup de sortie, j'utilise un script ou une fonction pour la sortie afin que tout soit fait de la même manière. Ci-dessous est ma version actuelle (overkill): (le truc VERBOSE est là lorsque j'exécute le script à partir d'un terminal et que je veux voir ce qui se passe à des fins de débogage.)
#!/bin/bash
## backup_logger
## backup system logging module
## Copyleft 01/20/2013 JPmicrosystems
## Usage is ${SCRIPT_NAME} [-v] [<caller> <log message text>]
## If present, -v says log to console as well as to the log file
## <caller> is the name of the calling script
## If <caller> <log message text> is not present, write a blank line to the log
## Must be placed in path, like ~/bin
## If log is owned by root or another user, then this must run as root ...
## If not, it just aborts
##source "/home/bigbird/bin/bash_trace" ## debug
SCRIPT_NAME="$(basename $0)"
USAGE="Usage is ${SCRIPT_NAME} [-v] [<caller> <log message text>]"
SYSLOGDIR='/var/log/maint'
SYSLOGFILE="${SYSLOGDIR}/backup.log"
LOGGING=1
VERBOSE=0
if [ "${1}" == "-v" ]
then
VERBOSE=1
shift
fi
##LOGGING=0 ## debug
##VERBOSE=1 ## debug
## Only zero or two parameters allowed - <caller> <log message text>
RC=0
if [ "$#" -eq 1 ] || [ "$#" -gt 2 ]
then
echo "${USAGE}"
RC=1
else
if [ ! -w "${SYSLOGFILE}" ]
then
touch "${SYSLOGFILE}"
if [ $? -ne 0 ]
then
echo -e "$(date) ${1} ${2}"
echo "${SCRIPT_NAME} Can't write to log file [${SYSLOGFILE}]"
RC=1
exit ${RC}
fi
fi
if [ -n "${1}" ]
then
(( LOGGING )) && echo -e "$(date) ${1} ${2}" >> "${SYSLOGFILE}"
(( VERBOSE )) && echo -e "$(date) ${1} ${2}"
else
(( LOGGING )) && echo "" >> "${SYSLOGFILE}"
(( VERBOSE )) && echo ""
fi
fi
exit $RC
Edit: at
exemple simpliste qui écrit dans un fichier utilisateur
Je n'ai pas utilisé cela depuis toujours, donc je l'ai compris avec quelques scripts simples.
Le premier script planifie simplement l'événement en utilisant at
. La commande elle-même pourrait simplement être tapée dans un terminal, mais je suis paresseux - surtout quand je dois le faire plusieurs fois tout en le testant sans tromper avec l'historique des commandes.
#!/bin/bash
## mytest_at_run
## Schedule a script to run in the immediate future
echo "/home/bigbird/bin/mytest_at_script" | at 00:56
Le deuxième script est celui qui doit s'exécuter
#!/bin/bash
## mytest_at_script
## The script to be run later
echo "$(date) - is when this ran" >> /home/bigbird/log/at.log
J'ai créé les deux scripts dans un éditeur de texte, les ai enregistrés, puis les ai rendus exécutables à l'aide de chmod 700 script-file-name
. Je les mets tous les deux dans mon $HOME/bin
annuaire pour plus de commodité, mais ils peuvent se trouver partout où mon utilisateur a un accès complet. J'utilise 700
pour n'importe quel script uniquement pour les tests, mais sur un système mono-utilisateur, il pourrait tout aussi bien l'être 755
.
J'ai déjà un répertoire appelé /home/bigbird/log
pour enregistrer la sortie de mytest_at_script
. Cela peut également se faire partout où votre utilisateur a un accès complet. Assurez-vous simplement qu'il existe avant l'exécution du script ou que le script le crée.
Pour l'exécuter, je me suis juste assuré que l'heure de la at
commande mytest_at_run
était un peu dans le futur, puis je l'ai exécutée à partir d'un terminal. J'ai ensuite attendu qu'il s'exécute et j'ai examiné le contenu de $HOME/log/at.log
.
bigbird@sananda:~/bin$ cat ~/log/at.log
Fri Sep 14 00:52:18 EDT 2018 - is when this ran
Fri Sep 14 00:56:00 EDT 2018 - is when this ran
bigbird@sananda:~/bin$
Quelques notes:
Même si je cours at
depuis mon utilisateur, il ne connaît pas mon environnement tel que mon PATH
et mon répertoire personnel, donc je ne le suppose pas. J'utilise des chemins complets comme je le ferais pour n'importe quel cron
travail. Et si jamais je veux en faire un cron
travail, je n'aurai rien à changer juste pour le faire fonctionner.
Je >>
en mytest_at_script
la sortie append dans le fichier journal au lieu de ce >
qui aurait remplacé sur chaque course. Utilisez celui qui convient le mieux à votre application.
sleep 3m; echo Running