Cyril Brulebois a écrit 690 commentaires

Tu peux regarder la doc des appels système wait et waitpid, notamment les différentes macros qui permettent de déchiffrer ce qu'il s'est passé : waitpid.2.fr.

Debian Consultant @ DEBAMAX

Non, le chargeur de démarrage lance le noyau. Celui-ci va mettre en place plein de choses, utiliser cet initramfs (qui est juste une archive CPIO, optionnellement compressée) pour lancer init depuis celui-ci. Cet initva faire le nécessaire pour mettre en place le reste du système et passer la main au vrai système init (souvent systemd, de nos jours).

Debian Consultant @ DEBAMAX

Sur Debian 9, ping utilise bien nsswitch, configuré pour utiliser files et dns, et regarde donc /etc/files, lit /etc/resolv.conf et effectue la résolution DNS.

Tu peux utiliser strace pour vérifier les appels système, par exemple avec -f -v -s 400 (je ne vais pas rentrer dans les détails, mais c'est les options qui sont souvent utiles pour commencer). Attention, il faudra peut-être lancer cela avec sudo pour éviter un EPERM (PTRACE vs. capabilities, j'imagine).

Debian Consultant @ DEBAMAX

Ta fonction de traitement de signal utilise des fonctions qui ne sont pas autorisées dans un gestionnaire de signal. Si tu utilises ce genre de fonctions, tu es hors jeu. Tout peut arriver. Undefined Behaviour (UB), c'est potentiellement aller écrire des zéros dans tous tes fichiers, puis tout supprimer, et faire chanter la Marseillaise à ton PC speaker. Cela peut également vouloir dire boucler sans arrêt, ou s'arrêter dès le premier passage dans cette fonction (les différents comportements que je décrivais).

Si tu veux des résultats prédictibles et définis, ne t'expose pas à des comportements indéfinis. Respecte les règles.

Quant aux race conditions, pas vraiment de rapport avec l'électronique à proprement parler. Un système informatique est constitué de plein d'événements concurrents. En fonction du timing, on peut se retrouver avoir des choses qui marchent©®™ ou pas-marchent©®™, par exemple parce que les signaux ont été reçus/traités plus ou moins rapidement, ou dans un ordre donné, ou en interrompant telle autre routine, etc.

Debian Consultant @ DEBAMAX

De mon côté, une fois que j'ai ajouté les #include qui manquent, soit :

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

#define SIGSEGV 11

void fToCallIfSegFault(int sig)
{
    fprintf(stdout, "il y a eu un segfault dans ton code mon coco, le sig = %i\n", sig);
    kill(getpid(), sig);
}

int main(int argc, char const *argv[])
{
    struct sigaction act;
    act.sa_handler = fToCallIfSegFault;
    sigaction(SIGSEGV, &act, NULL);

    //on genere un segfault
    char* str = NULL;
    str[0] = 'c'; //erreur de segmentation

    return 0;
}

J'ai bien ceci en boucle :

il y a eu un segfault dans ton code mon coco, le sig = 11
il y a eu un segfault dans ton code mon coco, le sig = 11
il y a eu un segfault dans ton code mon coco, le sig = 11

… ou bien un arrêt instantané, ou bien un arrêt après plus ou moins longtemps.

