Projet

Général

Profil

Bug #75478

Sur un crash dans un job de cron, le statut du tenant n'a pas été posé à terminé bloquant les jobs pendant 1 journée

Ajouté par Benjamin Dauvergne il y a environ un an. Mis à jour il y a environ un an.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Version cible:
-
Début:
15 mars 2023
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Non
Planning:
Non

Description

Cf. #75438-5

La trace qui bloque le cron : https://sentry.entrouvert.org/entrouvert/publik/issues/108094/?environment=prod

AttributeError: 'NoneType' object has no attribute 'cursor'
  File "manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "django/core/management/__init__.py", line 419, in execute_from_command_line
    utility.execute()
  File "django/core/management/__init__.py", line 413, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "django/core/management/base.py", line 354, in run_from_argv
    self.execute(*args, **cmd_options)
  File "django/core/management/base.py", line 398, in execute
    output = self.handle(*args, **options)
  File "wcs/qommon/management/commands/cron.py", line 114, in handle
    sql.mark_cron_status('done')
  File "wcs/sql.py", line 742, in f
    return func(*args, **kwargs)
  File "wcs/sql.py", line 5141, in mark_cron_status
    conn, cur = get_connection_and_cursor()
  File "wcs/sql.py", line 620, in get_connection_and_cursor
    cur = conn.cursor()

effectivement si on a plus de base, il sera difficile de marquer la tâche comme terminée :/ On a le choix soit on attend un peu, soit on pose une pierre tombale ailleurs (genre dans /var/lib/wcs/tenants/<tenant>/cron-crashed) pour récupérer ça au prochain cron.

Demandes liées

Lié à w.c.s. - Development #75647: cron: ne pas bloquer sur une erreur de logRejeté21 mars 2023

Actions

Révisions associées

Révision 76a87e22 (diff)
Ajouté par Frédéric Péters il y a environ un an

cron: reduce stalled job detection to 6 hours (#75478)

Historique

#2

Mis à jour par Benjamin Dauvergne il y a environ un an

Autre approche :
  • ajouter une colonne hearbeat : datetime.
  • régulièrement pendant les jobs appeler un update_cron_hearbeat() pour dire que ça tourne toujours
  • changer la condition à now() - heartbeat > 10 minutes
  • sur un update_cron_hearbeat() si la condition est déjà fausse, crasher proprement (ça veut dire qu'on avance trpo lentement)

On peut peut-être ne pas ajouter de colonne et réutiliser timestamp (code à relire).

#3

Mis à jour par Benjamin Dauvergne il y a environ un an

  • Assigné à mis à Benjamin Dauvergne
#4

Mis à jour par Frédéric Péters il y a environ un an

Avant de lancer quoique ce soit, il y a déjà une détection de cron anormalement coupé :

                    running += 1
                    if now() - timestamp > datetime.timedelta(days=1):
                        stalled_tenants.append(hostname)

Le sujet serait simplement de réduire ce delta ?

#5

Mis à jour par Benjamin Dauvergne il y a environ un an

Il faudrait mettre 20 minutes et ce sera trop court.

#6

Mis à jour par Frédéric Péters il y a environ un an

Quel problème à mettre, par exemple, 6 heures ? Sur le ticket pointé, ça aurait été suffisant. Et la situation (indisponibilité du serveur SQL) est suffisamment anormale et rare. (pour rester sur une correction simple).

#7

Mis à jour par Benjamin Dauvergne il y a environ un an

  • Assigné à Benjamin Dauvergne supprimé

Frédéric Péters a écrit :

Quel problème à mettre, par exemple, 6 heures ? Sur le ticket pointé, ça aurait été suffisant. Et la situation (indisponibilité du serveur SQL) est suffisamment anormale et rare. (pour rester sur une correction simple).

Dans ce cas particulier c'est ok, dans plein d'autres qui demanderont qu'un truc arrive pendant ces 6h ça ne conviendra pas. Je laisse ce ticket.

#8

Mis à jour par Frédéric Péters il y a environ un an

  • Assigné à mis à Frédéric Péters

demanderont qu'un truc arrive pendant ces 6h ça ne conviendra pas

On n'a jamais offert de garantie sur l'exécution, avant la parallélisation des cron on a parfois été bien au-delà des 6 heures, donc perso je doute de ça.

Et ok pour faire moi-même le patch simple.

#9

Mis à jour par Robot Gitea il y a environ un an

  • Statut changé de Nouveau à Solution proposée

Frédéric Péters (fpeters) a ouvert une pull request sur Gitea concernant cette demande :

#10

Mis à jour par Robot Gitea il y a environ un an

  • Statut changé de Solution proposée à Solution validée

Emmanuel Cazenave (ecazenave) a approuvé une pull request sur Gitea concernant cette demande :

#11

Mis à jour par Robot Gitea il y a environ un an

  • Statut changé de Solution validée à Résolu (à déployer)

Frédéric Péters (fpeters) a mergé une pull request sur Gitea concernant cette demande :

#12

Mis à jour par Pierre Ducroquet il y a environ un an

Pour info, on a eu 6 crons plantés hier à cause du plantage du NFS. Aucun log, ils sont restés dans les choux jusqu'à ce matin quand je me suis rendu compte qu'il y avait des tenants sans logs cron. cf #75629

#13

Mis à jour par Benjamin Dauvergne il y a environ un an

Pierre Ducroquet a écrit :

Pour info, on a eu 6 crons plantés hier à cause du plantage du NFS. Aucun log, ils sont restés dans les choux jusqu'à ce matin quand je me suis rendu compte qu'il y avait des tenants sans logs cron. cf #75629

C'est différent du problème ici, sur une trace du à des problèmes NFS le job aurait du être marqué terminé, mais peut-être que ça a planté dans la partie qui log et que le code pour marquer le job comme terminé est après.

#14

Mis à jour par Benjamin Dauvergne il y a environ un an

#15

Mis à jour par Transition automatique il y a environ un an

  • Statut changé de Résolu (à déployer) à Solution déployée
#16

Mis à jour par Transition automatique il y a 10 mois

Automatic expiration

Formats disponibles : Atom PDF