2007-06-14T19:17:17Z

Regarde dans les différents scripts lancés s'il n'existe pas des références à un quelconque tty ou stty ?

LeDub qui n'a pas lighttpd mais qui apporte, un peu, sa lumière !

2007-06-14T15:52:34Z

Apres moultes tests je me suis rendu compte que c'est le script d'init de lighttpd qui provoque ce probleme. Quand je fais un restart de lighty avant logout, mon terminal se fige. Quand je ne fais rien, tout va bien. J'ignore encore ce qui se passe avec ce script d'init, le voici au cas ou quelqu'un aurait une idee geniale :

#!/bin/sh
### BEGIN INIT INFO
# Provides:          lighttpd
# Required-Start:    networking
# Required-Stop:     networking
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start the lighttpd web server.
### END INIT INFO
PATH=/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/sbin/lighttpd
NAME=lighttpd
DESC="web server"
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
DAEMON_OPTS="-f /etc/lighttpd/lighttpd.conf"
test -x $DAEMON || exit 0
set -e
. /lib/lsb/init-functions
case "$1" in
  start)
    log_daemon_msg "Starting $DESC" $NAME
    if ! start-stop-daemon --start --quiet\
    --pidfile $PIDFILE --exec $DAEMON -- $DAEMON_OPTS ; then
            log_end_msg 1
    else
            log_end_msg 0
    fi
    ;;
  stop)
    log_daemon_msg "Stopping $DESC" $NAME
    if start-stop-daemon --quiet --stop --oknodo --retry 30\
    --pidfile $PIDFILE --exec $DAEMON; then
        rm -f $PIDFILE
        log_end_msg 0
    else
        log_end_msg 1
    fi
    ;;
  reload)
    log_daemon_msg "Reloading $DESC configuration" $NAME
    if start-stop-daemon --stop --signal 2 --oknodo --retry 30\
    --quiet --pidfile $PIDFILE --exec $DAEMON; then
        if start-stop-daemon --start --quiet  \
        --pidfile $PIDFILE --exec $DAEMON -- $DAEMON_OPTS ; then
        log_end_msg 0
        else
        log_end_msg 1
        fi
    else
        log_end_msg 1
    fi
  ;;
  restart|force-reload)
    $0 stop
    [ -r  $PIDFILE ] && while pidof lighttpd |\
         grep -q `cat $PIDFILE 2>/dev/null` 2>/dev/null ; do sleep 1; done
    $0 start
    ;;
  *)
    echo "Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload}" >&2
    exit 1
    ;;
esac
exit 0

2007-06-14T13:47:37Z

Depuis le passage en etch de ton poste, des serveurs ou de tout le monde ?

Et ça marche mieux avec un exit ? (question bête, mais tu précise bien ctrl-D).

ça te fait ça avec n'importe quel serveur ou un spécifique ?

2007-06-14T13:34:24Z

Salut,

J'ai un probleme etrange depuis le passage en etch : parfois (et meme souvent, trop souvent) quand je me deconnecte d'une machine en ssh a l'aide d'un puissant Ctrl-D, je suis deconnecte de la machine mais ssh ne me rend pas la main. Exemple, en me connectant a la machine mogfront04 avec un ssh -vvv :

mogfront04:~# logout
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0

Quand la deconnexion se passe normalement, voila ce que ca donne :

mogfront03:~# logout
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug2: channel 0: rcvd close
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1)
debug3: channel 0: close_fds r -1 w -1 e 6 c -1
Connection to mogfront03 closed.
debug1: Transferred: stdin 0, stdout 0, stderr 34 bytes in 3.6 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 9.5
debug1: Exit status 0
[15:31][yom@goedele][~]

Je precise que les deux machines se parlent sur le meme sous-reseau, sans passer par aucune gateway, et que leurs PTR sont bien renseignes. Quelqu'un aurait-il la moindre idee de ce qui peut bien se passer ? Eventuellement, est-ce que quelqu'un parvient a reproduire le bug ?

a+,