Cyril Brulebois a écrit 652 commentaires

Ce n'est pas un fork.

Tu penses qu'exec est implémenté comment ?

Debian Consultant @ DEBAMAX

Si tu en es à compter les millisecondes, pourquoi forker ? S'il n'y a pas de wrapper PHP pour libproc, consulter /proc directement depuis PHP pourrait améliorer les choses, non ?

Debian Consultant @ DEBAMAX

Comme criait mon prof de maths : « Il faut LIRE l'énoncé. »

Debian Consultant @ DEBAMAX

En combinant find (éventuellement sed pour être sûr de ne garder que la partie numérique) et sort (éventuellement avec son option -n), tu devrais pouvoir t'en sortir facilement. Cf. également printf pour la partie génération du fichier n+1 au bon format.

Debian Consultant @ DEBAMAX

Tout est dans le sujet, bonnes recherches.

Debian Consultant @ DEBAMAX

La commande dpkg --audit devrait t'aider à cibler un certain nombre de points problématiques, en utilisant les infos de dpkg. Cela ne résoudra pas tout mais…

Debian Consultant @ DEBAMAX

Tu peux faire apt-get autoremove avant, noter les éventuels paquets qui seraient mentionnés.

Puis supprimer le paquet que tu avais ajouté (ligne Commandline:).

Puis refaire apt-get autoremove après, ce qui devrait te proposer tous les paquets qui ont été automatiquement installés (ligne Install:) et qui ne sont pas/plus nécessaires. Notons l'option --purge qui peut être passée à cette commande.

Debian Consultant @ DEBAMAX

Pour celles et ceux qui préfèrent regarder ce qu'il s'est passé précédemment et effectuer l'action opposée, il y a les logs apt…

Debian Consultant @ DEBAMAX

Pour ce fichier de conf, 640 est suffisant…

Debian Consultant @ DEBAMAX

Je vois un souci avec le resolv.conf dans ta trace :

openat(AT_FDCWD, "/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission non accordée)

On voit bien :

openat(AT_FDCWD, "/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 5
…
openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_CLOEXEC) = 5

pour la partie files et ensuite pour la partie dns :

openat(AT_FDCWD, "/lib64/libnss_dns.so.2", O_RDONLY|O_CLOEXEC) = 5
…
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 5
connect(5, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, 16) = 0

ce qui est peut-être dû au fait de ne pas avoir réussi à lire /etc/resolv.conf (du type « tentative désespérée faute de configuration lisible ») ? Je reproduis un comportement similaire localement en mettant (temporairement) un chmod 000 /etc/resolv.conf.

Note que se connecter sur localhost en UDP sur le port 53 (connexion IP donc), c'est assez différent d'utiliser nscd, en utilisant une socket UNIX :

connect(5, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ECONNREFUSED (Connexion refusée)

Debian Consultant @ DEBAMAX

Un initramfs ça permet de faire notamment : du RAID, du LVM, du LUKS (même si l'arrivée de la gestion cryptodisks dans GRUB change un peu le dernier point). Et tout plein d'autres choses (comme embarquer un serveur SSH minimaliste pour attendre une connexion et la saisie d'une phrase de passe pour déverrouiller le reste du système).

Un initramfs ça signifie aussi pouvoir utiliser le noyau proposé par sa distribution tout en étant capable de générer des éléments personnalisés dépendant de la configuration déployée sur une machine donnée, plutôt que de s'amuser à compiler un noyau aux petits oignons avec le minimum de modules.

Pour information, la liste des paquets dans Debian 9 qui fournissent des fichiers dans la hiérarchie initramfs-tools, ce qui dépasse largement les mdadm, lvm2, cryptsetup correspondant aux fonctionnalités citées en introduction :

kibi@armor:~$ apt-file search /usr/share/initramfs-tools/|awk -F: '{print $1}'|sort -u
amd64-microcode
aoetools
bcache-tools
bilibop-lockfs
bilibop-rules
bootcd
brltty
btrfs-progs
busybox
busybox-static
cloud-initramfs-dyn-netconf
cloud-initramfs-growroot
cloud-initramfs-rescuevol
cryptsetup
debian-edu-config
dmraid
dmsetup
dropbear-initramfs
fsprotect
fuse
glx-alternative-nvidia
initramfs-tools-core
intel-microcode
iscsiuio
klibc-utils
kmod
kxc
live-boot-initramfs-tools
ltsp-client-core
lvm2
mandos-client
mdadm
multipath-tools-boot
nbd-client
ntfs-3g
open-infrastructure-system-boot
open-iscsi
open-vm-tools-dkms
plymouth
r8168-dkms
sg3-utils-udev
tuxonice-userui
udev
uswsusp
v86d
yubikey-luks
zfs-initramfs
zfsutils-linux

Debian Consultant @ DEBAMAX

Tu as essayé en redémarrant nscd après avoir changé /etc/resolv.conf (ou en supprimant ce service) ?

C'est à lui qu'est posée la question DNS :

[pid  6562] connect(5, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = 0
[pid  6562] sendto(5, "\2\0\0\0\16\0\0\0\n\0\0\0google.fr\0", 22, MSG_NOSIGNAL, NULL, 0) = 22
[pid  6562] poll([{fd=5, events=POLLIN|POLLERR|POLLHUP}], 1, 5000) = 1 ([{fd=5, revents=POLLIN|POLLHUP}])
[pid  6562] read(5, "\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 24) = 24

juste avant le chargement des fichiers de message pour afficher le message d'erreur.

Debian Consultant @ DEBAMAX

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