Exécute un seul script Perl instance par cron

J'ai besoin d'exécuter le script Perl par cron périodiquement (~tous les 3 à 5 minutes). Je tiens à vous assurer que seul un script Perl instance va être en cours d'exécution dans le temps, de sorte prochain cycle ne démarre pas jusqu'à ce que la précédente est terminée. Pourrait/Devrait être atteint par certaines fonctionnalités intégrées de cron, Perl ou j'ai besoin de le gérer au niveau de script?

Je suis tout à fait nouveau pour Perl et cron, afin d'aider et de recommandations d'ordre général sont appréciés.

La plate-forme parlez-vous? *nix?
Ça va fonctionner sur linux
blog.booking.com/highlander-daemons-without-daemons.html

InformationsquelleAutor Gennady Shumakher | 2010-02-09

cron perl

14

J'ai toujours eu de la chance de l'aide Fichier::NFSLock pour obtenir un verrou exclusif sur le script lui-même.
```
use Fcntl qw(LOCK_EX LOCK_NB);
use File::NFSLock;

# Try to get an exclusive lock on myself.
my $lock = File::NFSLock->new($0, LOCK_EX|LOCK_NB);
die "$0 is already running!\n" unless $lock;
```
C'est en quelque sorte le même que l'autre fichier de verrouillage des suggestions, sauf que je n'ai pas à faire autre chose que de tenter d'obtenir la serrure.
- Cela fonctionne si le script n'a pas l'autorisation d'écriture?
- Merci! Je l'aime plus, car il est très compact et ne pas écrire n'importe quoi dans le fichier.
- C'est encore à l'aide d'un fichier de verrouillage. Si le script est foo.pl puis il utilise foo.pl.NFSLock par défaut. Si vous avez besoin de la permission d'écriture sur le répertoire.
- J'aime cette solution car elle est simple et ne nécessite qu'une commune module perl. Si vous l'utilisez pour prévenir la tâche cron chevauchements, vous voulez probablement à la sortie sans tracas si vous n'obtenez pas infinies cron e-mails lorsque vous l'exécutez à chaque instant 🙂 utiliser ce lieu de mourir: exit 0 unless $lock;
- Installer, c'est "apt-get install libfile-nfslock-perl"
InformationsquelleAutor oylenshpeegul
11

