tmpwatch : Ménage dans /tmp/ sous Linux Redhat & Fédora

Je fais un petit rappel pour le ménage (suppression) du répertoire /tmp/ sous Linux. A la suite de l’étude des logs de error.log de Apache j’ai pu voir que souvent le répertoire /tmp/ était complet.

grep "No space left on device" error.log.201701* | awk '{print $4 " " $3}' | sort -n | uniq -c
  85 18 Jan
 114 19 Jan

L’idéal est donc de modifier le paramètre de tmpwatch, par défaut on a :

# cat /etc/cron.daily/tmpwatch
#! /bin/sh
flags=-umc
/usr/sbin/tmpwatch "$flags" -x /tmp/.X11-unix -x /tmp/.XIM-unix \
        -x /tmp/.font-unix -x /tmp/.ICE-unix -x /tmp/.Test-unix \
        -X '/tmp/hsperfdata_*' 10d /tmp
/usr/sbin/tmpwatch "$flags" 30d /var/tmp
for d in /var/{cache/man,catman}/{cat?,X11R6/cat?,local/cat?}; do
    if [ -d "$d" ]; then
        /usr/sbin/tmpwatch "$flags" -f 30d "$d"
    fi
done

Par défaut le ménage se fait donc tous les 10 jours, le plus propre est donc de modifier le temps plutôt que d’ajouter une autre tache cron qui ne va pas tenir compte de la date de création du fichier.
Voici le man :

NAME
       tmpwatch - removes files which haven't been accessed for a period of time
 
SYNOPSIS
       tmpwatch [-u|-m|-c] [-MUXadfqstvx] [--verbose] [--force] [--all]
                      [--nodirs] [--nosymlinks] [--test] [--fuser] [--quiet]
                      [--atime|--mtime|--ctime] [--dirmtime] [--exclude path]
                      [--exclude-user user] [--exclude-pattern pattern]
                      time dirs
 
DESCRIPTION
       tmpwatch recursively removes files which haven't been accessed for a given time.  Normally, it's used to clean up directories which are used for temporary holding space such as /tmp.
 
       When  changing directories, tmpwatch is very sensitive to possible race conditions and will exit with an error if one is detected. It does not follow symbolic links in the directories it's
       cleaning (even if a symbolic link is given as its argument), does not switch filesystems (including non-trivial bind mounts), skips lost+found directories owned by the root user, and  only
       removes empty directories, regular files, and symbolic links.
 
       By  default,  tmpwatch  dates files by their atime (access time), not their mtime (modification time). If files aren't being removed when ls -l implies they should be, use ls -u to examine
       their atime to see if that explains the problem.
 
      If the --atime, --ctime or --mtime options are used in combination, the decision about deleting a file will be based on the maximum of these times.  The --dirmtime option implies  ignoring
       atime of directories, even if the --atime option is used.
 
       The  time parameter defines the threshold for removing files.  If the file has not been accessed for time, the file is removed.  The time argument is a number with an optional single-char‐
       acter suffix specifying the units: m for minutes, h for hours, d for days.  If no suffix is specified, time is in hours.
 
       Following this, one or more directories may be given for tmpwatch to clean up.

Je pense que le mieux est de passer de 10 jours à 10 heures. Pour du site Web (Apache, MySQL, PHP), je pense que c’est largement suffisant 10h dans le répertoire /tmp/. Disons que PHP ne va faire un fichier qui va durer plus que le temps maximum dans php.ini , et une session ne devrait pas durer plus de 10h.

 

PHPNET : Support

Souvent je fais la publicité pour PHPNET : https://www.phpnet.org/ , voici mon historique des problèmes chez eux afin d’être transparent.

1-Ticket n°69373 (ouverture 10/11/2016 à 10:59:17 / fermeture10/11/2016 à 21:00:00 ) : Soucis sur les serveurs mutualisés, qui a provoqué un dysfonctionnement sur l’upload de fichier depuis un script PHP. Critique pour moi (mais Basse pour eux :().

capture-decran-2016-11-10-a-21-50-52

2-Ticket n°39662 (ouverture 09/06/2012 à 17:30:15 / fermeture 13/06/12 à 16:35) :  le virtualhost était en majuscules, plutôt qu’en minuscules. Non critique.

3-Ticket n°39158 (ouverture 11/04/2012 à 11:30:56 / fermeture 16/04/12 à 15:38) : délai de 4 heure dans les emails. Non critique.

4-Ticket n°37823 (ouverture 23/12/2011 à 13:39:08 / fermeture 29/12/11 à 11:40) : Changement du mots de passe sans que j’en sois informé. Critique.

5-Ticket n°37181 ( ouverture 24/10/2011 à 12:23:31 / fermeture 24/10/11 à 14:20) : Limitation sur le nombre d’Inode (df – i) mais pas sur l’espace (df -h). Pas très clair sur leur offre. Non critique.

6-Ticket n°37372 : (ouverture 07/11/2011 à 09:31:43 / fermeture 09/11/11 à 11:40) : Statistique fausse sur WebAnalyzer. Non critique.

7-Ticket n°33106 : (ouverture 29/09/2010 à 21:56:00 / fermeture 29/09/10 à 23:13) Problème sur le serveur FTP. Non critique.

8-Ticket n°9209 : (ouverture 04/10/2005 à 12:09:35 / fermeture 04/10/05 à 23:37) . Plus de logs access_log. Non critique.

9-Ticket n°8316 : (ouverture 31/08/2005 à 08:40:22 / fermeture 31/08/05 à 10:21) . Tous les sites HS : « L’intervention effectuée le Mardi 30 Août ne s’est pas déroulée comme nous l’avions prévue ». Critique.

Création de mon compte chez PHPNET : 17/09/2003. En 13 ans j’ai eu 9 problèmes, dont 3 critiques.

Il reste quand même quelques évolutions à faire :

  • Ajouter le service Digiposte (Ticket n°62402)/ Digiposte+ (Ticket n°69165). C’est plus pratique pour les factures !
  • Ajouter un interface pour voir la liste des connexions sur la page Admin : Date Heure / IP / Durée. A noter que maintenant il est possible d’avoir une alerte par email :
  • capture-decran-2016-11-10-a-21-33-46