Encore et toujours des probl=c3=a8mes avec systemd.

Le
BERTRAND Jo=c3=abl
Bonjour à tous,

J'ai toujours des problèmes de scripts de démarrage avec systemd. Ce
matin, après que la bouse a refusé de récupérer tous les processus
défunts permettant à mon serveur principal d'atteindre une charge de 54
avec des processus en état D, d'autres en Z, je décide de redémarrer la
machine.

Et là, boum Non seulement systemd refuse de redémarrer la machine
(j'ai dû l'achever au bouton après la cible shutdown), mais au
redémarrage, j'ai dû relancer certains daemons parce que'OpenVPN refuse
de se lancer correctement au boot.

Je précise que les versions du noyau, de udev et de systemd sont des
versions censées travailler ensemble.

Voici un extrait de mon syslog :

Jun 27 08:51:48 rayleigh ovpn-server_tcp[2178]: TUN/TAP device tap0 opened
Jun 27 08:51:48 rayleigh ovpn-server_tcp[2178]: TUN/TAP TX queue length
set to 100
Jun 27 08:51:48 rayleigh ovpn-server_udp[2177]: TUN/TAP device tap1 opened
Jun 27 08:51:48 rayleigh ovpn-server_udp[2177]: TUN/TAP TX queue length
set to 100
Jun 27 08:51:48 rayleigh ovpn-server_tcp[2178]: do_ifconfig,
tt->did_ifconfig_ipv6_setup=0
Jun 27 08:51:48 rayleigh ovpn-server_udp[2177]: do_ifconfig,
tt->did_ifconfig_ipv6_setup=0
Jun 27 08:51:48 rayleigh ovpn-server_tcp[2178]: /sbin/ip link set dev
tap0 up mtu 1336
Jun 27 08:51:48 rayleigh ovpn-server_udp[2177]: /sbin/ip link set dev
tap1 up mtu 1338
Jun 27 08:51:48 rayleigh ovpn-server_tcp[2178]: /sbin/ip addr add dev
tap0 192.168.2.1/24 broadcast 192.168.2.255
Jun 27 08:51:48 rayleigh ovpn-server_udp[2177]: /sbin/ip addr add dev
tap1 192.168.1.1/24 broadcast 192.168.1.255
Jun 27 08:51:48 rayleigh ovpn-server_udp[2177]:
/etc/openvpn/route-udp-up.sh tap1 1338 1492 192.168.1.1 255.255.255.0 init
Jun 27 08:51:48 rayleigh ovpn-server_tcp[2178]: WARNING: nice -10
failed: Operation not permitted: Operation not permitted (errno=1)


^^^^^^ Sachant que openvpn de lance chez moi en root pour bénéficier
d'un nice -10, pourquoi ai-je cette erreur ?

Jun 27 08:51:48 rayleigh ovpn-server_tcp[2178]: Could not determine
IPv4/IPv6 protocol. Using AF_INET
Jun 27 08:51:48 rayleigh ovpn-server_tcp[2178]: Socket Buffers:
R=[87380->87380] S=[16384->16384]
Jun 27 08:51:48 rayleigh ovpn-server_tcp[2178]: TCP/UDP: Socket bind
failed on local address 192.168.253.1[AF_INET]192.168.253.1:1194: Cannot
assign requested address

^^^^^^^ Même question. Les adresses sont spécifiées dans
/etc/network/interfaces et 192.168.253.1 est bien une adresse valide. On
dirait qu'à ce moment, le réseau n'est pas encore monté. Pourtant, la
cible openvpn.service contient bien :

[Unit]
Description=OpenVPN service
After=network.target

Dans les logs, je vois que cette adresse IP est montée _après_ le
lancement d'openvpn par avahi-daemon :

Jun 27 08:52:29 rayleigh avahi-daemon[2129]: Registering new address
record for 192.168.253.1 on eth2.IPv4.

Forcément, ça se passe mal. La question est donc de savoir comment
corriger ce genre de dysfonctionnement. Effet de bord ? Cycle dans les
dépendances calculées à la hussarde par systemd ?

Merci de vos lumières,

JB

