exec x>&y => Device or resource busy !

Le
Cyrille Lefevre
Bonjour,

os : RHEL 4.4
shell : bash 3.0.15
commande : exec 9>&1
symptôme (aléatoire) :
/path/to/script: line XXX: 1: Device or resource busy

une idée ?

Cordialement,

Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%nospam@laposte.net.invalid
supprimer "%nospam% et ".invalid" pour me repondre.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Stephane CHAZELAS
Le #22341531
2010-07-08, 12:03(+02), Cyrille Lefevre:
[...]
os : RHEL 4.4
shell : bash 3.0.15
commande : exec 9>&1
symptôme (aléatoire) :
/path/to/script: line XXX: 1: Device or resource busy

une idée ?


[...]

dup2(2):

EBUSY (Linux only) This may be returned by dup2() or dup3()
during a race condition with open(2) and dup()

pas clair quel est le probleme exactement.

--
Stephane
Cyrille Lefevre
Le #22344381
Le 09/07/2010 13:24, Stephane CHAZELAS a écrit :
2010-07-08, 12:03(+02), Cyrille Lefevre:
[...]
os : RHEL 4.4
shell : bash 3.0.15
commande : exec 9>&1
symptôme (aléatoire) :
/path/to/script: line XXX: 1: Device or resource busy

une idée ?


[...]

dup2(2):

EBUSY (Linux only) This may be returned by dup2() or dup3()
during a race condition with open(2) and dup()

pas clair quel est le probleme exactement.



Bonjour,

j'utilise le fd 9 pour faire passer les messages d'informations
pour ne pas pourrir la sortie standard qui me permet de récupér er
le résultat des commandes. pb, de façon aléatoire, je n'ar rive pas
à créer ce %&^!@ de descripteur, plus de messages...
bien entendu, je n'arrive pas à reproduire ce pb de qq façon qu e ce
soit ! toutefois, cela arrive une fois de temps en temps, la nuit,
durant les sauvegardes soumises en // de façon indépendantes, p b de
charge ?
PS : je ne peux utiliser de fd 2 qui ne sert qu'aux messages d'erreur
et aux traces, c'est dans le cahier des charges...
dernière info, mais je n'ai pas le choix, le kernel est un 2.4 :
Linux nyplsac5 2.6.9-42.0.10.ELsmp #1 SMP Fri Feb 16 17:17:21 EST 2007
i686 i686 i386 GNU/Linux

ex. : rien à voir avec l'implémentation actuelle, mais l'idé e y est...

init() { exec 9>&1 && _FD=9 || _FD=2; }
foo() { echo "$@" >&${_FD:-2}; }
bar() { foo "$@"; "$@"; rc=$?; foo rc=$rc; return $rc; }
init
VGS=$(bar vgs)
...

pout init, j'en suis à la solution suivante, mais sans succès :

if [[ -z ${_FD} ]]; then
if shver 'bash'; then
typeset i=0
for i in 1 2 3 4 0; do
exec 9>&1
coderet=$?
(( coderet == 0 )) && break
sleep 0.5
case $i in
1)
lsof -p $$
sleep 0.5
;;
2)
exec 9>&-
sleep 0.5
;;
3)
typeset r=
read -r r < "${_DEVNULL} "
sleep 0.5
;;
4)
sleep 0.5 &
wait "$!" 2> "${_DEVNULL }"
sleep 0.5
;;
esac
done
(( coderet != 0 )) && _FD=2
else
exec 9>&1
coderet=$?
fi
fi
return $[coderet}

[hors sujet]

le pourquoi de tout bordel est que dans un autre cas, j'avais trouvé un
palliatif assez tordu pour lire dans une succession de fifos, toujours
sous bash. pour autant je n'utilise plus cette solution (historique)
pas assez fiable, mais me contente de récupérer le cr de wait.
interrêt des fifos, possibilité de faire un echo 1 > fifo pour faire
avancer le bignou si besoin.

foo () { ( fifo=$1; shift; "$@"; rc=$?; echo $rc > $fifo ) & }
for fifo in A B; do mkfifo fifo$fifo; done
for fifo in A B; do foo fifo$fifo cmd $fifo ...; done

sans palliatif => Interrupted system call sur le 2ème fifo !

for fifo in A B; do read -r rc < fifo$fifo; done

avec palliatif :

