Configuration et compilation en tant que root, c'est non.
Règle de base : Ne donner des privilèges que quand c'est strictement nécessaire. En général seulement à l'étape make install (idéalement, après avoir vérifié ce qui est prévu dans cette cible…).
Si mes git skills ne me font pas défaut : il te faut au strict minimum un noyau v4.12-rc1, qui est la première version à contenir le commit 7e040726850a106587485c21bdacc0bfc8a0cbed, qui ajoute plein d'EPOLL*.
Première intuition : une blague entre l'heure système en UTC et un éventuel fuseau horaire (e.g. CET/CEST) ? Du coup ça bloque pendant une demi-heure, mais pas au bon moment ?
Hypothèse que j'imagine facile à valider en ciblant plusieurs plages successives, mais en utilisant la cible LOG (avec un message différent pour chacune) ?
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 ?
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.
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…
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.
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 :
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 :
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.
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).
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).
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.
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 11voidfToCallIfSegFault(intsig){fprintf(stdout,"il y a eu un segfault dans ton code mon coco, le sig = %i\n",sig);kill(getpid(),sig);}intmain(intargc,charconst*argv[]){structsigactionact;act.sa_handler=fToCallIfSegFault;sigaction(SIGSEGV,&act,NULL);//on genere un segfaultchar*str=NULL;str[0]='c';//erreur de segmentationreturn0;}
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 :
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 ]
[^] # Re: abracadaplouf
Posté par Cyril Brulebois (site web personnel) . En réponse au message Compilation de kernel-header. Évalué à 4.
Configuration et compilation en tant que
root
, c'est non.Règle de base : Ne donner des privilèges que quand c'est strictement nécessaire. En général seulement à l'étape
make install
(idéalement, après avoir vérifié ce qui est prévu dans cette cible…).Debian Consultant @ DEBAMAX
[^] # Re: Peut-être avec ce script bash
Posté par Cyril Brulebois (site web personnel) . En réponse au message Commande de suppression par analogie de nom.. Évalué à 5.
Les trois premières lignes sont bien alambiquées, alors que ceci ferait l'affaire (et fonctionnerait quel que soit le shell)…
Debian Consultant @ DEBAMAX
# Noyau trop vieux
Posté par Cyril Brulebois (site web personnel) . En réponse au message Compilation d'un projet (resolu). Évalué à 3.
Si mes git skills ne me font pas défaut : il te faut au strict minimum un noyau v4.12-rc1, qui est la première version à contenir le commit
7e040726850a106587485c21bdacc0bfc8a0cbed
, qui ajoute plein d'EPOLL*
.Pour la définition de
__poll_t
, il s'agit du commit8ced390c2b18364af35e3d3f080e06f8ea96be9a
, qui lui n'apparaît qu'en version v4.16-rc1.Debian Consultant @ DEBAMAX
# Fuseau horaire ?
Posté par Cyril Brulebois (site web personnel) . En réponse au message IPTABLES et la planification horaire. Évalué à 1.
Première intuition : une blague entre l'heure système en UTC et un éventuel fuseau horaire (e.g. CET/CEST) ? Du coup ça bloque pendant une demi-heure, mais pas au bon moment ?
Hypothèse que j'imagine facile à valider en ciblant plusieurs plages successives, mais en utilisant la cible
LOG
(avec un message différent pour chacune) ?Debian Consultant @ DEBAMAX
[^] # Re: Réponse d'un vieux singe
Posté par Cyril Brulebois (site web personnel) . En réponse au message probléme réseau . Évalué à 3.
lsblkid
c'est la fusion delsblk
dansblkid
ou l'inverse ?:)
Debian Consultant @ DEBAMAX
[^] # Re: man pidof
Posté par Cyril Brulebois (site web personnel) . En réponse au message [Solved] [Optimisation] PHP/Bash tester le plus rapidement si un process est actif. Évalué à 2.
Tu penses qu'
exec
est implémenté comment ?Debian Consultant @ DEBAMAX
[^] # Re: man pidof
Posté par Cyril Brulebois (site web personnel) . En réponse au message [Solved] [Optimisation] PHP/Bash tester le plus rapidement si un process est actif. Évalué à 3.
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
[^] # Re: moi
Posté par Cyril Brulebois (site web personnel) . En réponse au message bash : créer des fichiers numérotés successifs. Évalué à 4.
Comme criait mon prof de maths : « Il faut LIRE l'énoncé. »
Debian Consultant @ DEBAMAX
# Quelques pistes
Posté par Cyril Brulebois (site web personnel) . En réponse au message bash : créer des fichiers numérotés successifs. Évalué à 6.
En combinant
find
(éventuellementsed
pour être sûr de ne garder que la partie numérique) etsort
(éventuellement avec son option-n
), tu devrais pouvoir t'en sortir facilement. Cf. égalementprintf
pour la partie génération du fichiern+1
au bon format.Debian Consultant @ DEBAMAX
# Wide strings
Posté par Cyril Brulebois (site web personnel) . En réponse au message Longueur d'une chaine de caractères en itf8. Évalué à 3.
Tout est dans le sujet, bonnes recherches.
Debian Consultant @ DEBAMAX
# dpkg --audit
Posté par Cyril Brulebois (site web personnel) . En réponse au message Énorme connerie, sauvez moi !. Évalué à 5.
La commande
dpkg --audit
devrait t'aider à cibler un certain nombre de points problématiques, en utilisant les infos dedpkg
. Cela ne résoudra pas tout mais…Debian Consultant @ DEBAMAX
[^] # Re: Méthode bulldozer
Posté par Cyril Brulebois (site web personnel) . En réponse au message Supprimer kde-standard. Évalué à 2.
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 (ligneInstall:
) et qui ne sont pas/plus nécessaires. Notons l'option--purge
qui peut être passée à cette commande.Debian Consultant @ DEBAMAX
[^] # Re: Méthode bulldozer
Posté par Cyril Brulebois (site web personnel) . En réponse au message Supprimer kde-standard. Évalué à 2.
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
[^] # Re: what ???
Posté par Cyril Brulebois (site web personnel) . En réponse au message nslookup fonctionne mais pas ping. Évalué à 1.
Pour ce fichier de conf, 640 est suffisant…
Debian Consultant @ DEBAMAX
[^] # Re: what ???
Posté par Cyril Brulebois (site web personnel) . En réponse au message nslookup fonctionne mais pas ping. Évalué à 2.
Je vois un souci avec le
resolv.conf
dans ta trace :On voit bien :
pour la partie
files
et ensuite pour la partiedns
: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) unchmod 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 :
Debian Consultant @ DEBAMAX
[^] # Re: initrd et kernel
Posté par Cyril Brulebois (site web personnel) . En réponse au message initrd et kernel. Évalué à 3.
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 lesmdadm
,lvm2
,cryptsetup
correspondant aux fonctionnalités citées en introduction :Debian Consultant @ DEBAMAX
[^] # Re: what ???
Posté par Cyril Brulebois (site web personnel) . En réponse au message nslookup fonctionne mais pas ping. Évalué à 1.
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 :
juste avant le chargement des fichiers de message pour afficher le message d'erreur.
Debian Consultant @ DEBAMAX
# Noyau
Posté par Cyril Brulebois (site web personnel) . En réponse au message linux me retourne la valeur 139 quand j'ai un segFault (SIGSGEV). Évalué à 2.
Tu peux regarder la doc des appels système
wait
etwaitpid
, notamment les différentes macros qui permettent de déchiffrer ce qu'il s'est passé : waitpid.2.fr.Debian Consultant @ DEBAMAX
# Pas tout à fait
Posté par Cyril Brulebois (site web personnel) . En réponse au message initrd et kernel. Évalué à 5.
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. Cetinit
va faire le nécessaire pour mettre en place le reste du système et passer la main au vrai systèmeinit
(souventsystemd
, de nos jours).Debian Consultant @ DEBAMAX
[^] # Re: what ???
Posté par Cyril Brulebois (site web personnel) . En réponse au message nslookup fonctionne mais pas ping. Évalué à 3.
Sur Debian 9, ping utilise bien nsswitch, configuré pour utiliser
files
etdns
, 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 avecsudo
pour éviter unEPERM
(PTRACE
vs. capabilities, j'imagine).Debian Consultant @ DEBAMAX
[^] # Re: undefined behaviour
Posté par Cyril Brulebois (site web personnel) . En réponse au message probleme avec sigaction. Évalué à 2.
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
# Étrange, mais un (équivalent de) raise() depuis un gestionnaire de signaux…
Posté par Cyril Brulebois (site web personnel) . En réponse au message probleme avec sigaction. Évalué à 2.
De mon côté, une fois que j'ai ajouté les
#include
qui manquent, soit :J'ai bien ceci en boucle :
… 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 : appelerbacktrace
, 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 :
Debian Consultant @ DEBAMAX
[^] # Re: plusieurs erreur de base
Posté par Cyril Brulebois (site web personnel) . En réponse au message probleme if. Évalué à 4.
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 duif
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
[^] # Re: plusieurs erreur de base
Posté par Cyril Brulebois (site web personnel) . En réponse au message probleme if. Évalué à 2.
Ç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
[^] # Re: Le code semble correct mais…
Posté par Cyril Brulebois (site web personnel) . En réponse au message probleme if. Évalué à 2.
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