PS : il faudrait peut-être voir à remettre quelque chose de fiable comme
un démarrage systemV ou BSD Au moins en lancer l'idée car systemd ne
va franchement pas en s'améliorant. systemd apporte plus de problèmes
qu'il ne propose de solution. J'ai pour ma part passé des jours à
éplucher le fonctionnement de la chose sans jamais n'avoir de résultat
fiable dès qu'on sort des sentiers balisés et des daemons packagés par
l'équipe de devs de Debian.
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
BERTRAND Jo=c3=abl
Le #26436804
Haricophile a écrit :
Le Tue, 27 Jun 2017 11:10:19 +0200,
BERTRAND Joël
PS : il faudrait peut-être voir à remettre quelque chose de fiable
comme un démarrage systemV ou BSD... Au moins en lancer l'idée car
systemd ne va franchement pas en s'améliorant. systemd apporte plus
de problèmes qu'il ne propose de solution. J'ai pour ma part passé
des jours à éplucher le fonctionnement de la chose sans jamais
n'avoir de résultat fiable dès qu'on sort des sentiers balisés et des
daemons packagés par l'équipe de devs de Debian.

Gentoo n'a pas systemD par défaut, ça peut se faire (^~^) D'ailleurs
Devuan l'a fait.

Le problème de Devuan est le manque de recul et la pérennité de la
distribution. L'intérêt de Debian est d'avoir un support et des
corrections de bugs réactifs. Pour tout ce qui est embarqué ou machines
distantes, c'est important.
Gentoo, je n'ai vraiment pas accroché. Quitte à avoir quelque chose de
rugueux, autant partir sur du BSD ;-)
Pour le reste, il serait intéressant d'avoir le choix chez Debian.
Systemd pour ceux qui veulent essuyer les plâtres sur une machine de
bureau, autre chose pour les machines qui doivent avoir un comportement
fiable et reproductible.
Je râle beaucoup contre systemd. Parce que j'ai investi du temps sur le
truc en me disant que c'était peut-être mieux que cela en avait l'air. À
chaque fois, j'ai été déçu. J'ai contourné des tas de problèmes, mais
là, une configuration qui fonctionnait la veille ne fonctionne plus
parce qu'il y a eu un subtil changement dans l'usine à gaz. Il y a bien
la solution networkd, mais elle n'est pas encore sèche pour accepter
toute ma configuration (ou alors, il faut que je me prenne le chou
durant quelques heures pour comprendre comment la chose traite les
interfaces virtuelles...).
Cordialement,
JB
Gabriel Moreau
Le #26436822
PS : il faudrait peut-être voir à remettre quelque chose de fiable
comme un démarrage systemV ou BSD... Au moins en lancer l'idée car
systemd ne va franchement pas en s'améliorant. systemd apporte plus
de problèmes qu'il ne propose de solution. J'ai pour ma part passé
des jours à éplucher le fonctionnement de la chose sans jamais
n'avoir de résultat fiable dès qu'on sort des sentiers balisés et des
daemons packagés par l'équipe de devs de Debian.

Gentoo n'a pas systemD par défaut, ça peut se faire (^~^) D'ailleurs
Devuan l'a fait.

Debian supporte toujours SystemV ! Pas besoin de Devuan ;-)
Sur un serveur (ou un poste récalcitrant), il est parfois pratique de
faire :
apt-get install sysvinit-core sysvinit-utils systemd-shim systemd-sysv-
Et hop, cela boot vite fait bien fait comme avant...
gaby
--
Gabriel Moreau - IR CNRS http://www.legi.grenoble-inp.fr
LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels
Domaine Universitaire, CS 40700, 38041 Grenoble Cedex 9, France
mailto: tel:+33.476.825.015
BERTRAND Jo=c3=abl
Le #26436972
Bon, à force de tourner le problème dans tous les sens, c'est la cible
networking.service qui ne supporte pas les interfaces virtuelles.
Rapport de bug effectué.
Chose étrange, les services qui ne sont pas lancés automatiquement lors
du boot du serveur peuvent être lancés à la main après, alors que les
prérequis ne sont pas actifs.
Il n'y a pas à dire, c'est franchement pas sec...
Bonne soirée à tous,
JKB
Publicité
Poster une réponse
Anonyme