for fifo in A B; do
if shver 'bash'; then
# Linux: Interrupted system call !
read -r rc < "${_DEVNULL}"
sleep "${Delay}" &
wait "$!" 2> "${_DEVNULL}"
fi
read -r rc < fifo$fifo
...
done

solution à base de wait :

foo () { "$@" & pids="$pids $!"; }
for fifo in A B; do cmd $fifo ...; done
for pid in $pids; do wait $pid; rc=$?; ...; done

une alternative à base de top donnerait qqc comme :

foo () { "$@" & pids="$pids $!"; }
for fifo in A B; do cmd $fifo ...; done
while :; do
npids=
for pid in $pids; do
if kill -0 $pid; then
[[ -f $top ]] && break
npids="$npids $pid"
else
wait $pid; rc=$?; ...
fi
done
[[ -z $npids ]] && break
pids=$npids
done

[fin hors sujet]

Cordialement,

Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%
supprimer "%nospam% et ".invalid" pour me repondre.
Cyrille Lefevre
Le #22344411
Le 10/07/2010 16:32, Cyrille Lefevre a écrit :
Le 09/07/2010 13:24, Stephane CHAZELAS a écrit :
2010-07-08, 12:03(+02), Cyrille Lefevre:
[...]
os : RHEL 4.4
shell : bash 3.0.15
commande : exec 9>&1
symptôme (aléatoire) :
/path/to/script: line XXX: 1: Device or resource busy

une idée ?


[...]

dup2(2):

EBUSY (Linux only) This may be returned by dup2() or dup3()
during a race condition with open(2) and dup()

pas clair quel est le probleme exactement.



j'utilise le fd 9 pour faire passer les messages d'informations
pour ne pas pourrir la sortie standard qui me permet de récupé rer
le résultat des commandes. pb, de façon aléatoire, je n' arrive pas
à créer ce %&^!@ de descripteur, plus de messages...



conséquence : lors de la tentative d'écriture sur le fd9, on se prend un
/path/to/script: line XX: 1: Bad file descriptor

pour autant, je trouve bizarre d'avoir 1 et non 9 alors que la ligne est
bien echo ... >&9 ! mais pourquoi pas puisqu'il n'arrive pas à
faire un dup2(1, 9), le write sur 1 se plante... encore que bash devrait
plutôt râler sur dup et non write avec un EBADF !

tiens, je viens même de trouver des :
/path/to/script: line XX: /dev/null: Device or resource busy
trop fort !

pas ex. : ce pb est survenu lundi et mardi, et rien depuis !

bien entendu, je n'arrive pas à reproduire ce pb de qq façon que ce
soit ! toutefois, cela arrive une fois de temps en temps, la nuit,
durant les sauvegardes soumises en // de façon indépendantes, pb de
charge ?



Cordialement,

Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%
supprimer "%nospam% et ".invalid" pour me repondre.
xtof pernod
Le #22344521
Le 10/07/2010 16:47, Cyrille Lefevre a fait rien qu'à écrire:
Le 10/07/2010 16:32, Cyrille Lefevre a écrit :
Le 09/07/2010 13:24, Stephane CHAZELAS a écrit :
2010-07-08, 12:03(+02), Cyrille Lefevre:





tiens, je viens même de trouver des :
/path/to/script: line XX: /dev/null: Device or resource busy
trop fort !



Ô Joliii ! Magnifique ! Inconcevable d’absurdité, de détresse !
J'envoie ça sur le groupe où l'on goûte fort ce genre de délicatesses.

Il s'y trouvera peut-être assorti de quelque commentaire au gout prononcé,
Et si le mainteneur du GFA
Se trouve par là,
Peut-être même y sera-t-il immortalisé.


pas ex. : ce pb est survenu lundi et mardi, et rien depuis !




Un script qui bosse que 2 j. par semaine.. ouais, c'est pas mal.
Y'en a qui bossent moins que ça. (de scripts, hein..)


(Bon, c'est du closed-source, ton script ? Si tu le posais quelque part,
qu'on voit si on reproduit l'effet ?) [gaffe le fu2 auquel cas]

--
christophe.
Stéphane Le Men
Le #22344631
"Cyrille Lefevre"
commande : exec 9>&1
symptôme (aléatoire) :
/path/to/script: line XXX: 1: Device or resource busy

une idée ?





