evolix/wiki
22
0
Fork 0
Code Releases Activity

Ajout backticks

Browse source
This commit is contained in:
Benoît S. 2016-12-14 16:34:42 +01:00
parent d3f61261fd
commit 8da6863542
1 changed files with 7 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

14
HowtoSystemd.md
View file

@ -310,29 +310,29 @@ Vérifier que GRUB ne se lance pas avec l'option `init=/lib/sysvinit/init`.
## Bind9 ## Bind9
Sous Debian 8, l'unité par défaut ne gère par les options dans /etc/default/bind Sous Debian 8, l'unité par défaut ne gère par les options dans `/etc/default/bind`.
Voir <http://trac.evolix.net/infogerance/wiki/HowtoDebian/MigrationWheezyJessie#Bind> Voir <http://trac.evolix.net/infogerance/wiki/HowtoDebian/MigrationWheezyJessie#Bind>
## strace Apache (TODO) ## strace Apache (TODO)
Une astuce efficace pour stracer un serveur de type Apache était : strace -s65535 -ff /etc/init.d/apache2 restart. Ensuite on joue la requête et on des infos (impossible à faire en prod bien sûr!). Une astuce efficace pour stracer un serveur de type Apache était : `strace -s65535 -ff /etc/init.d/apache2 restart`. Ensuite on joue la requête et on des infos (impossible à faire en prod bien sûr!).
Avec systemd, le strace ne suit pas les forks malgré -ff. À voir pourquoi systemd empêche ça… Avec systemd, le strace ne suit pas les forks malgré `-ff`. À voir pourquoi systemd empêche ça…
## networking ## networking
Sous Debian 8, le démarrage du système se bloque complètement (dead lock) si l'initialisation de process dépendant du réseau (comme NFS, NTP, firewalling…) se fait avant que le réseau soit démarré. Sous Debian 8, le démarrage du système se bloque complètement (dead lock) si l'initialisation de process dépendant du réseau (comme NFS, NTP, firewalling…) se fait avant que le réseau soit démarré.
Notamment quand ils sont démarrés via des hooks dans /etc/network/if-*/…cela n'était pas bloquant avec SysV, cf https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754218#30 Notamment quand ils sont démarrés via des hooks dans `/etc/network/if-*/`… Cela n'était pas bloquant avec SysV, cf https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754218#30
Astuces « bourrin » : ajouter `exit 0` dans /etc/init.d/networking et voir le souci via systemctl status networking -l ; modifier JobTimeoutUSer => "systemctl show networking -p JobTimeoutUSer" Astuces « bourrin » : ajouter `exit 0` dans `/etc/init.d/networking` et voir le souci via `systemctl status networking -l` ; modifier `JobTimeoutUSer` => `systemctl show networking -p JobTimeoutUSer`
## Failed to get D-Bus connection: Unknown error -1 ## Failed to get D-Bus connection: Unknown error -1
Si en utilisant *systemctl* vous obtenez une erreur "Failed to get D-Bus connection: Unknown error -1" vérifiez si vous êtes bien passé à systemd et n'êtes resté à sysvinit ! Si en utilisant `systemctl` vous obtenez une erreur "Failed to get D-Bus connection: Unknown error -1" vérifiez si vous êtes bien passé à systemd et n'êtes resté à sysvinit !
## systemd-fsck : Dependency failed for File System Check on /dev/disk/xxx ## systemd-fsck : Dependency failed for File System Check on /dev/disk/xxx
Par défaut, systemd-fsck attend 1m30 l'accès à chaque device disque. Pour diverses raisons (accès à un SAN externe, etc.) cela peut échouer, vous aurez alors : Par défaut, `systemd-fsck` attend 1m30 l'accès à chaque device disque. Pour diverses raisons (accès à un SAN externe, etc.) cela peut échouer, vous aurez alors :
~~~ ~~~
systemd[1]: Job dev-disk-by\x2dlabel-foo.device/start timed out. systemd[1]: Job dev-disk-by\x2dlabel-foo.device/start timed out.