Dans mes vieux souvenirs (mais je n'ai pas de source pour cela), il me semble qu'on disait qu'un gestionnaire de signal, sur SIGSEGV du moins, était censé faire une chose et une seule : appeler backtrace, finir de loguer et quitter.

Quoi qu'il en soit, je t'invite à lire (en anglais) cette section de la page wikipedia sur les signaux, notamment la première phrase :

Signal handling is vulnerable to race conditions.

Debian Consultant @ DEBAMAX

C'est effectivement un point qui revient régulièrement dans les formations shell…

Rappel rapide : [ est une commande, donc doit être séparée du if précédent. Puis viennent ses arguments, donc espace également après [. Quant à ], c'est un argument à passer (le dernier) à la commande [ donc doit être séparé des autres arguments. Après le ], pas de contrainte particulière (si on a un ; notamment, il peut être collé).

Exemple sans if pour montrer l'aspect facultatif des séparations en dehors des crochets : [ 0 = 1 ]||[ 1 = 1 ]

Debian Consultant @ DEBAMAX

Ça ne mène pas à l'erreur mentionnée, donc ça ne m'a pas paru pertinent de le mentionner à ce stade. La vie, les priorités, tout ça.

Debian Consultant @ DEBAMAX

Pas si le copier-coller est fidèle (en vérifiant le code markdown).

Et effectivement le code me semble correct.

Et je ne vois rien qui puisse être problématique avec un quelconque shell.

Debian Consultant @ DEBAMAX

Non, l'espace n'est pas nécessaire.

Debian Consultant @ DEBAMAX

Non…

Ici tu filtres pour n'afficher que les entités qui sont à la fois fichier et répertoire… Il te faudrait un -o entre les deux (et ça exclut tout ce qui est b, c, p, s…).

Debian Consultant @ DEBAMAX

Alternative au script dédié, dans ~/.bashrc ou équivalent pour le shell de ton choix :

mymediainfo() {
  mediainfo "$@" | grep 'name\|Width\|Height'
}

Je ne sais pas trop ce que tu entends par coloriser, tu peux préciser ?

Debian Consultant @ DEBAMAX

Yep. Et complément d'information, mkdir -p permet d'éviter ce if.

Debian Consultant @ DEBAMAX

Tu peux commencer par ip link pour voir à quoi ressemblent les différentes interfaces et l'état de chacune.

Exemple sur mon laptop docké (donc Ethernet branché) :

2: eth0: mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether a0:8c:fd:2a:bd:8a brd ff:ff:ff:ff:ff:ff

vs. non docké :

2: eth0: mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
link/ether a0:8c:fd:2a:bd:8a brd ff:ff:ff:ff:ff:ff

Debian Consultant @ DEBAMAX

Cela fait un moment que je n'ai pas eu à faire cela, mais un petit ssh -D 1080 vers une machine dans le bon pays, et un navigateur configuré pour passer par le proxy SOCKS ainsi ouvert, ça m'a dépanné une paire de fois.

(Pour éviter d'avoir à retoucher aux réglages régulièrement, on peut utiliser une extension de type « sélecteur de proxy », ou bien un profil particulier dans Firefox.)

Debian Consultant @ DEBAMAX

C'est toujours une bonne idée de citer la configuration qu'on essaie de faire fonctionner, en complément des éventuels messages d'erreur des commandes lancées.

Debian Consultant @ DEBAMAX

Le fichier include/rt_os_util.h semble avoir le même contenu (modulo des commentaires) que celui du driver fourni par TP Link. Si mon analyse (voir commentaire plus haut) est bonne, cela donnera le même problème de compilation ?

Debian Consultant @ DEBAMAX

À première vue, cela ressemble beaucoup à un problème classique pour les modules qui ne sont pas intégrés dans le noyau : les structures de données et les fonctions dans le noyau évoluent avec le temps, et les composants inclus dans le noyau sont mis à jour au fur et à mesure.

(Dans les cas classiques, le module externe pourrait ne pas être au courant des modifications en question, d'où de possibles incompatibilités/erreurs de compilation.)

Mais pour le coup, il pourrait être question d'un compilateur devenu plus strict avec le temps (cf. l'option -Werror=incompatible-pointer-types)…

Voici le type attendu par la fonction pour le paramètre en question : typedef void (*usb_complete_t)(struct urb *);

Voici le type spécifié dans les sources du module externe (./NETIF/include/rt_os_util.h) : typedef VOID (*USB_COMPLETE_HANDLER)(VOID *);

Tu peux essayer de changer cela en : typedef VOID (*USB_COMPLETE_HANDLER)(struct urb *);

(qui est plus précis sur le type de pointeur manipulé, void* étant générique)

Aucune garantie que cela permette de compiler l'ensemble avec succès, mais est-ce que ça peut être pire que la situation actuelle ? :)

Debian Consultant @ DEBAMAX

Quelques questions:

• Quels sont les paquets boost que tu as installés (libboost-thread-dev, libboost-system-dev, libboost-test-dev ou assimilés) ?
• Où sont les fichiers installés par ces paquets (/usr/include ou assimilé) ?
• Ces emplacements font-ils partie des chemins de recherche par défaut du compilateur ?

D'après un codesearch rapide, le code Meson que tu as cité est explicitement testé dans la suite de test Meson, donc je pense que ça n'est pas la partie problématique…

Debian Consultant @ DEBAMAX

Comme indiqué dans la sortie apt, il a été installé mais ne l'est plus…

Quant à la présence de la commande youtube-dl qui persiste, tu peux vérifier où cette commande est installée, par exemple avec which youtube-dl. Pour localiser les autres fichiers qui pourraient être impliqués, locate youtube-dl (il faudra peut-être installer mlocate ou assimilé, et lancer updatedb en superutilisateur une première fois).

Édition : Oups, j'avais ouvert cette page et ai commenté bien après, sans voir la réponse plus complète de Kerro.

Debian Consultant @ DEBAMAX

Je m'appuie sur un exemple local, mais c'est pareil chez toi :

kibi@armor:~$ dpkg -l xfce4-mixer
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                   Version          Architecture     Description
+++-======================-================-================-==================================================
rc  xfce4-mixer            4.10.0-3         amd64            Xfce mixer application

Les deux lettres r et c dans les premières colonnes correspondent respectivement à Remove et Conf-files.

Autrement dit, le paquet a bien été supprimé, mais des fichiers de configuration sont toujours présents.

Pour le supprimer complètement, c'est l'opération purge plutôt que remove qu'il faut utiliser.

Debian Consultant @ DEBAMAX

Je n'ai pas d'interface gnomesque sous la main, mais je ne suis pas sûr que l'option choisie soit la bonne. Cela pourrait être une variante du français, alors qu'il y a une disposition suisse directement.

Pour vérifier les réglages dans la session en cours :

setxkbmap -print

Exemples pour basculer vers le français en variante OSS, puis vers le suisse :

setxkbmap fr oss
setxkbmap ch

Le second appel me donne bien qwertzu.

Ce réglage n'est que temporaire, je t'invite donc à vérifier que ça fait bien ce que tu veux pour ton clavier, puis à trouver les bonnes options dans l'interface graphique. ;)

Debian Consultant @ DEBAMAX

Étant donné l'existence de https://fwupd.org/ j'aurais tendance à être moins catégorique quant à l'absence totale d'interaction entre OS et UEFI…

Debian Consultant @ DEBAMAX

Ton dossier s'appelle /home/armel/Documents/Archer_T2U_V1_150901(1) et les parenthèses sont probablement le problème ici (il s'agit de caractères spéciaux). Je t'invite à renommer ton répertoire, ça devrait mieux se passer :

mv '/home/armel/Documents/Archer_T2U_V1_150901(1)' /home/armel/Documents/Archer_T2U_V1_150901

Néanmoins, le plus simple est probablement de supprimer le répertoire où le début de compilation a eu lieu, et de partir d'une copie de travail propre (moins de risque d'avoir des choses à moitié compilées dedans, et qui font référence à l'ancien chemin).

Debian Consultant @ DEBAMAX

On peut habituellement forcer l'extinction/l'allumage via DPMS :

xset dpms force off
xset dpms force on

Bien évidemment, la moindre interaction va sortir l'écran de la veille DPMS, donc ça ne remplit pas la fonction de verrouillage.

Debian Consultant @ DEBAMAX

Dans un environnement graphique (X11), les différents périphérique d'entrée peuvent être consultés mais aussi (re)configurés avec la commande xinput.

Exemple sur mon laptop :

$ xinput
⎡ Virtual core pointer                        id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ AlpsPS/2 ALPS GlidePoint                  id=9    [slave  pointer  (2)]
⎜   ↳ ALP000D:00 044E:120C                      id=12   [slave  pointer  (2)]
⎣ Virtual core keyboard                       id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard                 id=5    [slave  keyboard (3)]
    ↳ Power Button                                id=6    [slave  keyboard (3)]
    ↳ Video Bus                                   id=7    [slave  keyboard (3)]
    ↳ Sleep Button                                id=8    [slave  keyboard (3)]
    ↳ HP HD Camera                                id=11   [slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard                id=13   [slave  keyboard (3)]
    ↳ HP Wireless hotkeys                         id=15   [slave  keyboard (3)]
    ↳ HP WMI hotkeys                              id=16   [slave  keyboard (3)]

(Attention, les identifiants numériques ne sont pas fixes.)

Il est possible d'activer/désactiver un périphérique avec xinput --enable 12 et xinput --disable 12 respectivement (ici pour mon touchpad, ALP000D:00 044E:120C).

Si tu fais tourner cela dans une crontab, il faudra faire attention d'avoir les bonnes variables d'environnement positionnées (notamment DISPLAY, et probablement XAUTHORITY), pour que la commande appelée puisse se connecter au serveur d'affichage.

Debian Consultant @ DEBAMAX