grep file-max /var/log/messages
kernel: VFS: file-max limit xxx reached
xtof pernod
Le #22345821
Le 10/07/2010 19:04, Stéphane Le Men a fait rien qu'à écrire:

"Cyrille Lefevre"
/path/to/script: line XXX: 1: Device or resource busy

une idée ?





grep file-max /var/log/messages
kernel: VFS: file-max limit xxx reached



Ah pinaise.. Une bonne hypothèse, rationelle, plausible, toussa.

Snif alors. Déçu je suis.

Je trouvais cette version-ci au-delà de tout:
/path/to/script: line XX: /dev/null: Device or resource busy

Qui, mais qui osera poser un loquet sur dev/null ? je parle
pas d'y réussir, c'est pas prévu dans le noyau (à vos patches!),
mais rien que le fait d'y conceptualiser..


Sinon, Cyrille, et d'après ce que tu nous dis: fais gaffe que ton
chef lise pas ce groupe, parce que ça va se voir, que tu bourres
la machine en début de semaine, quitte à lui faire exploser une
limite pourtant assez haute, et que comme ça après tu as le reste
de la semaine pour gland^H^H^H^H^Hgeeker.

Ce qui n'est pas une preuve d'incompétence, loin de là, mais si
c'est ton calculos de prod'... =)

--
christophe.
Stephane CHAZELAS
Le #22347291
2010-07-10, 16:32(+02), Cyrille Lefevre:
[...]
init() { exec 9>&1 && _FD=9 || _FD=2; }


[...]

Normalement, si "exec" fail, ca exit le script.

Faut "command exec 9>&1 || ..." pour que le || serve a
quelquechose.

Pour ton probleme, je chercherais dans les archives de lkml pour
des bugs avec "EBUSY" sur "dup2", pour voir comment eviter de
rentrer dedans.

T'as essayé avec un autre shell?

--
Stephane
Cyrille Lefevre
Le #22347811
Le 10/07/2010 19:04, Stéphane Le Men a écrit :
grep file-max /var/log/messages



bien entendu, rien dans messages, j'avais déjà vérifié ...

Cordialement,

Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%
supprimer "%nospam% et ".invalid" pour me repondre.
Cyrille Lefevre
Le #22347821
Le 11/07/2010 21:25, Stephane CHAZELAS a écrit :
2010-07-10, 16:32(+02), Cyrille Lefevre:
[...]
init() { exec 9>&1 && _FD=9 || _FD=2; }


[...]

Normalement, si "exec" fail, ca exit le script.



