Forum Linux.embarqué Ctrl-c ne fonctionne pas

Posté par  .
Étiquettes : aucune
0
19
juin
2007
Bonjour,

Je suis en train de réaliser un linux emabrqué. Je ne possede q'une seule console.
La commande Ctrl-c ne fonctionne pas lorsque un programme estlancé et que je souhaite l'interrompre.

Savez-vous comment refaire fontionner cette commande ?

Je vous remercie par avance
  • # Deux solution

    Posté par  (site web personnel) . Évalué à 3.

    Bon normalement le Ctrl+c est en fait un envoi de SIGINT au programme si mes souvenirs sont bon.

    Je sais pas exactement comment ça marche mais normalement c'est ton interpréteur qui dois l'envoyer au programme j'imagine.
    (donc si tu as un interpréteur limité ça peux ne pas marcher)

    Après dans ton programme il faut rajouter un masque pour intercepter cet appel et lancer la procédure d'extinction du programme.

    Pour de plus ample voir :
    $ man sigaction

    Bonne chance ;)
  • # handler sur sigint

    Posté par  (site web personnel) . Évalué à 2.

    ctlr+c envoie normalement un sigint à ton programme, c'est peutêtre que dans le programme en question il y a un handler qui intercepte le sigint ?
  • # stty

    Posté par  . Évalué à 4.

    Question bête :
    que te donne la commande "stty -a" ?
    et plus particulièrement le champ intr ?
    • [^] # Re: stty

      Posté par  . Évalué à 2.

      Un bon coup de plussoir pour ce commentaire !
    • [^] # Re: stty

      Posté par  . Évalué à 2.

      Merci pour ton conseil mais j'ai bien "intr = ^C" pour la commande "ssty -a"
  • # busybox

    Posté par  . Évalué à 2.

    Salut,

    c'est sans doute du à un pb de busybox. beaucoup de versions de busybox ont un masque de signal qui par défaut ignore le SIGINT. Si c'est bien ça, alors il faut utiliser un script de lancement de ton programme qui intercepte ton signal.
    De mémoire, j'utilisais quelque chose comme ça:

    ------- 8< -----------------
    #!/bin/sh

    cleanup ()
    {
    echo "interrupted (SIGINT)">&2
    exit -1
    }

    trap cleanup SIGINT
    exec "$@"
    ------- 8< -----------------

    Mettons que tu appelles ce script 'plop' et qu'il soit évidemment dans ton PATH, alors au lieu de faire
    > tail -f /var/log/messages.log
    tu fais
    > plop tail -f /var/log/messages.log

    le C^c est intercepté par 'plop' et l'interruption du programme aurra bien lieu.
    • [^] # Re: busybox

      Posté par  . Évalué à 1.

      Merci pour ton aide mais j'ai quelques probèmes.

      Déjà j'ai remarqué, en faisant un "kill -l" que je n'ai pas SIGINT mais INT pour la ligne '2)'. En fait tout mes nom sont identiques a ceux d'un linux "classique" sans le préfixe 'SIG'. Est-ce que c'est ca le problème ?

      De plus mon repertoire /var/log/ est vide.

      J'ai vu sur des forums de busybox qu'il faut peut etre modifier le fichier inittab. Par contre je ne vois pas quoi modifier:

      ---------------------------------------------
      # inittab This file describes how the INIT process should set up
      # the system in a certain run-level.
      # version busybox


      # System initialization(runs when system boots).
      ::sysinit:/etc/rc.d/rcS

      #demande de login
      ::askfirst:-/bin/sh

      # Start an "askfirst" shell on /dev/tty2-4
      tty2::askfirst:-/bin/sh
      tty3::askfirst:-/bin/sh
      tty4::askfirst:-/bin/sh

      # /sbin/getty invocations for selected ttys
      tty4::respawn:/sbin/getty 38400 tty5
      tty5::respawn:/sbin/getty 38400 tty6

      # Stuff to do when restarting the init process
      ::restart:/sbin/init

      # Stuff to do before rebooting
      ::ctrlaltdel:/sbin/reboot
      ::shutdown:/bin/umount -a -r
      ::shutdown:/sbin/swapoff -a
      -----------------------------------------------

      Merci
      • [^] # Re: busybox

        Posté par  . Évalué à 1.

        Déjà j'ai remarqué, en faisant un "kill -l" que je n'ai pas SIGINT mais INT pour la ligne '2)'
        Ça c'est normal, j'ai ça même sur mon PC.

        Bon par contre mon plop en shell c'est foireux parce que le handler de signal n'est pas hérité par les fils, bien sûr. Ce qu'il faut, c'est un plop qui rétablisse le conportement par défaut du SIGINT. Le 'plop' que j'utilisais était en fait un programme en C qui faisait:
        - rétablissement du comportement souhaité sur récéption des signaux (par défaut à SIG_IGN avec la busybox que j'avais)
        - exec de la commande.
        Les masques de signaux étant hérités, ça le fait bien. Donc plop, ce serait plutôt un truc du genre:

        #include <signal.h>
        #include <unistd.h>

        int main (int argc, char *argv[])
        {
        ++argv;
        if (*argv) {
        signal (SIGINT, SIG_DFL);
        execvp (*argv, argv);
        }
        return 0;
        }

        Pb de cette méthode: il te faut un cross compilo pour compiler ces quelques lignes de C. Et puis ensuite une fois loggué, tu fais tout de suite un 'plop sh' et ça roule pour toute la suite (je viens de tester).

        Pour ce qui est du fichier inittab, je n'avais rien fait et google te sera donc sans doute d'une meilleure aide que moi.
        • [^] # Re: busybox

          Posté par  . Évalué à 1.

          Merci pour ton aide mais ca ne fonctionne toujours pas chez moi :(

          J'ai compilé le programme que tu viens de me donner avec les sources de mon linux avec la busybox (i.e. en croisé). La compilation se déroule bien, je le copie ds un des repertoire du PATH. J'appel "#plop sh", il me donne la version de ma Busybox (comme un 'sh' normal). Mais le Ctrl-C ne fonctionne pas...
          Est-ce que j'ai manqué une étape ??

          Merci
          • [^] # Re: busybox

            Posté par  . Évalué à 1.

            Désolé, je viens de tester et chezmoiçamarche.com . Juste pour être sûr, vérifie que le masque par défaut pour SIGINT était bien SIG_IGN (ignoré):

            #include <stdio.h>
            #include <signal.h>
            #include <unistd.h>

            typedef void (*sighandler_t)(int);

            int main (int argc, char *argv[])
            {
            ++argv;
            if (*argv) {
            sighandler_t hook = signal (SIGINT, SIG_DFL);
            if (hook==SIG_DFL)
            fprintf (stderr, "SIGINT handler was DFL\n");
            else if (hook==SIG_IGN)
            fprintf (stderr, "SIGINT handler was IGN\n");
            execvp (*argv, argv);
            }
            return 0;
            }

            Chez moi:
            # plop sh
            SIGINT handler was IGN


            BusyBox v0.60.4 (2003) Built-in shell (ash)
            Enter 'help' for a list of built-in commands.

            #

            Si ça ne fonctionne pas, alors creuses l'autre piste du inittab.
            • [^] # Re: busybox

              Posté par  . Évalué à 1.

              Ah non mon SIGINT est sur SIG_DFL:

              #plop sh
              SIGINT handler was DFL


              BusyBox v1.3.1 (2007-02-02 11:34:56 CET) Built-in shell (ash)
              Enter 'help' for a list of built-in commands.

              #

              Merci de ton aide
  • # kernel...

    Posté par  (site web personnel) . Évalué à 2.

    SI ton programme est en train de passé du temps dans un appel kernel, un lancement de signal ne sera notifier qu'à son retour.

    Donc, si tu est "bloqué" dans le kernel un ctl-c ne sera pas pris en compte.

    "La première sécurité est la liberté"

    • [^] # Re: kernel...

      Posté par  . Évalué à 1.

      En fait j'ai créé un petit programme user et un ctrl-c ne fonctionne pas.
      C'est un basic while(1) avec un printf et un calcul à la con (juste pour occuper du temps processeur).
      • [^] # Re: kernel...

        Posté par  (site web personnel) . Évalué à 2.

        Cela fait pareil si tu t'excite sur le ctl-c ?

        Tu utilises quoi comme terminal ?

        "La première sécurité est la liberté"

        • [^] # Re: kernel...

          Posté par  . Évalué à 1.

          Si je m'excite sur le Ctrl-c il ne se passe rien.
          Si par contre je fais Ctrl-c sur mon terminal (non utilisé), je psse a la ligne suivante (comme un enter...)

          Mon shell c'est ash (classique car je suis en BusyBox). Je suis en ligne de commande (pas besoin de la gestion graphique car par la suite il n'y aura pas d'écran...).

          Merci de ton aide
          • [^] # Re: kernel...

            Posté par  (site web personnel) . Évalué à 2.

            Si il passe à la ligne, cela veut dire que le système embarqué à capter ton ctl-c (il a reçu l'interruption et traiter le caractère).

            Ton code fait quoi ?

            Si par contre je fais Ctrl-c sur mon terminal (non utilisé), je psse a la ligne suivante (comme un enter...)

            Mais est-ce que cela passe aussi avec ton code de teste ? Et si tu rajoute un usleep() ?

            "La première sécurité est la liberté"

            • [^] # Re: kernel...

              Posté par  . Évalué à 1.

              Dans mon code de test d'utilisation processeur, si je fais un crtl-c il n'y a aucune réaction (ni passage à la ligne, ni afichage d'un caractère....).

              En ajoutant un usleep(10) à chaque boucle dans mon programme, il n'y a aucune incidence, le programme ne s'arrete toujours pas, et rien ne s'affiche.

              Merci

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.