wismerhill a écrit 2602 commentaires

de versions majeures qui figent tout le monde dans un espèce de 1, 2, 3, Soleil immuable avec le dit numéro qui change presque moins souvent qu'on ne sort une nouvelle théorie de la gravité.

Oh, il y en a eu plein, surtout ces dernières années, par contre ça fait presque un siècle qu'on en attends une qui fonctionne.

Regarde la taille totale de sdb (s'il ne te l'affiche pas directement fais la somme des partitions qu'il propose) pour voir si ça correspond au disque dur interne de ton ordinateur.
Tant que tu n'a pas validé le partitionnement, rien n'a été appliqué et tu peux éteindre l'ordinateur brutalement si tu veux.

Les partitions de tes différentes disques sont-elles montées quelque part?
Si non, tu peux le faire temporairement avec la commande mount, ou de façon plus permanente en les ajoutant au fichier fstab.
Il y a probablement des outils graphiques dans linux mint pour faire ça, mais là je laisse répondre quelqu'un qui connait cette distribution.

Si télécharger la totalité des mises à jour en une fois fait déborder ton /var, fais-le en plusieurs fois.
Yum a une option -x (qui prend des glob séparés par des virgules) qui permet d'exclure certains paquets de la mise à jour (tout en respectant les dépendances, bien sur).

Avec sysvinit, j'avais directement les informations sur l'erreur.

Et si ça se passe au démarrage du système ça va être perdu dans tous les messages de démarrage sans moyen d'aller le retrouver, alors qu'avec systemd ce sera quand même dans le journal et tu pourra retrouver l'information.
En plus, un systemctl status t'affiche les dernières lignes du journal pour l'unité concernée.

Si c'est juste pour ces deux commandes là, tu peux aussi les lancer l'une à la suite de l'autre en utilisant une seule entrée de crontab en utilisant des parenthèses. Genre:

* * * * * (python thermometre.py > gna.txt; mail -s "temperature" RRR@gmail.com < gna.txt)


Ou beaucoup plus simplement, envoyer directement la sortie de la première commande dans mail:

python thermometre.py | mail -s "temperature" RRR@gmail.com

Comme ça, pas besoin de fichier temporaire et pas de problème de temps de démarrage.

Et si tu a malgré tout besoin (par exemple à des fin de log)) que les données soient enregistrées dans un fichier tu peux intercaler un tee entre les deux:

python thermometre.py | tee gna.txt | mail -s "temperature" RRR@gmail.com

(et si c'est pour un log, ajouter l'option --append à tee)

Le plus pratique pour faire ce que tu veux (enfin tu n’es pas très précis dans ta demande…), à savoir faire la somme des valeurs de l’une des colonne d’une liste c’est d’utiliser awk

Ou bien tu utilise l'option -c de du qui te donne le total de la taille de tous les arguments.