je t'assure que non, exemple de trace ci-dessous, pas de pj, ça pass e
pas :-(

Faut "command exec 9>&1 || ..." pour que le || serve a
quelquechose.



c'était un exemple, mais le coderet est bien != de 0 dans le cas o u ça
merde, sans plantage du script ! je pense que le command est nécessa ire
si tu fais une redirection sur un fichier qui ne fonctionne pas...

Pour ton probleme, je chercherais dans les archives de lkml pour
des bugs avec "EBUSY" sur "dup2", pour voir comment eviter de
rentrer dedans.



je t'en remercie par avance, de mon côté, je vais faire en sort e que ce
soit escaladé chez RH, mais sans attente particulière, car je n e pense
pas qu'ils vont sortir un patch pour un os vieux de 5 ans.

T'as essayé avec un autre shell?



pour l'heure, le "shell" de l'os est dans le cahier des charges,
sauf pour sun ou j'ai le droit à celui de xpg :-)
en ksh88, pas de pb d'une façon général, mais en bash, que lle merde...
de mémoire, le code fonctionne bien aussi en pdksh, mais il n'a jama is
été qualifié/installé en prod, bash donc...

la pj:

:/exploitation/log# more
monte_snap_avec_InBlock_fa6_mer_err.log
+++ 0:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:285:2:0 + _PEU_FD =9
+++ 0:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:287:2:0 + shver b ash
+++ 0:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:55:2:0 +
typeset trace=
-x
+++ 0:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:55:2:0 + set +x
+++ 0:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:76:2:0 + return 0
+++ 0:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:288:2:0 +
typeset i=0
+++ 0:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:289:2:0 + for i
in 1 2 3
4 0
+++ 0:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:290:2:0 + exec
/exploitation/lib/peu/PeuInit: line 290: 1: Device or resource busy
+++ 0:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:291:2:1 + coderet =1
+++ 0:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:292:2:0 + ((
coderet ==
0 ))
+++ 0:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:293:2:1 + sleep 0 .5
+++ 1:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:294:2:0 + case $i in
+++ 1:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:296:2:0 + lsof
-p 5715
+++ 1:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:297:2:0 + sleep 0 .5
+++ 1:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:289:2:0 + for i
in 1 2 3
4 0
+++ 1:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:290:2:0 + exec
/exploitation/lib/peu/PeuInit: line 290: 1: Device or resource busy
+++ 1:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:291:2:1 + coderet =1
+++ 1:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:292:2:0 + ((
coderet ==
0 ))
+++ 1:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:293:2:1 + sleep 0 .5
+++ 2:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:294:2:0 + case $i in
+++ 2:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:300:2:0 + exec
+++ 2:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:301:2:0 + sleep 0 .5
+++ 2:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:289:2:0 + for i
in 1 2 3
4 0
+++ 2:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:290:2:0 + exec
/exploitation/lib/peu/PeuInit: line 290: 1: Device or resource busy
+++ 2:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:291:2:1 + coderet =1
+++ 2:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:292:2:0 + ((
coderet ==
0 ))
+++ 2:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:293:2:1 + sleep 0 .5
+++ 3:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:294:2:0 + case $i in
+++ 3:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:304:2:0 + typeset r=
+++ 3:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:305:2:0 + read -r r
+++ 3:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:306:2:1 + sleep 0 .5
+++ 3:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:289:2:0 + for i
in 1 2 3
4 0
+++ 3:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:290:2:0 + exec
/exploitation/lib/peu/PeuInit: line 290: 1: Device or resource busy
+++ 3:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:291:2:1 + coderet =1
+++ 3:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:292:2:0 + ((
coderet ==
0 ))
+++ 3:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:293:2:1 + sleep 0 .5
+++ 4:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:294:2:0 + case $i in
+++ 4:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:309:2:0 + sleep 0 .5
+++ 4:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:310:2:0 + wait 71 26
+++ 4:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:311:2:0 + sleep 0 .5
+++ 5:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:289:2:0 + for i
in 1 2 3
4 0
+++ 5:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:290:2:0 + exec
/exploitation/lib/peu/PeuInit: line 290: 1: Device or resource busy
+++ 5:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:291:2:1 + coderet =1
+++ 5:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:292:2:0 + ((
coderet ==
0 ))
+++ 5:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:293:2:1 + sleep 0 .5
+++ 5:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:294:2:0 + case $i in
+++ 5:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:315:2:0 + ((
coderet !=
0 ))
+++ 5:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:315:2:0 + _PEU_FD =2
+++ 5:5715:somehost:PeuMonteSnapModule.sh:PreFilterLog:328:2:0 + set +x

Cordialement,

Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%
supprimer "%nospam% et ".invalid" pour me repondre.
gits
Le #22348591
On 10 juil, 16:32, Cyrille Lefevre <cyrille.lefevre-news
% wrote:
<snip>
> dup2(2):

> EBUSY  (Linux only) This may be returned by dup2() or dup3()
> during a race condition with open(2) and dup()


<snip>
dernière info, mais je n'ai pas le choix, le kernel est un 2.4 :
Linux somehost 2.6.9-42.0.10.ELsmp #1 SMP Fri Feb 16 17:17:21 EST 2007
i686 i686 i386 GNU/Linux



j'ai fumé la moquette, kernel 2.6 et non 2.4 !

je viens de trouver ça :

http://www.mofeel.net/1272-linux-kernel/63341.aspx

résultat obtenu :

# /tmp/ebusy
open()=3 (Success)
close(0)=-1 (Bad file descriptor)
dup2(1, 0)=-1 (Device or resource busy)

en RHEL 4.5, le pb semble corrigé :

# uname -a
Linux somehost 2.6.9-55.0.2.ELsmp #1 SMP Tue Jun 12 17:59:08 EDT 2007
i686 i686 i386 GNU/Linux
# /tmp/ebusy
open()=0 (Success)
close(0)=0 (Success)
dup2(1, 0)=0 (Success)

je vais proposé une monté de version à la prod, on verra plus tard si
le pb est réellement résolu ou non,
en attendant, merci pour votre aide, je vous tiens au courant...

Cordialement,

Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%
supprimer "%nospam% et ".invalid" pour me repondre.
Publicité
Poster une réponse
Anonyme