FreeBSD, MySQL, Perl, bash: blocage intermittent sur les pipes nommés?

Question

Ceci est bizarre et je ne suis pas sûr qui le coupable est vraiment.

Je fais des scripts, sur FreeBSD (6.2)? qui fait un usage intensif des éléments suivants *** *** bash isme:

do_something <(mysql --skip-column-names -B -e 'select ... from ... where ...;')

... où « do_something est un utilitaire peu crufty (en Perl) qui ne sera pas lu d'un pipeline. Si j'utilise un fichier régulier, il fonctionne très bien. Mes bash script en utilisant des choses comme exec 4< <(...) avec ces sortes de requêtes (ci-dessous par des boucles de la forme while read x y z <&4; do ... ne semblent jamais avoir des problèmes.

Cependant, Perl (5.8.x) semble bloquer périodiquement (apparemment pour toujours). J'ai essayé de changer le chomp(my $data = <MYDATA>); avec une routine qui utilise sysread et j'ai écrit quelques cas de test en Python pour la comparaison. Ceux-ci semblent bloquer beaucoup moins souvent que le code idiomatiques Perl, mais ils le font encore parfois. (Le code Python en utilisant f.read() ou os.read(f.fileno()...) semble se comporter à peu près également dans ce numéro).

J'ai essayé de reproduire le problème en utilisant ... <(cat ...) (où je suis chat , du fichier régulier) et qui semble ne jamais reproduire ce décrochage.

Je l'ai regardé à un ktrace / kdump données ... mais je suis beaucoup plus familier avec Linux strace ou même Solaris ferme ... donc je ne l'ai pas compris ce qui se passe à partir de là encore, que ce soit.

Je suppose que la plupart du temps, nous pouvons exclure Perl, parce que j'ai reproduit le même problème en utilisant Python ... Je ne vois pas comment le bash pourrait faire quelque chose de mal ici (il est juste la création un tube nommé dans / var / tmp / sh-np-xxx et le câblage des processus jusqu'à ce que).

Que pourrait faire le mysql shell / utilitaire faire ça pourrait être la cause? Je ne pense pas que je l'ai vu de quoi que ce soit d'autre (comme chat ou dd ). Je ne l'ai pas testé ce scénario sous Linux ... mais je l'ai utilisé <(...) (substitution de processus) pendant des années sous Linux et ne me souviens pas avoir jamais vu cela.

Est-il un problème FreeBSD?

Bien sûr, je peux contourner le problème en utilisant les fichiers temporaires ... mais je vous plutôt comprendre pourquoi il fait cela (et éviter certaines des courses et salissant nettoyage que les fichiers temporaires entraînent).

Toutes les suggestions?

Answer 1

La grande différence entre l'exploitation sur la sortie de MySQL et directement sur un fichier est le timing. Lorsque le processus de perl est bloqué, la grande question est: « pourquoi est-il pas fait avancer le progrès »? Vous pouvez utiliser l'option « l » à ps pour voir le canal d'attente pour le processus de Perl; De cette façon vous pouvez voir si elle bloquée sur une lecture, ou si autre chose se passe. Si elle est vraiment bloqué sur l'entrée du tuyau, je me attends à l'entrée de MWCHAN pour perl être « piperd ».

Les mêmes informations serait intéressant pour le processus de MySQL.

Qu'est-ce que votre code de test Python ressembler?

Une autre façon d'écrire, tout en évitant l'est ce bash; qui vous permettra de excluez bash:

mysql --skip-column-names -B -e 'select ... from ... where ...;' | do_something /dev/stdin

Autres questions intéressantes:

• Est-ce que l'option --unbuffered mysql changer quoi que ce soit?

• Ne redirigeant la sortie de MySQL par dd changer quoi que ce soit? (Par exemple, « PerlScript <(mysql ... |. Dd)

Résumé:. Vous avez besoin d'informations