Et note aussi que du (comme son nom l'indique, «disk usage») mesure par défaut la taille effectivement utilisée dans le système de fichier, en nombre de blocs, qui peut être inférieure ou supérieure à la taille des données utiles des fichiers (celle rapportée par les outils habituels comme ls).
Pour avoir la taille des vrai données des fichiers il faut ajouter l'option --apparent-size.

Hé non, fais le test, cat ne teste un fichier que quand il a fini de traiter le précédent, et comme avec /dev/urandom il n'aura jamais fini, donc tu n'(arrive pas au message d'erreur sur un deuxième fichier qui n'existerait pas.

Mais ça ne devrait pas être ça le problème (ou alors seulement en partie), car > est un opérateur du shell, donc même si le caractère qui suit n'est pas un espace ce sera quand même interprété comme une redirection (sauf si c'est un caractère spécial qui change le type de redirection), mais pas vers le fichier que tu crois. (et là ça peut faire une erreur directe du shell s'il ne peut pas écrire dedans)

Sauf qu'il avait redirigé la sortie dans un fichier, donc il ne devrait y avoir eu aucun effet sur le terminal.

hexa-uple(??)

Si c'est pour dire «seize fois», je dirais hexadécuple (mais je ne sais pas s'il faut le mettre en un ou deux mots).

[supprimé car redondant]

Non

http://blog.cr.yp.to/20140205-entropy.html

• un raid1 c'est un mirroir, donc tu ne peux pas faire un mirroir avec 3 disques.

Heu, tu devrais appliquer ton propre conseil et lire la section consacrée au RAID1:

https://fr.wikipedia.org/wiki/RAID_(informatique)#RAID_1_:_Disques_en_miroir

Il y est bien écrit

Le RAID 1 consiste en l'utilisation de n disques redondants (avec n≥2), chaque disque de la grappe contenant à tout moment exactement les mêmes données, d'où l'utilisation du mot « miroir » (mirroring en anglais).

Chaque disque contenant exactement les même données, tu peux bien entendu en faire autant de copie que tu veux.

l'ai donc vidé (/var/spool/centreontrapd)

Heu, tu es sur qu'il n'y avait rien d'important dedans?

Et ça tombe bien, ce n'est pas activé par défaut, comme l'indique la description du changement indiquée dans le commentaire précédent, il faut ajouter l'option -XX:+UseShenandoahGC pour que ce nouveau GC soit utilisé.

Qui peut être installé sur USB

http://www.system-rescue-cd.org/Sysresccd-manual-en_How_to_install_SystemRescueCd_on_an_USB-stick

Et qui a un tutoriel pour personnaliser le contenu du CD/USB

http://www.system-rescue-cd.org/Sysresccd-manual-en_How_to_personalize_SystemRescueCd

• au contraire de la version awk elle gère un nombre quelconque de colonnes

C'est assez facile à modifier pour inclure un nombre quelconque de colonne (la variable NF est là pour ça).

et niveau efficacité (sur un fichier de 1 000 000 lignes), elle fait mieux que les versions sed ou awk :

Non, ou plus exactement ton test ne permet pas de conclure, car tu n'a mesure que l'exécution de paste, les trois sous-shell avec leurs instances de cut se sont exécuté en parallèle.
Ça peut être une façon intéressante de profiter d'un CPU multi-cœur, mais si tu n'a qu'un cœur CPU ça fait beaucoup plus de changements de contexte ce qui est assez mauvais pour les performances.

Pas terrible question efficacité, puisque tu lance trois sous-shells, trois processus cut et un paste.

Sinon, on peut aussi s'amuser avec sed, et son option -i si on n'a pas peur de perdre ses données

sed -ri 's/^([^ ]+) +([^ ]+) /\2 \1 /' fichier_en_colonnes.txt

(et si on a quand même un peu peur, on ajoutera un suffixe à l'option -i pour préserver la version précédente du fichier)

Met une virgule entre les différents arguments de print, il les considérera ainsi comme des champs différents et intercalera le séparateur de champ de sortie (OFS, qui est un espace par défaut).

Dans le langage awk, l'espace est en fait l'opérateur de concaténation, c'est pour ça que tu n'avais aucun séparateur en sortie.

Juste une remarque, /usr n'est pas le bon endroit pour faire ce genre de modification. Les configurations locales doivent plutôt aller dans /etc (pour avoir une séparation claire entre ce qui est fourni par la distribution dans /usr, et la configuration locale dans /etc).
Donc en l'occurrence, tu devrais plutôt créer ton fichier dans /etc/X11/xorg.conf.d/ (cf la page de manuel xorg.conf).

Gparted est un outil de partitionnement, pas de vérification de disque dur. La seule chose qu'il peut éventuellement réparer, c'est la table de partitions.

Je te conseille d'utiliser gsmartcontrol, c'est uen interface graphique pour smartctl, dans la liste des attributs il t'affichera en fond rouge ceux qui sont considérés comme inquiétants, et au survol de la souris il affiche une explication (si elle est disponible) de la signification des différents attributs (certains n'ont pas la même signification selon le constructeur).

Oui, c'est à craindre, vu sa formulation:

j'ai voulu installer Ubuntu 16.04 […] sur mon disque C:

Si je comprends bien ton besoin, tu veux qu'un script s'exécute au démarrage du système et un autre à l'arrêt.
Tu avais fait ça en utilisant les actions start et stop d'un init script sysV, mais j'ai l'impression que ce n'est pas vraiment le fonctionnement prévu pour ces scripts et que ça fonctionnait par effet de bord (l'init sysV traditionnel n'ayant aucun moyen de savoir si un service fonctionne encore vraiment, il lance tous les stop prévu, qu'il y ait quelque chose à arrêter ou pas).

Systemd a essayer de maintenir autant que possible la compatibilité avec ces scripts d'init, mais il a visé le fonctionnement normal et le scripts qui comptaient sur un effet de bord des limitations d'init sysV ne vont plus forcément fonctionner comme prévu.
En l'occurrence, je pense que systemd constate, après avoir démarré ton «service» qu'il ne reste plus aucun processus qui tourne et en conclu que le service s'est terminé et qu'il n'y a donc plus rien à arrêter.

La solution est de faire un vrai service systemd en tenant compte du fonctionnement (documenté!) de systemd.
Je te recommande de lire les pages de manuel systemd.unit systemd.service et systemd.exec.

En particulier, je pense que l'option importante pour ce que tu veux faire est RemainAfterExit (dans le man systemd.service) qui permet de dire à systemd que le service doit encore être considéré comme actif même si tous les processus se sont terminés.
Tu combine ça avec ExecStart et ExecStop pour définir les scripts à exécuter au démarrage et à l'arrêt (le Type par défaut simple devrait faire l'affaire).
Tu ajoute une section Install où tu indique que ton service est WantedBy multi-user.target (ou celui qui est le plus adapté à ce que tu veux faire).
Un fois que tu systemctl enable ton service il devrait être automatiquement démarré au boot et arrêté au shutdown (parce que par défaut tous les services sont arrêtés au suhtdown, cf le paramètre DefaultDependencies dans man systemd.unit).

Note que si tu veux en plus que ton service soit arrêté quand le système est mis en veille et relancé quand il sort de veille, c'est plus compliqué (j'ai une solution qui fonctionne, mais elle n'est pas très élégante).

Attention, l'option -d de svnserve lui dit de se "daemonizer", c'est à dire de se détacher de lui-même de son processus parent pour tourner en arrière-plan.
Si tu veux fonctionner comme ça, il faut le dire à systemd avec l'option

Type=forking

et pour bien faire il faudrait ajouter l'option PIDFile pour que systemd sache quel est le processus à arrêter, et ajouter à la ligne de commande l'option --pid-file pour dire à svnserve où enregistrer son fichier PID.

Voir la documentation via man systemd.service