Doit-on reboot après une mise à jour ?

En ligne depuis le 13 avril 2014

La réponse est simple, nous devons reboot une machine uniquement après une upgrade du kernel ou de la libc… Cependant, certains programmes en cours d’exécution doivent être redémarrés lors d’une upgrade d’une lib…

Une commande assez sympa existe : checkrestart, provenant du packet debian-goodies.
A mon travail, je n’éteins / reboot que très rarement ma machine (Ubuntu) mais je fais une mise à jour assez souvent… Le cas idéal ! A la première version de cet article, je voulais montrer la sortie de la commande checkrestart. Tellement longue, que je t’aurais perdu, toi lecteur.
Voici un exemple avec le serveur hébergeant ce site :

$ sudo checkrestart
Found 30 processes using old versions of upgraded files
(18 distinct programs)
(18 distinct packages)

Of these, 9 seem to contain init scripts which can be used to restart them:
The following packages seem to have init scripts that could be used
to restart them:
opendkim:
12911 /usr/sbin/opendkim
dbus:
19104 /usr/bin/dbus-daemon
squid:
16221 /usr/sbin/squid
16224 /usr/sbin/squid
php5-fpm:
14179 /usr/sbin/php5-fpm
14181 /usr/sbin/php5-fpm
21196 /usr/sbin/php5-fpm
3097 /usr/sbin/php5-fpm
cron:
2187 /usr/sbin/cron
at:
2022 /usr/sbin/atd
rsyslog:
1974 /usr/sbin/rsyslogd
udev:
27769 /sbin/udevd
380 /sbin/udevd
27768 /sbin/udevd
acpid:
2053 /usr/sbin/acpid

These are the init scripts:
service opendkim restart
service dbus restart
service squid restart
service php5-fpm restart
service cron restart
service atd restart
service rsyslog restart
service udev-mtab restart
service udev restart
service acpid restart

These processes do not seem to have an associated init script to restart them:
gamin:
13686 /usr/lib/gamin/gam_server
isc-dhcp-client:
2465 /sbin/dhclient
irssi:
8512 /usr/bin/irssi
mariadb-server-core-5.5:
18190 /usr/sbin/mysqld
consolekit:
1464 /usr/sbin/console-kit-daemon
policykit-1:
1533 /usr/lib/policykit-1/polkitd
bash:
13391 /bin/bash

Après lancement des commandes de redémarrage ci-dessus (service…), voici le résultat :

~$ sudo checkrestart
Found 13 processes using old versions of upgraded files
(7 distinct programs)
(7 distinct packages)
These processes do not seem to have an associated init script to restart them:
gamin:
13686 /usr/lib/gamin/gam_server
isc-dhcp-client:
2465 /sbin/dhclient
irssi:
8512 /usr/bin/irssi
mariadb-server-core-5.5:
18190 /usr/sbin/mysqld
bash:
13391 /bin/bash

Il me reste donc :

  • Mon screen + irssi (avec bash) : facile je coupe tout et je relance
  • MariaDB… étrange qu’il ne soit pas détecté comme démon (bug ?) : un coup de /etc/init.d/mysql restart
  • DHCP, un ptit coup de /etc/init.d/networking restart et c’est reparti !

Et gamin, alors là, j’avoue que je ne sais pas quoi faire… je ne vais pas reboot ?! :(

A+ pour un nouvel épisode !

in_array en Perl

En ligne depuis le 17 avril 2013

Le perl

Bonjour ! Voici un petit article sur le Perl. Oui bon de la programmation dans blog dédié à Debian... je sais, je sais. Mais mon crédo depuis plusieurs années : "si tu peux pas le faire, fait le en Perl". Et pour l'instant ça passe plutôt bien ! Bref, ce que j'aime bien avec Perl, c'est qu'il existe plein de possibilités pour parvenir à ces fins. Malheureusement, quel façon de faire et dans quel contexte ?
Prenons, un cas simple une recherche dans un tableau. En PHP, nous avons la fonction in_array... mais en Perl il existe plusieurs façons de faire. Voici un petit script "benchmark" pour tester 3 techniques :

#!/usr/bin/perl
use Benchmark;
my @list;
for (1..10_000) {
    push @list, $_;
}

timethese(10000, {
  'grep'    => sub {
            if ( grep(/^5000$/o, @list) ) {
                # code
            }
        },
  'hash'    => sub {
            my %params = map { $_ => 1 } @list;
            if ( exists($params{5000}) ) {
                # code
            }
        },
   '~~'	   => sub {
            if ( 5000 ~~ @list ) {
                # code
            }
	}
});
$ perl bench.pl
Benchmark: timing 10000 iterations of grep, hash, ~~...
      grep:  7 wallclock secs ( 6.17 usr +  0.00 sys =  6.17 CPU) @ 1620.75/s (n=10000)
      hash: 33 wallclock secs (33.29 usr +  0.00 sys = 33.29 CPU) @ 300.39/s (n=10000)
        ~~:  1 wallclock secs ( 1.36 usr +  0.00 sys =  1.36 CPU) @ 7352.94/s (n=10000)

Mon interprétation :

  1. grep est utile pour une recherche avec regex. Perf "moyenne"
  2. hash... à oublier !
  3. très performant avec pour des recherches exactes.

J'espère que ce petit test a plu... j'en refaire plein d'autres :)

Soucis avec Dropbox : Please run "echo 100000 | sudo tee /proc/sys/fs/inotify/max_user_watches"

En ligne depuis le 28 février 2013

Petite astuce à connaitre pour éviter de toujours recevoir des erreurs avec Dropbox... Il se peut que ta Dropbox contienne beaucoup de fichiers... mais vraiment beaucoup (comme dans mon cas). Cette erreur qui n'en n'est pas une signifie que inotify ne peut pas scanner tous les fichiers (par défaut 8192 sur Debian Lenny)... Voici la petite astuce du jour pour que ça corrigé "en dur" :

echo "fs.inotify.max_user_watches = 100000" >> /etc/sysctl.conf && sysctl -p