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.
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.
Poser une question
[...]
[...]
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
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.
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 !
Cordialement,
Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%
supprimer "%nospam% et ".invalid" pour me repondre.
Ô 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é.
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.
grep file-max /var/log/messages
kernel: VFS: file-max limit xxx reached