Recherche de processus zombie

Ah ! On se rapproche, voilà ce qu’il y a dans mon /etc/crontab:

# m h dom mon dow user	command
17 *	* * *	root    cd / && run-parts --report /etc/cron.hourly
25 6	* * *	root	test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6	* * 7	root	test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6	1 * *	root	test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

Et cela correspond au processus mystérieux qui écrit toutes les heures vers 17mn !

Par contre mon /etc/cron.d est pratiquement vide:

/etc/cron.d/anacron: crontab entries for the anacron package
30 7    * * *   root	test -x /etc/init.d/anacron && /usr/sbin/invoke-rc.d anacron start >/dev/null

Donc apparemment ce serait le run-parts qui écrirait toutes les heures quelque chose même s’il n’y a rien à faire ?
Edit: apparemment non, j’ai lancé manuellement run-parts et il n’écrit rien…

Je retiens le coup de monter le /tmp en tmpfs mais j’avais le même problème avec le /var/log avec tous ces process qui loggaient un peu tout et n’importe quoi.
J’ai réglé un peu les logs de quelques programmes et maintenant les logs sont plus rationnels et /var/log n’est plus modifié en permanence (et donc pas besoin de le monter en tmpfs).
CRON est je crois le dernier programme qui m’embête avant d’avoir une machine qui ne fait (presque) rien lorsque je ne lui demande rien.

Merci !

Ton /etc/crontab est classique, j’ai le même.
C’est la première ligne qui fait que cron se déclenche toutes les heures pour exécuter les scripts placés dans /etc/cron.daily. Chez moi une ligne est ajoutée dans /var/log/syslog à cette occasion même si le répertoire est vide, par exemple :

Quant à savoir quel processus en particulier écrit dans /tmp, il faudrait tracer les appels système.

Oui j’avais bien repéré cette ligne quand je voulais rationaliser les logs dans /var/log.
J’ai donc déjà désactivé le log de CRON via /etc/rsyslog.conf et /var/log/syslog n’est donc pas modifié lorsque CRON se lance.

Je crois que je touche bientôt au but. J’ai bien l’impression que CRON écrit quelque chose dans /tmp même si il n’y a rien à faire. Il faut juste que j’arrive à le reproduire…

Merci !

Bon hier soir j’ai commenté cette ligne dans /etc/crontab:

Et je n’ai plus d’écritures toutes les heures…
C’est donc bien le responsable. Par contre je n’arrive pas encore à reproduire le phénomène “manuellement” en lançant run-parts directement à la main.

[quote=“Nico_Pern”]Bon hier soir j’ai commenté cette ligne dans /etc/crontab:
Et je n’ai plus d’écritures toutes les heures[/quote]
Forcément…

En effet, j’ai exécuté run-parts sur ce répertoire avec strace et il ne semble pas créer de fichier temporaire. J’en déduis que c’est probablement cron lui-même qui le fait, peut-être pour y enregistrer la sortie standard ou d’erreur de la commande exécutée pour traitement ultérieur, comme l’envoi par mail.

J’ai téléchargé le code de CRON et j’ai jeté un oeil vite fait mais je n’ai pas trouvé comment il utilisait le /tmp.
J’ai bien vu la création de fichiers temporaires lorsque l’on édite le crontab mais c’est tout.

Bon il faut que je regarde de nouveau attentivement.

Je ne connais pas trop strace. Tu penses que ce serait possible de le lancer sur CRON directement pour voir ce qu’il fait ?

Merci encore !

strace -f -p $(ps auxf | awk '/[c]ron/{print $2}')

Je viens de faire une trace de cron et ses processus fils. Je ne suis pas un expert en analyse de trace d’appels système, mais il me semble en ressortir les actions suivantes :

  • ouverture d’un fichier avec un nom pseudo-aléatoire dans /tmp/
  • suppression de l’entrée du fichier dans le répertoire (mais tant qu’il reste ouvert il reste présent, bien que plus visible depuis l’arborescence)
  • duplication du descripteur de fichier sur les descripteurs des sorties standard (1) et erreur (2) : tout ce qui est écrit sur ces descripteurs est désormais envoyé dans le fichier temporaire
  • exécution de la commande spécifiée par la ligne de crontab
  • vérification de la taille du fichier, si non nulle lecture et envoi à sendmail.

Super, cela m’aide beaucoup à comprendre le code C de cron.

J’ai trouvé le code suivant qui correspond plus ou moins à ta description dans le fichier do_command.c de cron:

static void child_process(e, u)
{
  ...
  int		stdin_pipe[2], stdout_pipe[2];
  ...
  /* create some pipes to talk to our future child */
  pipe(stdin_pipe);	/* child's stdin */
  pipe(stdout_pipe);	/* child's stdout */
  ...
  /* grandchild process.  make std{in,out} be the ends of
   * pipes opened by our daddy; make stderr go to stdout.
   */
  close(STDIN);	dup2(stdin_pipe[READ_PIPE], STDIN);
  close(STDOUT); dup2(stdout_pipe[WRITE_PIPE], STDOUT);
  ...
  if (*input_data && fork() == 0) {
    register FILE	*out = fdopen(stdin_pipe[WRITE_PIPE], "w");
    ...
  }
}

Par contre avec mes maigres connaissances en C, je ne vois pas trop où le fichier temporaire est créé.
Il me semble que c’est la function “pipe” mais je ne suis pas sûr (c’est un peu la galère de trouver des renseignements sur cela sur Internet).

Un énorme merci pour toute l’aide que je reçois sur ce forum. C’est vraiment super sympa de m’aider !

do_command.c:

        /* child's stdout */
        if ((tmpout = tmpfile()) == NULL) {
                log_it("CRON", getpid(), "error", "create tmpfile");
                exit(ERROR_EXIT);
        }

Bizarre je n’ai pas le même code pour do_command.c.
Je suis allé récupérer le code ici:
ftp.fr.debian.org/debian/pool/ma … rig.tar.gz

Code issu du paquet Debian stable

Ah !
Je crois que j’ai pris le code de cron upstream et pas le code de cron adapté à Debian ?

Le code de cron pour Debian ce doit être celui-là:
anonscm.debian.org/gitweb/?p=pkg … .c;hb=HEAD

Et effectivement dans celui-là on voit la création du fichier temporaire !
Cela voudrait dire que c’est une spécificité Debian ?

Aucune idée
Je te susurre de demander au mainteneur du paquet

Bingo !!!
Voici le commit:
anonscm.debian.org/gitweb/?p=pkg … 14eced70cb

C’est donc la fin de la quête !
CRON créé donc en effet systématiquement un fichier temporaire et cela semble être une spécificité Debian et récente en plus (ce qui expliquerait pourquoi je n’ai pas trouvé beaucoup de renseignements à ce sujet).

Merci à tous ceux qui m’ont aidé sur cette quête très intéressante au demeurant.
L’éventail des outils utilisés pour traquer ce “problème” était très instructif.

Merci encore à tous !