Utilisation Fichier::Pid pour stocker le pid du script dans un fichier, le script doit vérifier au début, l'abandon et s'il est trouvé. Vous pouvez supprimer le pidfile quand le script est fait, mais ce n'est pas vraiment nécessaire, comme vous pouvez simplement vérifier plus tard pour voir si l'id de processus est encore en vie (ce qui prendra en compte également le cas lorsque le script s'interrompt de façon inattendue):
```
use strict;
use warnings;
use File::Pid;

my $pidfile = File::Pid->new({file => /var/run/myscript});
exit if $pidfile->running();

$pidfile->write();

# ... rest of script...

# end of script
$pidfile->remove();
exit;
```
- J'ai été surpris de ne trouver aucun troupeau appelle dans sa source!
- n'hésitez pas à soumettre un patch 🙂
- Je ne recommanderais pas cette réponse. Vous avez une condition de concurrence (appel d'écrire après l'exécution). C'est probablement jamais être un problème dans une tâche cron, mais mieux éviter encore comme il y a des réponses de meilleure qualité (voir reconnus).
InformationsquelleAutor Ether
11

La Sys::RunAlone module fait ce que vous voulez très bien. Juste ajouter
```
  use Sys::RunAlone;
```
près du haut de votre code.
- +1 après la lecture de ce dans les REMERCIEMENTS (Grâce à) Booking.com pour l'utilisation de cette lourdement dans la production et de me permettre d'améliorer ce module.
InformationsquelleAutor Jonathan A. Marshall

Une approche classique consiste pour chaque processus d'ouverture et de fermeture d'un certain fichier. Ensuite, le processus lit l'ID de processus contenues dans le fichier.

Si un processus d'identification est en cours d'exécution, le retardataire sort tranquillement. Sinon, le nouveau gagnant écrit son numéro de processus ($$ en Perl) pour le pidfile, ferme la poignée (qui libère le verrou), et vaque à ses affaires.

Exemple de mise en œuvre ci-dessous:

#! /usr/bin/perl

use warnings;
use strict;

use Fcntl qw/ :DEFAULT :flock :seek /;

my $PIDFILE = "/tmp/my-program.pid";
sub take_lock {
  sysopen my $fh, $PIDFILE, O_RDWR | O_CREAT or die "$0: open $PIDFILE: $!";
  flock $fh => LOCK_EX                       or die "$0: flock $PIDFILE: $!";

  my $pid = <$fh>;
  if (defined $pid) {
    chomp $pid;
    if (kill 0 => $pid) {
      close $fh;
      exit 1;
    }
  }
  else {
    die "$0: readline $PIDFILE: $!" if $!;
  }

  sysseek  $fh, 0, SEEK_SET or die "$0: sysseek $PIDFILE: $!";
  truncate $fh, 0           or die "$0: truncate $PIDFILE: $!";
  print    $fh "$$\n"       or die "$0: print $PIDFILE: $!";
  close    $fh              or die "$0: close: $!";
}

take_lock;
print "$0: [$$] running...\n";
sleep 2;

InformationsquelleAutor Greg Bacon

1

Autant que je sache, perl n'a pas une telle chose bâtiment. Vous pouvez facilement créer des fichiers temporaires, lorsque vous démarrez votre application et de le supprimer, lorsque le script est terminé.
- Désolé, je prévois de gros problèmes si quelque chose va mal (la machine de redémarrer) et le fichier n'est pas supprimé...
- Juste pour dire, mais si l'ordinateur est redémarré pendant que votre script est en cours d'exécution, vous aurez probablement faire face à des ennuis de toute façon (sauf si le script n'est quelque chose d'extrêmement banal).
- Le redémarrage peut se produire lors de l'exécution de script. Le script est à l'aide de transactions db, donc je suppose qu'il va "survivre" redémarrer la préservation de l'intégrité des données.
- que d'écrire le pid dans ce fichier et vérifier si un processus qui pid est toujours en cours d'exécution.
InformationsquelleAutor ZeissS

J'ai toujours utilisé ce - petit et simple - pas de dépendance sur n'importe quel module et fonctionne à la fois sur Windows + Linux.

use Fcntl ':flock';                    

### Check to make sure there is only one instance ###
open SELF, "< $0" or die("Cannot run two instances of this program");
unless ( flock SELF, LOCK_EX | LOCK_NB ) {
    print "You cannot run two instances of this program , a process is still running";
    exit 1;
}

InformationsquelleAutor PodTech.io

-1

Compte tenu de la fréquence normalement j'écris un démon (serveur) qui joliment attend les bras croisés entre l'exécution du travail (c'est à dire sleep()) plutôt que d'essayer d'utiliser cron pour assez fine des accès.

Si nécessaire, sur les systèmes Unix /Linux vous pouvez exécuter à partir de /etc/inittab (ou de remplacement) pour s'assurer qu'il est toujours en cours d'exécution, et est automatiquement redémarré dans le processus est tué ou meurt.

Ajouté: (et quelque chose sans pertinence supprimé)

Le toujours présent (en cours d'exécution, mais surtout d'inactivité) démon approche a l'avantage d'éliminer la possibilité d'instances simultanées du script en cours d'être lancé par cron automatiquement.

Cependant, vous êtes responsable de la gestion du timing correctement, comme dans le cas de il y a un chevauchement (c'est à dire une exécution précédente est toujours en cours d'exécution, tandis qu'un nouveau déclencher se produit). Cela peut vous aider à décider si vous souhaitez utiliser un fork de démon ou de non-bifurcation de la conception. Les Threads n'apportent aucun avantage dans ce scénario, donc, il n'est pas nécessaire d'envisager leur utilisation.

Ce n'élimine pas complètement la possibilité de multiples processus en cours d'exécution, mais que d'un problème commun à de nombreux démons. La solution classique est d'utiliser un sémaphore comme mutuellement exclusifs verrou sur un fichier, pour éviter une deuxième instance en cours d'exécution. Le fichier de verrouillage est automatiquement oublié lorsque le processus se termine, dans le cas d'un arrêt anormal (par ex. panne de courant) il n'y a pas de nettoyage nécessaire de la serrure elle-même.

Une approche à l'aide de module Fcntl, et à l'aide d'un Perl sysopen avec un O_EXCL drapeau (ou O_RDWR | O_CREAT | O_EXCL) a été donné par Greg Bacon. Les seules différences que j'aimerais apporter sont les combiner de verrouillage exclusif dans le sysopen appel (c'est à dire utiliser les drapeaux, j'ai suggéré), et retirez-le ensuite redondant flock appel. Oh, et je voudrais suivre les UNIX (& Linux FHS) du système de fichiers et les conventions de nommage de /var/run/daemonname.pid.

Une autre approche serait d'utiliser djb de daemontools ou similaire à "daemonize" la tâche.
- L'exécution d'un démon ne pas éliminer les multiples exécution de scripts problème .. c'est facile pour quelqu'un ou quelque chose accidentellement essayer de démarrer une deuxième démon. Vous avez encore besoin d'un fichier PID pour traiter de cette question.
InformationsquelleAutor mctylr

Vous devez vous connecter pour publier un commentaire.