SIGALRM en dormant sur Solaris 9

Question

Je suis en cours d'exécution dans un peu d'une erreur bizarre lors de l'exécution Perl dans un environnement chroot sur Solaris 9 (Sparc). Nous sont en utilisant une commande Perl, mais il est presque exactement Perl 5.8.7, et cette version a été en cours d'exécution depuis des années sur différentes plates-formes, y compris Solaris 8-10.

Le code suivant est assez simple:

#!/usr/bin/perl
use strict; 
use warnings;

print "About to sleep(1)\n";
sleep 1;
print "Just woke up!\n";

Cependant, si je lance que, « vient de se réveiller! » n'est jamais imprimé - au lieu, le programme se termine et « réveil » est repris à l'écran. Cela ne se produit s'il y a un sommeil - si j'écris un programme qui fait beaucoup de mathématiques et prend 10 secondes pour courir, tout fonctionne bien. Il arrive aussi que dans un environnement chroot.

Je l'ai largué% SIG, qui a une entrée de « ALRM => FNUD », qui devrait - l'environnement non chrooté a le même comportement. Cependant, si je change le script pour inclure:

$SIG{ALRM} = sub {};

... tout fonctionne très bien. Alors, quel est le problème? Je n'ai pas beaucoup d'expérience avec Solaris, mais il faut que ce soit un moyen de rendre les gestionnaires de signaux par défaut se comportent correctement.

Answer 1

La première chose que je vais essayer est d'exécuter votre programme d'échantillonnage en treillis:

truss testprogram.pl

affiche les appels système réels utilisés pour mettre en œuvre le sommeil. Sur un système Solaris 8 que j'ai accès à la partie pertinente de la sortie est:

write(1, " A b o u t   t o   s l e".., 18)      = 18
time()                                          = 1247258429
alarm(0)                                        = 0
sigaction(SIGALRM, 0xFFBEF6E0, 0xFFBEF790)      = 0
sigfillset(0xFF0C28D0)                          = 0
sigprocmask(SIG_BLOCK, 0xFFBEF780, 0xFFBEF770)  = 0
alarm(1)                                        = 0
    Received signal #14, SIGALRM, in sigsuspend() [caught]
sigsuspend(0xFFBEF760)                          Err#4 EINTR
setcontext(0xFFBEF448)
alarm(0)                                        = 0
sigprocmask(SIG_UNBLOCK, 0xFFBEF780, 0x00000000) = 0
sigaction(SIGALRM, 0xFFBEF6E0, 0x00000000)      = 0
time()                                          = 1247258430
Just woke up!
write(1, " J u s t   w o k e   u p".., 14)      = 14

Sur un hôte Solaris 10, il délivre en sortie:

write(1, " A b o u t   t o   s l e".., 18)      = 18
time()                                          = 1247258270
nanosleep(0xFFBFF770, 0xFFBFF768)               = 0
time()                                          = 1247258271
Just woke up!
write(1, " J u s t   w o k e   u p".., 14)      = 14

Je suppose que vous aurez quelque chose de plus proche de la sortie Solaris 8, et il va probablement montrer sigaction () d'échec d'appel pour une raison quelconque.

Au-delà, je vérifier que les bibliothèques partagées dans le chroot / usr / lib sont en fait les versions correctes pour l'hôte et la version OS. La sortie ferme également vous montrer exactement quelles bibliothèques partagées sont chargées par Perl.

Answer 2

Je recommande de remplacer simplement les appels sleep 1 avec select(undef, undef, undef, 1) et en évitant toute la question.

D'après les symptômes que vous donnez, je parierais que votre script perl chroot'd met en œuvre sleep en termes de SIGALRM (permise par Posix), et que pour une raison perl ne rattrape pas ce signal comme il se doit, peut-être parce qu'il ne s'y attend pas que la mise en œuvre. Est-ce votre version personnalisée de perl? Est-ce une idiosyncrasie dans le libc de chroot'd? Est-ce que perl -e "sleep 1" sous chroot montrent le même problème? Etc, etc. Difficile à dire sans accès à l'environnement et un outil comme ferme .

Encore une fois, la question peut être évité: select ne sera pas muck avec SIGALRM

.

Answer 3

Avez-vous toujours la version de Perl qui vient avec Solaris? Si oui, essayez votre code là-dessus. Si vous ne possédez pas cette version, alors je suggère que le téléchargement Perl 5.8.7 , la compilation d'une version stock, et ensuite tester votre script là-dessus.

Si votre script fonctionne correctement, sur l'une de ces deux versions, alors vous savez que le problème est lié aux changements dans votre version de Perl. Si le script a la même erreur, alors je vous suggère de télécharger Perl 5.8.9 , la compilation, puis vérifier si le bug disparaît. Si elle ne le fait pas, alors, félicitations, vous avez trouvé un bogue dans Perl. Vous voudrez probablement exécuter perlbug pour le signaler.