Re: @^\[@^#{[ de systemd !

[BERTRAND Joël]

Frédéric BOITEUX a écrit :
>   Bonjour,
> 
>> C'est exactement ce que j'utilise. Mais systemd passe par dessus avec des 
>> ifup@.service et autres joyeusetés. Jusqu'à Debian 10, ça passait, mais 
>> aujourd'hui, systemd est le plus fort et laisse les interfaces radio 'down' 
>> en raison de cette dépendance à rfkill. Si je retire rfkill de l'équation, 
>> les interfaces radio sont toujours bloquées par défaut (c'est un 
>> comportement nouveau).
> 
> Juste une piste qui pourrait peut-être expliquer ce blocage au démarrage : il 
> me semble qu'il y a eu un renforcement dans Linux de la vérification des 
> contraintes Wifi liées à chaque pays (voir les paquets crda et 
> wireless-regdb), peut-être que si le pays n'est pas configuré, le wifi est 
> bloqué ?

Bonjour,

J'ai pensé à cela, mais non, tout est bon de ce côté.

RE: @^\[@^#{[ de systemd !

[Frédéric BOITEUX]

Bonjour,

> C'est exactement ce que j'utilise. Mais systemd passe par dessus avec des 
> ifup@.service et autres joyeusetés. Jusqu'à Debian 10, ça passait, mais 
> aujourd'hui, systemd est le plus fort et laisse les interfaces radio 'down' 
> en raison de cette dépendance à rfkill. Si je retire rfkill de l'équation, 
> les interfaces radio sont toujours bloquées par défaut (c'est un comportement 
> nouveau).

Juste une piste qui pourrait peut-être expliquer ce blocage au démarrage : il 
me semble qu'il y a eu un renforcement dans Linux de la vérification des 
contraintes Wifi liées à chaque pays (voir les paquets crda et wireless-regdb), 
peut-être que si le pays n'est pas configuré, le wifi est bloqué ?

Fred.

Re: @^\[@^#{[ de systemd !

[err404]

On 6/30/22 08:55, BERTRAND Joël wrote:
>   Bonjour à tous,
> 
>   J'utilise des rPI 3 comme point d'accès WiFi. Cela fonctionne bien,
> mais depuis la dernière mise à jour de Debian, il y a comme un problème
> lors du démarrage et je suis contraint de démarrer les services à la
> main. Ça m'amuse cinq minutes, pas plus... :-(
> 
>   Jusqu'ici, ces machines utilisaient un script rc.local qui n'est plus
> appelé. Ce script se terminait pas :
> 
> rfkill unblock 0
> ifup wlan0
> iptables-legacy -t nat -A POSTROUTING -s 192.168.11.0/24 -j MASQUERADE
> dhcpd
> exit 0
> 
>   Aujourd'hui, lorsque je démarre un rPI, je me retrouve avec une
> interface wlan0 qui est bloquée par défaut (soft) :
> 
> root@abel:~# rfkill
> ID TYPE  DEVICESOFT  HARD
>  0 wlan  phy0   blocked unblocked
>  1 bluetooth hci0   blocked unblocked
> root@abel:~#
> 
>   Là, je ne comprends pas. L'interface est _toujours_ active lors de
> l'extinction et systemd.restore_state vaut par défaut 1.
> 
>   Si je lance successivement :
> 
> rfkill unblock 0
> ifup wlan0
> hostapd -B -P /run/hostapd.pid /etc/hostapd/hostapd.conf
> dhcpd
> 
> je récupère une borne WiFi fonctionnelle. J'ai donc écrit dans
> /etc/systemd/system les choses suivantes :
> 
> root@abel:/etc/systemd/system# cat rfkill.service
> [Unit]
> Description=rfkill
> Before=ifup@wlan0.service
> After=systemd-rfkill
> 
> [Service]
> Type=oneshot
> ExecStart=/usr/sbin/rfkill unblock 0
> 
> [Install]
> WantedBy=network.target
> 
> root@abel:/etc/systemd/system# cat route.service
> [Unit]
> Description=Wlan route
> After=networking.service
> 
> [Service]
> Type=oneshot
> ExecStart=/usr/sbin/iptables-legacy -t nat -A POSTROUTING -s
> 192.168.11.0/24 -j MASQUERADE
> 
> [Install]
> WantedBy=network.target
> 
> root@abel:/etc/systemd/system# cat dhcpd.service
> [Unit]
> Description=dhcpd
> After=route.service
> 
> [Service]
> Type=forking
> ExecStart=/usr/sbin/dhcpd
> 
> [Install]
> WantedBy=network.target
> 
>   Si route.service et dhcpd.service sont appelés, pas moyen que
> rfkill.service soit appelé au bon moment. Il faut pourtant qu'il soit
> appelé _après_ systemd-rfkill (qui merdoie) et avant que l'interface
> wlan0 soit montée par ifup.service. Lors du démarrage, systemd provoque
> un timeout sur rfkill.service et merdoie sur hostapd.service (là, ce
> n'est pas un timeout, mais des lancements de hostapd en boucle parce que
> wlan0 n'existe pas).
> 
>   Une idée pour corriger la chose, parce que je ne comprends pas trop.
> 
>   Bien cordialement,
> 
>   JKB
> 
pour activer rc.local avec systemd sur une Debian (ou Ubuntu), j'utilise un 
petit script qui crée et active les fichiers 
/etc/systemd/system/rc-local.service et /etc/rc.local
mais il faut quand même éviter de transformer le rc.local en quelque chose de 
trop compliqué, surtout si on peut utiliser les services (que ce soient ceux de 
systemd ou autre)


voici le script (on trouve plein de version différentes sur le web, je donne ça 
ici comme exemple qui fonctionne)
#!/bin/bash


if [ "$EUID" -ne 0 ]
  then echo "Please run as root (use sudo)"
  exit
fi


cat >  /etc/systemd/system/rc-local.service << "EOF"

[Unit]
 Description=/etc/rc.local Compatibility
 ConditionPathExists=/etc/rc.local

[Service]
 Type=forking
 ExecStart=/etc/rc.local start
 TimeoutSec=0
 StandardOutput=tty
 RemainAfterExit=yes
 SysVStartPriority=99

[Install]
 WantedBy=multi-user.target
EOF


cat >> /etc/rc.local << "EOF"
#!/bin/bash
logger "on ne fait rien"
exit 0
EOF

chmod +x /etc/rc.local
systemctl enable rc-local

Re: @^\[@^#{[ de systemd !

[BERTRAND Joël]

Hugues Larrive a écrit :
> --- Original Message --- Le jeudi 30 juin 2022 à 08:55,
> BERTRAND Joël  a écrit :
> 
> 
>> 
> 
>> 
> 
>> Bonjour à tous,
>> 
> 
> Bonjour,

Bonjour,

>> J'utilise des rPI 3 comme point d'accès WiFi. Cela fonctionne
>> bien,
> 
> Moi aussi, il a une bonne portée.
> 
>> mais depuis la dernière mise à jour de Debian, il y a comme un
>> problème lors du démarrage et je suis contraint de démarrer les
>> services à la main. Ça m'amuse cinq minutes, pas plus... :-(
>> 
> 
> Pour en revenir à systemd, c'est bien pour les stations de
> travail, beaucoup moins pour les serveurs ou l'embarqué. Mon pi3
> est en Debian Systemd/Linux (buster), mais maintenant je préfère
> Devuan pour ce genre d'application. C'est un fork de Debian qui
> offre le choix entre 3 systèmes d'init : - le traditionnel sysvinit
> ; - openrc (Gentoo) ; - runit (void linux).

Oui, moi aussi, je vire de plus en plus Debian pour autre chose
(Devuan, mais pas uniquement).

> Il est possible de migrer une debian vers devuan, la procédure est
> sur le site. Il y a un moment ou apt "couine" un peu, mais ça passe
> en insistant un chouya, je l'ai déjà fait trois fois, dont 2
> directement de debian 9 vers devuan chimaera (debian 11).
> 
> Les avantages sont : - un démarrage séquentiel (clarté de la
> console et des journaux) ; - une description claire du démarrage
> dans /etc/rc* ; - pas de "merged /usr" ; - pas de renommage des
> interfaces réseau.

On est parfaitement d'accord, ce ne sont que des avantages, mais là
n'est pas la question.

> L’inconvénient c'est que l'absence de systemd pose des problèmes
> pour les softs qui en dépendent plus ou moins comme lxc...

NetBSD se démerde très bien avec un systemd-fake. Je n'ai jamais
regardé plus que cela, mais j'ai vu passer quelques liens sur les
listes officielles.

>> Jusqu'ici, ces machines utilisaient un script rc.local qui n'est
>> plus appelé. Ce script se terminait pas :
>> 
> 
> Je crois que la commande magique pour qu'il soit de nouveau appelé
> c'est : systemctl unmask rc.local.service

Ne fonctionne pas. Ce n'est pas reproductible d'un démarrage à un
autre, j'ai essayé.

> C'est pas dit que ça fonctionne, il me semble que dans sysvinit,
> rc.local est exécuté tout à la fin donc après networking mais
> qu'avec systemd la cible multi utilisateur qui le déclenche est
> atteinte avant la cible network...

Voilà. Et comme le truc ne démarre pas les daemons dans un ordre
établi...

> De toute façon rc.local n'est pas fait pour ça, voir : 
> https://arkit.co.in/using-rc-local-file-execute-commands/
> 
> Il y a trois façons de configurer le réseau sous debian : -
> /etc/network/interfaces (historique mais pas encore obsolète) ; -
> systemd (moderne...) ; - network-manager (pour les ordinateurs de
> bureau / portable).
> 
> 
> Je pense que la méthode la mieux adaptée pour un point d'accès
> sous debian est /etc/network/interfaces, surtout quand on ne s'en
> sort pas avec systemd. C'est la plus éprouvée et la mieux
> documentée sous debian.

C'est exactement ce que j'utilise. Mais systemd passe par dessus avec
des ifup@.service et autres joyeusetés. Jusqu'à Debian 10, ça passait,
mais aujourd'hui, systemd est le plus fort et laisse les interfaces
radio 'down' en raison de cette dépendance à rfkill. Si je retire
rfkill de l'équation, les interfaces radio sont toujours bloquées par
défaut (c'est un comportement nouveau).

>> rfkill unblock 0 ifup wlan0 iptables-legacy -t nat -A POSTROUTING
>> -s 192.168.11.0/24 -j MASQUERADE dhcpd exit 0
>> 
> 
> 
> Si rfkill est nuisible, autant le supprimer (apt remove rfkill).
> Je n'en vois pas l'utilité sur un point d'accès.
> 

Il faut néanmoins activer l'interface wlan0 qui est désactivée par
défaut depuis la dernière mise à jour du système.

> Pourquoi ne pas avoir utilisé /etc/network/interfaces ? Est-il 
> nécessaire de faire du routage ? Personnellement j'ai préféré 
> utiliser un pont :
> 
> # /etc/network/interfaces auto lo br0 iface lo inet loopback
> 
> iface br0 inet static address 192.168.1.253/24 gateway 192.168.1.1 
> pre-up iw dev wlan0 set type __ap up /etc/nftables.conf #
> 
> # dans /etc/hostapd/hostapd.conf : bridge=br0

Je ne veux pas un pont parce qu'il y a du filtrage et que je tiens
absolument à isoler les réseaux pour des raisons de sécurité. Quant au
réseau, il est géré par /etc/network/interfaces, exclusivement.

JKB

Re: @^\[@^#{[ de systemd !

[Hugues Larrive]

--- Original Message ---
Le jeudi 30 juin 2022 à 08:55, BERTRAND Joël  a 
écrit :


> 

> 

> Bonjour à tous,
> 

Bonjour,

> J'utilise des rPI 3 comme point d'accès WiFi. Cela fonctionne bien,

Moi aussi, il a une bonne portée.

> mais depuis la dernière mise à jour de Debian, il y a comme un problème
> lors du démarrage et je suis contraint de démarrer les services à la
> main. Ça m'amuse cinq minutes, pas plus... :-(
> 

Pour en revenir à systemd, c'est bien pour les stations de travail,
beaucoup moins pour les serveurs ou l'embarqué. Mon pi3 est en
Debian Systemd/Linux (buster), mais maintenant je préfère Devuan pour
ce genre d'application. C'est un fork de Debian qui offre le choix
entre 3 systèmes d'init :
 - le traditionnel sysvinit ;
 - openrc (Gentoo) ;
 - runit (void linux).

Il est possible de migrer une debian vers devuan, la procédure est sur
le site. Il y a un moment ou apt "couine" un peu, mais ça passe en
insistant un chouya, je l'ai déjà fait trois fois, dont 2 directement
de debian 9 vers devuan chimaera (debian 11).

Les avantages sont :
 - un démarrage séquentiel (clarté de la console et des journaux) ;
 - une description claire du démarrage dans /etc/rc* ;
 - pas de "merged /usr" ;
 - pas de renommage des interfaces réseau.

L’inconvénient c'est que l'absence de systemd pose des problèmes pour
les softs qui en dépendent plus ou moins comme lxc...

> Jusqu'ici, ces machines utilisaient un script rc.local qui n'est plus
> appelé. Ce script se terminait pas :
> 

Je crois que la commande magique pour qu'il soit de nouveau appelé c'est :
systemctl unmask rc.local.service

C'est pas dit que ça fonctionne, il me semble que dans sysvinit, rc.local
est exécuté tout à la fin donc après networking mais qu'avec systemd
la cible multi utilisateur qui le déclenche est atteinte avant la cible
network...

De toute façon rc.local n'est pas fait pour ça, voir :
 https://arkit.co.in/using-rc-local-file-execute-commands/

Il y a trois façons de configurer le réseau sous debian :
 - /etc/network/interfaces (historique mais pas encore obsolète) ;
 - systemd (moderne...) ;
 - network-manager (pour les ordinateurs de bureau / portable).
 

Je pense que la méthode la mieux adaptée pour un point d'accès sous
debian est /etc/network/interfaces, surtout quand on ne s'en sort
pas avec systemd. C'est la plus éprouvée et la mieux documentée sous
debian.

> rfkill unblock 0
> ifup wlan0
> iptables-legacy -t nat -A POSTROUTING -s 192.168.11.0/24 -j MASQUERADE
> dhcpd
> exit 0
> 


Si rfkill est nuisible, autant le supprimer (apt remove rfkill). Je
n'en vois pas l'utilité sur un point d'accès. 


Pourquoi ne pas avoir utilisé /etc/network/interfaces ? Est-il
nécessaire de faire du routage ? Personnellement j'ai préféré
utiliser un pont :

# /etc/network/interfaces
auto lo br0
iface lo inet loopback

iface br0 inet static
address 192.168.1.253/24
gateway 192.168.1.1
pre-up iw dev wlan0 set type __ap
up /etc/nftables.conf
#

# dans /etc/hostapd/hostapd.conf :
bridge=br0

Avec cette configuration on obtient un point d'accès "transparent"
au niveau IP : les périphériques wifi sont sur le même sous-réseau
que l'ethernet, il peuvent recevoir une adresse du DHCP de la
passerelle ou d'un serveur, le point d'accès n'a qu'une seul IP
sur br0. Il n'est pas nécessaire d'activer l'IP forwarding ou de
faire du masquerading avec nftables, il faut juste installer
bridge-utils.



Si on préfère isoler le wifi :
 

# /etc/network/interfaces
auto lo eth0 wlan0
iface lo inet loopback

iface eth0 inet dhcp

iface wlan0 inet static
address 192.168.11.254/24
pre-up iw dev wlan0 set type __ap
bridge_ports eth0 wlan0
#

Le script (mode 755) /etc/nftables.conf que j'utiliserais :
#!/usr/sbin/nft -f

flush ruleset

table inet filter {
chain input {
type filter hook input priority 0;
}
chain forward {
type filter hook forward priority 0;
}
chain output {
type filter hook output priority 0;
}
chain postrouting {
type nat hook postrouting priority 100; policy accept;
ip saddr 192.168.11.0/24 oifname eth0 masquerade
}
}
#

J'aime bien les scripts nft probablement à cause des accolades
et de l'indentation. Je les trouves plus lisibles que les
scripts iptables qui m'avaient toujours rebuté.

Avec du filtrage et du NAT/PAT (soyez indulgent, je débute en
nft) ça donnerait ce genre de chose :

#!/usr/sbin/nft -f
#

# nettoyage des règles existantes
flush ruleset

define LAN_IF = eth0
define WLAN_IF = wlan0
define WLAN_NET = 192.168.11.0/24

# un serveur en wifi
define WSRV_IP = 192.168.11.1

# table de filtrage ipv4
table inet filter {

chain output {
# le trafic sortant est autorisé par défaut
type filter hook output priority 0; policy accept;
}

chain inbound {
# le trafic entrant est rejeté par dé

Re: @^\[@^#{[ de systemd !

[BERTRAND Joël]

didier gaumet a écrit :
> 
> 
> Bonjour,

Bonjour,

> Si je ne comprends pas de travers (c'est toujous possible, hein...), je
> pense qu'il s'agit potentiellement d'une caractéristique de Systemd qui
> requiert des instructions assez explicites: 
> - tu spécifies que ton service rfkill doit tourner après ("After=") le
> service systemd-rfkill.
> - Mais ce faisant, littéralement, tu ne spécifies pas que pour toi
> systemd-rfkill *doit* être lancé, donc il ne l'est pas car la clause
> "After=" ne l'implique pas.
> - En plus de la clause "After=" pour le séquencement, il faudrait
> spécifier une clause "Requires=" pour indiquer que tu veux que le
> service ssytemd-rfkill soit lancé
> 
> cf https://wiki.archlinux.org/title/Systemd#Handling_dependencies

Exact. J'ai fait simple parce que systemd-rfkill est lancé sur le
système (et est lancé avant rfkill, je le vois sur la console). Je vais
rajouter cette clause, mais ce n'est pas la bonne réponse ;-)

Bien cordialement,

JKB

Re: @^\[@^#{[ de systemd !

[didier gaumet]

Bonjour,

Si je ne comprends pas de travers (c'est toujous possible, hein...), je
pense qu'il s'agit potentiellement d'une caractéristique de Systemd qui
requiert des instructions assez explicites: 
- tu spécifies que ton service rfkill doit tourner après ("After=") le
service systemd-rfkill.
- Mais ce faisant, littéralement, tu ne spécifies pas que pour toi
systemd-rfkill *doit* être lancé, donc il ne l'est pas car la clause
"After=" ne l'implique pas.
- En plus de la clause "After=" pour le séquencement, il faudrait
spécifier une clause "Requires=" pour indiquer que tu veux que le
service ssytemd-rfkill soit lancé

cf https://wiki.archlinux.org/title/Systemd#Handling_dependencies

Re: @^\[@^#{[ de systemd !

[NoSpam]

Bonjour,


pas de réponse, j'ai abandonné depuis longtemps. Je fais dans crontab root

@reboot /usr/local/bin/aafterReboot.sh

et le script

#!/bin/bash

debug=false
second=0
max_time=10

while [ "$second" -lt "$max_time" ]; do
  sleep 1
  second=$((second+1))
  [ $debug = true ] && echo $second

  case $second in
    1)
  ;;
    2)
  ;;
    3)
  ;;
    4)
  ;;
    5)
  ;;
    6)
  ;;
    7)
  ;;
    8)
  ;;
    9)
  ;;
    10)
  ;;
    *)
  ;;
  esac
done

exit 0

et je suis heureux :)

Le 30/06/2022 à 08:55, BERTRAND Joël a écrit :

Bonjour à tous,

J'utilise des rPI 3 comme point d'accès WiFi. Cela fonctionne bien,
mais depuis la dernière mise à jour de Debian, il y a comme un problème
lors du démarrage et je suis contraint de démarrer les services à la
main. Ça m'amuse cinq minutes, pas plus... :-(

Jusqu'ici, ces machines utilisaient un script rc.local qui n'est plus
appelé. Ce script se terminait pas :

rfkill unblock 0
ifup wlan0
iptables-legacy -t nat -A POSTROUTING -s 192.168.11.0/24 -j MASQUERADE
dhcpd
exit 0

Aujourd'hui, lorsque je démarre un rPI, je me retrouve avec une
interface wlan0 qui est bloquée par défaut (soft) :

root@abel:~# rfkill
ID TYPE  DEVICESOFT  HARD
  0 wlan  phy0   blocked unblocked
  1 bluetooth hci0   blocked unblocked
root@abel:~#

Là, je ne comprends pas. L'interface est _toujours_ active lors de
l'extinction et systemd.restore_state vaut par défaut 1.

Si je lance successivement :

rfkill unblock 0
ifup wlan0
hostapd -B -P /run/hostapd.pid /etc/hostapd/hostapd.conf
dhcpd

je récupère une borne WiFi fonctionnelle. J'ai donc écrit dans
/etc/systemd/system les choses suivantes :

root@abel:/etc/systemd/system# cat rfkill.service
[Unit]
Description=rfkill
Before=ifup@wlan0.service
After=systemd-rfkill

[Service]
Type=oneshot
ExecStart=/usr/sbin/rfkill unblock 0

[Install]
WantedBy=network.target

root@abel:/etc/systemd/system# cat route.service
[Unit]
Description=Wlan route
After=networking.service

[Service]
Type=oneshot
ExecStart=/usr/sbin/iptables-legacy -t nat -A POSTROUTING -s
192.168.11.0/24 -j MASQUERADE

[Install]
WantedBy=network.target

root@abel:/etc/systemd/system# cat dhcpd.service
[Unit]
Description=dhcpd
After=route.service

[Service]
Type=forking
ExecStart=/usr/sbin/dhcpd

[Install]
WantedBy=network.target

Si route.service et dhcpd.service sont appelés, pas moyen que
rfkill.service soit appelé au bon moment. Il faut pourtant qu'il soit
appelé _après_ systemd-rfkill (qui merdoie) et avant que l'interface
wlan0 soit montée par ifup.service. Lors du démarrage, systemd provoque
un timeout sur rfkill.service et merdoie sur hostapd.service (là, ce
n'est pas un timeout, mais des lancements de hostapd en boucle parce que
wlan0 n'existe pas).

Une idée pour corriger la chose, parce que je ne comprends pas trop.

Bien cordialement,

JKB

@^\[@^#{[ de systemd !

[BERTRAND Joël]

Bonjour à tous,

J'utilise des rPI 3 comme point d'accès WiFi. Cela fonctionne bien,
mais depuis la dernière mise à jour de Debian, il y a comme un problème
lors du démarrage et je suis contraint de démarrer les services à la
main. Ça m'amuse cinq minutes, pas plus... :-(

Jusqu'ici, ces machines utilisaient un script rc.local qui n'est plus
appelé. Ce script se terminait pas :

rfkill unblock 0
ifup wlan0
iptables-legacy -t nat -A POSTROUTING -s 192.168.11.0/24 -j MASQUERADE
dhcpd
exit 0

Aujourd'hui, lorsque je démarre un rPI, je me retrouve avec une
interface wlan0 qui est bloquée par défaut (soft) :

root@abel:~# rfkill
ID TYPE  DEVICESOFT  HARD
 0 wlan  phy0   blocked unblocked
 1 bluetooth hci0   blocked unblocked
root@abel:~#

Là, je ne comprends pas. L'interface est _toujours_ active lors de
l'extinction et systemd.restore_state vaut par défaut 1.

Si je lance successivement :

rfkill unblock 0
ifup wlan0
hostapd -B -P /run/hostapd.pid /etc/hostapd/hostapd.conf
dhcpd

je récupère une borne WiFi fonctionnelle. J'ai donc écrit dans
/etc/systemd/system les choses suivantes :

root@abel:/etc/systemd/system# cat rfkill.service
[Unit]
Description=rfkill
Before=ifup@wlan0.service
After=systemd-rfkill

[Service]
Type=oneshot
ExecStart=/usr/sbin/rfkill unblock 0

[Install]
WantedBy=network.target

root@abel:/etc/systemd/system# cat route.service
[Unit]
Description=Wlan route
After=networking.service

[Service]
Type=oneshot
ExecStart=/usr/sbin/iptables-legacy -t nat -A POSTROUTING -s
192.168.11.0/24 -j MASQUERADE

[Install]
WantedBy=network.target

root@abel:/etc/systemd/system# cat dhcpd.service
[Unit]
Description=dhcpd
After=route.service

[Service]
Type=forking
ExecStart=/usr/sbin/dhcpd

[Install]
WantedBy=network.target

Si route.service et dhcpd.service sont appelés, pas moyen que
rfkill.service soit appelé au bon moment. Il faut pourtant qu'il soit
appelé _après_ systemd-rfkill (qui merdoie) et avant que l'interface
wlan0 soit montée par ifup.service. Lors du démarrage, systemd provoque
un timeout sur rfkill.service et merdoie sur hostapd.service (là, ce
n'est pas un timeout, mais des lancements de hostapd en boucle parce que
wlan0 n'existe pas).

Une idée pour corriger la chose, parce que je ne comprends pas trop.

Bien cordialement,

JKB

Re: Un autre effet Kiskool de systemd !

[BERTRAND Joël]

BOITEUX, FREDERIC a écrit :
>   Bonjour,
> 
>   Ton souci me fait penser à un souci que j'avais eu, à propos de Systemd qui 
> supprimait toutes les SHM créées par un utilisateur quand sa dernière session 
> se terminait : cela avait pour effet de tuer un éventuel démon lancé par 
> l'utilisateur (un serveur Postgresql par exemple !).
> J'avais dû positionner le paramètre « RemoveIPC=no » dans 
> /etc/systemd/logind.conf.
> 
> C'est pas sûr que cela t'aide, mais au cas où…

Bonjour,

Je note, mais ça ne semble pas être mon problème. Ça ressemblerait dans
mon cas plus à un watchdog (mais le système n'est pas planté, seule une
application peut ramer en attente de swap).

Bien cordialement,

JKB

Re: [HS] Re: Un autre effet Kiskool de systemd !

[Fabien R]

On 19/05/2020 11:33, BERTRAND Joël wrote:
> NoSpam a écrit :
>>
>> Le 19/05/2020 à 10:15, BERTRAND Joël a écrit :
>>> [...]
>>> Ce qui serait vraiment intéressant, c'est que Debian propose avec ou
>>> sans systemd (pour tous ses paquets d'ailleurs),
>>
>> Cela s'appelle devuan.org
> 
>   Sur le papier, oui. Mais as-tu testé devuan ? 
Moi, je l'utilise à la place de debian.
Ca fonctionne très bien.
L'audience n'est pas
> assez grande pour en faire un système utilisable sans problème.
Tu peux développer ?

--
Fabien

Un autre effet Kiskool de systemd !

[BOITEUX, FREDERIC]

Bonjour,

  Ton souci me fait penser à un souci que j'avais eu, à propos de Systemd qui 
supprimait toutes les SHM créées par un utilisateur quand sa dernière session 
se terminait : cela avait pour effet de tuer un éventuel démon lancé par 
l'utilisateur (un serveur Postgresql par exemple !).
J'avais dû positionner le paramètre « RemoveIPC=no » dans 
/etc/systemd/logind.conf.

C'est pas sûr que cela t'aide, mais au cas où…

Cdlt,
Fred.
This message contains information that may be privileged or confidential and is 
the property of the Capgemini Group. It is intended only for the person to whom 
it is addressed. If you are not the intended recipient, you are not authorized 
to read, print, retain, copy, disseminate, distribute, or use this message or 
any part thereof. If you receive this message in error, please notify the 
sender immediately and delete all copies of this message.

Re: [HS] Re: Un autre effet Kiskool de systemd !

[NoSpam]

Le 19/05/2020 à 10:15, BERTRAND Joël a écrit :

[...]
Ce qui serait vraiment intéressant, c'est que Debian propose avec ou
sans systemd (pour tous ses paquets d'ailleurs),


Cela s'appelle devuan.org

--

Daniel

Re: [HS] Re: Un autre effet Kiskool de systemd !

[didier gaumet]

Disons que j'ai peut-être tort, mais je pense qu'ici tu envisages ton
problème d'un manière plus subjective que rationnelle et que ça te
pénalise dans sa résolution :-)

Je suis loin d'être compétent sur les systèmes de démarrage pseudo-unix
en général et Systemd en particulier, qui ne se résume pas à ce rôle,
donc je ne vais pas trop m'étendre.
Mais je pense que l'un des points qui gênent, souvent inconsciemment,
les critiques de Systemd est que de facto, on a transféré des
responsabilités: autrefois sous SysV, le caractère fonctionnel ou non
d'un daemon était plus ou moins en partie caractérisé par la qualité de
son script Sysv de démarrage, écrit par l'équipe de développement
upstream du logiciel concerné. Avec Systemd j'ai l'impression qu'une
partie du caractère opérationnel du système d'exploitation et du
logiciel concerné (via son service) repose -c'est nouveau- sur
l'administrateur du système d'exploitation.
 En gros, avec SysV, suivant où était placé le script du dameon dans la
chaîne d'initialisation, c'était binaire: ça démarrait et ça
fonctionnait, ou non. Systemd demanderait plutôt une démarche
d'intégration de système et pénaliserait l'administrateur du système par
un fonctionnement non-optimisé lorsque la réflexion de l'administrateur
a été trop vague ("Systemd, me fais pas chier, j'veux qu'tu démarres
daemon1, pose pas de questions")

Je pense que la majorité des problèmes se pose pour ceux qui souhaitent
utiliser Systemd de la même manière que SysV auparavant alors que ce
n'est pas prévu (tu as déjà dû connaître ça du temps de la guéguerre
SysV/rc: "SysV c'est de la merde", et on cause même pas des
ordonnancements par cartes perforées)

Que l'on soit heureux ou malheureux de ces tendances, de facto:
- Debian c'est basé sur Linux (Debian/Hurd est assez anecdotique,
Debian/kNetBSD est mort-né, Debian/kFreeBSD n'a pas vraiment survécu)
- Linux c'est de plus en plus Systemd en termes d'adoption
- selon moi en OS libres sur desktop ou laptop, sortir de Linux c'est
chercher les ennuis (j'ai utilisé NetBSD plus que Free ou Open, y a très
longtemps). En desktop ça s'est beaucoup dégradé, en laptop ça n'a
jamais été vraiment pertinent (opinion perso, comme le reste). (Dans la
recherche Distrowatch suscitée figurent tous les BSD)

Donc, pour moi, soit tu mets ton dégoût de côté et tu solutionneras plus
facilement tes problèmes Systemd par une approche moins subjective
("quelle merde ce truc, c'est normal que ça marche pas"), soit le dégoût
en question est trop fort et tu sautes le pas pour te passer de Systemd
(ce qui peut signifier cesser d'utiliser certains logiciels ou certains OS)

KISS et le principe "tout-est-fichier" c'est bien tant que ça ne devient
pas un dogme qui empêche l'atteinte de tes objectifs. Le paroxysme du
KISS c'est l'immobilisme et y a eu une vie informatique avant le
"tout-est-fichier" :-)

Je reconnais bien volontiers que je suis un utilisateur basique de
laptop donc que je ne figure pas parmi ceux que Systemd peut le plus
gêner :-)

Fin de la parenthèse, je m'arrête là :-)

Re: [HS] Re: Un autre effet Kiskool de systemd !

[BERTRAND Joël]

NoSpam a écrit :
> 
> Le 19/05/2020 à 10:15, BERTRAND Joël a écrit :
>> [...]
>> Ce qui serait vraiment intéressant, c'est que Debian propose avec ou
>> sans systemd (pour tous ses paquets d'ailleurs),
> 
> Cela s'appelle devuan.org

Sur le papier, oui. Mais as-tu testé devuan ? L'audience n'est pas
assez grande pour en faire un système utilisable sans problème.

[HS] Re: Un autre effet Kiskool de systemd !

[BERTRAND Joël]

didier.gau...@gmail.com a écrit :
> Le mardi 19 mai 2020 08:30:03 UTC+2, BERTRAND Joël a écrit :
>> Bonjour à tous,
>>
>>  Vous le savez depuis le temps que je m'exprime sur le sujet, je hais la
>> bouse systemd pour tout un tas de raisons.
> [...]
>>  Je prends toute idée.
>>
>>  Merci,
>>
>>  JKB
> 
> https://distrowatch.com/search.php?ostype=All=All=All=All=None=All=All=All=All=All=All=All=Not+systemd=Active#simple
>  ?

Ce n'est _pas_ une solution. Il y a trop de dépendances cachées à
systemd dans les softs actuels et pas assez de visibilité (avenir) sur
les distributions non systemd. Il se passe aujourd'hui avec systemd très
exactement ce qu'il se passe avec les logiciels soit disant Unix. Ils
sont bourrés de linuxismes.

La seule dans le lot qui ait une audience plus que symbolique et qui
pourrait répondre à certains de mes critères, c'est gentoo (mais j'ai
déjà donné et pour un certain nombre de raisons dont emerge sur un poste
diskless, je préférerais éviter...).

Aujourd'hui, j'utilise systemd parce que je n'ai pas trouvé de solution
satisfaisante pour remplacer la chose correctement. J'ai maintenu init
SysV tant que j'ai pu. Et si je dois réinstaller ce poste, je ne
réinstallerai pas un Linux, ce système d'exploitation file de plus en
plus un mauvais coton. La gestion de la mémoire, en particulier, est
devenue totalement délirante. Je ne parle même pas du système d'amorçage.

Pour fixer les idées, j'ai deux machines comparables (hard et
utilisation) pour faire de la simulation électronique. La première
tourne sous Debian/testing, la seconde sous NetBSD 9.0. Logiciels
utilisés : kicad, ngpice, versions identiques (compilées depuis le git).

Linux : swappe à mort (malgré un swapiness à 1, d'ailleurs swapiness ne
sert plus à rien ou ne fait plus ce qu'il est censé faire)
NetBSD : je peux retirer le swap sans problème, il n'est pas utilisé
sauf par ngspice dans des simulations vraiment lourdes.

\begin{ma vie mon oeuvre}
En 1995, lorsque j'ai installé ma première debian, une 0.93, on avait un
système à peu près fiable, simple, robuste, qui faisait ce qu'on lui
demandait de faire.

Aujourd'hui, on est bien loin avec Linux en général et avec Debian en
particulier de la philosophie Unix KISS. Je rajouterai qu'on peut
reprocher aujourd'hui à Linux les mêmes travers qu'à Windows, à savoir
devenir une usine à gaz avec des fuites.
\end{ma vie mon oeuvre}

Ce qui serait vraiment intéressant, c'est que Debian propose avec ou
sans systemd (pour tous ses paquets d'ailleurs), parce que j'ai beau
chercher et trouver des excuses à systemd, je ne vois pas en quoi ce
truc est élégant, fiable et robuste. Sur des machines un peu courtes en
mémoire, le système swappe d'entrée de jeu en raison des lancements
concurrents (alors que si j'ai bonne mémoire, l'un des intérêts de la
chose, c'est justement de démarrer plus vite, ce dont on se contrefiche
sur un serveur qui est redémarré une fois par an). C'est en raison de
systemd que je vire à chaque remplacement Debian de mes serveurs pour
passer à du système beaucoup plus robuste, qu'on peut rebooter à
distance sans croiser les doigts, voire simplement mettre à jour sans se
poser la question de savoir si ça redémarrera correctement la prochaine
fois (ah, la dernière couillonnade sur le renommage des interfaces
réseau, elle était belle, celle-là ! systemd et udev qui se tiraient la
nouille sur qui arrivera à renommer les interfaces réseau et comme
personne ne voulait céder, eh bien mon eth0 qui heureusement était la
patte du LAN était renommée en eth3 !).

Je ne parle même pas des mises à jour de systemd qui mettent le daemon
à moitié en vrac et qui obligent à redémarrer un poste. Pas très sérieux.

Re: Un autre effet Kiskool de systemd !

[didier . gaumet]

Le mardi 19 mai 2020 08:30:03 UTC+2, BERTRAND Joël a écrit :
> Bonjour à tous,
> 
>   Vous le savez depuis le temps que je m'exprime sur le sujet, je hais la
> bouse systemd pour tout un tas de raisons.
[...]
>   Je prends toute idée.
> 
>   Merci,
> 
>   JKB

https://distrowatch.com/search.php?ostype=All=All=All=All=None=All=All=All=All=All=All=All=Not+systemd=Active#simple
 ?

Un autre effet Kiskool de systemd !

[BERTRAND Joël]

Bonjour à tous,

Vous le savez depuis le temps que je m'exprime sur le sujet, je hais la
bouse systemd pour tout un tas de raisons. Depuis quelques jours, je
peux en ajouter une de plus. Je m'explique :

J'utilise un poste de travail diskless (debian/testing à jour du 17 mai
dernier, i7, 32 Go de mémoire, swap en iSCSI, / et /home en nfs depuis
un serveur NetBSD, biécran, Windowmaker). Je précise que j'ai mis à jour
la distribution à la suite d'un premier problème de systemd qui, pour
une raison que j'ignore (et j'ai d'autres choses à faire que d'essayer
de comprendre les effets de bord de ce truc), avait décidé de ne plus
fonctionner normalement. J'avais encore accès à la vt1, mais les autres
ne lançaient plus getty... Là encore, strictement rien dans les logs.

Lorsqu'un programme quelconque met un peu de temps à répondre, il
m'arrive depuis quelque temps que ma session X soit autoritairement
close et que je me retrouve sous wdm. C'est assez énervant. Les logs ne
contiennent que ceci :

May 19 07:47:57 hilbert systemd[1]: Created slice User Slice of UID 0.
May 19 07:47:57 hilbert systemd[1]: Starting User Runtime Directory
/run/user/0...
May 19 07:47:57 hilbert systemd[1]: Finished User Runtime Directory
/run/user/0.
May 19 07:47:57 hilbert systemd[1]: Starting User Manager for UID 0...
May 19 07:47:57 hilbert systemd[573558]: gpgconf: erreur d'exécution de
« /usr/lib/gnupg/scdaemon » : il n'est sans doute pas installé
May 19 07:47:59 hilbert systemd[573552]: Reached target Paths.
May 19 07:47:59 hilbert systemd[573552]: Reached target Timers.
May 19 07:47:59 hilbert systemd[573552]: Starting D-Bus User Message Bus
Socket.
May 19 07:47:59 hilbert systemd[573552]: Listening on GnuPG network
certificate management daemon.
May 19 07:47:59 hilbert systemd[573552]: Listening on GnuPG
cryptographic agent and passphrase cache (access for web browsers).
May 19 07:47:59 hilbert systemd[573552]: Listening on GnuPG
cryptographic agent and passphrase cache (restricted).
May 19 07:47:59 hilbert systemd[573552]: Listening on GnuPG
cryptographic agent (ssh-agent emulation).
May 19 07:47:59 hilbert systemd[573552]: Listening on GnuPG
cryptographic agent and passphrase cache.
May 19 07:47:59 hilbert systemd[573552]: Listening on debconf
communication socket.
May 19 07:47:59 hilbert systemd[573552]: Condition check resulted in
Sound System being skipped.
May 19 07:47:59 hilbert systemd[573552]: Listening on D-Bus User Message
Bus Socket.
May 19 07:47:59 hilbert systemd[573552]: Reached target Sockets.
May 19 07:47:59 hilbert systemd[573552]: Reached target Basic System.
May 19 07:47:59 hilbert systemd[573552]: Condition check resulted in
Sound Service being skipped.
May 19 07:47:59 hilbert systemd[573552]: Reached target Main User Target.
May 19 07:47:59 hilbert systemd[573552]: Startup finished in 1.860s.

Je ne vois pas bien le rapport avec ce que j'observe. Je constate aussi
que toutes les instances de WM sont closes (même celles qui tournent
sous :1 et :2). De manière concomitante, certains processus se prennent
des SIGBUS.

Je n'ai strictement rien d'autre dans les logs, pas la plus petite
erreur mémoire, rien. Juste une déconnexion des sessions X pour une
raison indéterminée et, visiblement, à la demande de systemd.

Je prends toute idée.

Merci,

JKB

Re: Smokeping et ce de systemd

[Lucas Nussbaum]

On 25/03/19 at 07:24 +0100, BERTRAND Joël wrote:
> Lucas Nussbaum a écrit :
> > 
> > Et quand tu lances smokeping à la main avec /usr/sbin/smokeping
> > --pid-dir=/run/smokeping, où crée-t-il smokeping.pid ?
> > 
> > est-ce que tu peux faire 'systemctl cat smokeping.service' pour vérifier
> > que tu as bien le même contenu que ci-dessus (cad que tu n'as pas
> > d'overrides dans /etc) ?
> 
> Root rayleigh:[/lib/systemd/system] > systemctl cat smokeping.service
> # /lib/systemd/system/smokeping.service
> [Unit]
> Description=Latency Logging and Graphing System
> Documentation=man:smokeping(1)
> file:/usr/share/doc/smokeping/examples/systemd/slave_mode.conf
> After=network.target
> 
> [Service]
> # It would in theory be simpler to run smokeping with the --nodaemon
> option and
> # Type=simple, but smokeping does not work properly when in "slave" mode
> with
> # --nodaemon set.
> Type=forking
> RuntimeDirectory=smokeping
> PIDFile=/run/smokeping/smokeping.pid
> User=smokeping
> Group=smokeping
> StandardError=syslog
> 
> # If you need to run smokeping in slave/master mode, see the example unit
> # override in /usr/share/doc/smokeping/examples/systemd/slave_mode.conf
> ExecStart=/usr/sbin/smokeping --pid-dir=/run/smokeping
> 
> ExecReload=/bin/kill -HUP $MAINPID
> 
> [Install]
> WantedBy=multi-user.target
> Root rayleigh:[/lib/systemd/system] >
> 
>   Ça semble bien être la même chose (petite remarque en passant, le truc
> qui intercepte les scripts SysV me semble lui aussi être une connerie
> sans nom au fonctionnement aléatoire dans le machin systemd, on est bien
> loin du KISS du monde Unix...).
> 
>   Si je lance le daemon à la main :
> Root rayleigh:[/lib/systemd/system] > /usr/sbin/smokeping
> --pid-dir=/run/smokeping
> 
> je récupère un pid dans /run :
> Root rayleigh:[/lib/systemd/system] > ls /run/
> ...
> smokeping.pid
> ...
> 
>   Je pensais naïvement qu'il devait être dans 
> /run/smokeping/smokeping.pid...
> 
>   Même si je crée avant de lancer smokeping un répertoire /run/smokeping,
> je me retrouve avec le pid dans /run/smokeping.pid.

Voila, donc à la fin, c'est un probleme coté smokeping qui ne semble pas
respecter l'option --pid-dir. Rien à voir avec systemd. Je t'invite à
ouvrir un bug sur le paquet smokeping.

Lucas

Re: Smokeping et ce de systemd

[BERTRAND Joël]

Lucas Nussbaum a écrit :
> 
> Et quand tu lances smokeping à la main avec /usr/sbin/smokeping
> --pid-dir=/run/smokeping, où crée-t-il smokeping.pid ?
> 
> est-ce que tu peux faire 'systemctl cat smokeping.service' pour vérifier
> que tu as bien le même contenu que ci-dessus (cad que tu n'as pas
> d'overrides dans /etc) ?

Root rayleigh:[/lib/systemd/system] > systemctl cat smokeping.service
# /lib/systemd/system/smokeping.service
[Unit]
Description=Latency Logging and Graphing System
Documentation=man:smokeping(1)
file:/usr/share/doc/smokeping/examples/systemd/slave_mode.conf
After=network.target

[Service]
# It would in theory be simpler to run smokeping with the --nodaemon
option and
# Type=simple, but smokeping does not work properly when in "slave" mode
with
# --nodaemon set.
Type=forking
RuntimeDirectory=smokeping
PIDFile=/run/smokeping/smokeping.pid
User=smokeping
Group=smokeping
StandardError=syslog

# If you need to run smokeping in slave/master mode, see the example unit
# override in /usr/share/doc/smokeping/examples/systemd/slave_mode.conf
ExecStart=/usr/sbin/smokeping --pid-dir=/run/smokeping

ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target
Root rayleigh:[/lib/systemd/system] >

Ça semble bien être la même chose (petite remarque en passant, le truc
qui intercepte les scripts SysV me semble lui aussi être une connerie
sans nom au fonctionnement aléatoire dans le machin systemd, on est bien
loin du KISS du monde Unix...).

Si je lance le daemon à la main :
Root rayleigh:[/lib/systemd/system] > /usr/sbin/smokeping
--pid-dir=/run/smokeping

je récupère un pid dans /run :
Root rayleigh:[/lib/systemd/system] > ls /run/
...
smokeping.pid
...

Je pensais naïvement qu'il devait être dans 
/run/smokeping/smokeping.pid...

Même si je crée avant de lancer smokeping un répertoire /run/smokeping,
je me retrouve avec le pid dans /run/smokeping.pid.

Bien cordialement,

JB

Re: Smokeping et ce de systemd

[Lucas Nussbaum]

On 24/03/19 at 22:26 +0100, BERTRAND Joël wrote:
> Lucas Nussbaum a écrit :
> > Qu'as-tu juste après ? Dans le paquet, j'ai:
> > ExecStart=/usr/sbin/smokeping --pid-dir=/run/smokeping
> > 
> > qui demande donc à smokeping d'écrire son fichier .pid dans
> > /run/smokeping.
> > 
> > Donc, soit:
> > - cette ligne n'est pas présente
> > - cette ligne ne fonctionne pas
> 
> Voici le fichier complet (jamais touché) :
> 
> 
> Root rayleigh:[/lib/systemd/system] > cat smokeping.service
> [Unit]
> Description=Latency Logging and Graphing System
> Documentation=man:smokeping(1)
> file:/usr/share/doc/smokeping/examples/systemd/slave_mode.conf
> After=network.target
> 
> [Service]
> # It would in theory be simpler to run smokeping with the --nodaemon
> option and
> # Type=simple, but smokeping does not work properly when in "slave" mode
> with
> # --nodaemon set.
> Type=forking
> RuntimeDirectory=smokeping
> PIDFile=/run/smokeping/smokeping.pid
> User=smokeping
> Group=smokeping
> StandardError=syslog
> 
> # If you need to run smokeping in slave/master mode, see the example unit
> # override in /usr/share/doc/smokeping/examples/systemd/slave_mode.conf
> ExecStart=/usr/sbin/smokeping --pid-dir=/run/smokeping
> 
> ExecReload=/bin/kill -HUP $MAINPID
> 
> [Install]
> WantedBy=multi-user.target
> Root rayleigh:[/lib/systemd/system] >
> 
>   Naturellement, /run existe et un lien /var/run vers /run existe aussi.

Et quand tu lances smokeping à la main avec /usr/sbin/smokeping
--pid-dir=/run/smokeping, où crée-t-il smokeping.pid ?

est-ce que tu peux faire 'systemctl cat smokeping.service' pour vérifier
que tu as bien le même contenu que ci-dessus (cad que tu n'as pas
d'overrides dans /etc) ?

Lucas

Re: Smokeping et ce de systemd

[BERTRAND Joël]

Lucas Nussbaum a écrit :
> Qu'as-tu juste après ? Dans le paquet, j'ai:
> ExecStart=/usr/sbin/smokeping --pid-dir=/run/smokeping
> 
> qui demande donc à smokeping d'écrire son fichier .pid dans
> /run/smokeping.
> 
> Donc, soit:
> - cette ligne n'est pas présente
> - cette ligne ne fonctionne pas

Voici le fichier complet (jamais touché) :


Root rayleigh:[/lib/systemd/system] > cat smokeping.service
[Unit]
Description=Latency Logging and Graphing System
Documentation=man:smokeping(1)
file:/usr/share/doc/smokeping/examples/systemd/slave_mode.conf
After=network.target

[Service]
# It would in theory be simpler to run smokeping with the --nodaemon
option and
# Type=simple, but smokeping does not work properly when in "slave" mode
with
# --nodaemon set.
Type=forking
RuntimeDirectory=smokeping
PIDFile=/run/smokeping/smokeping.pid
User=smokeping
Group=smokeping
StandardError=syslog

# If you need to run smokeping in slave/master mode, see the example unit
# override in /usr/share/doc/smokeping/examples/systemd/slave_mode.conf
ExecStart=/usr/sbin/smokeping --pid-dir=/run/smokeping

ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target
Root rayleigh:[/lib/systemd/system] >

Naturellement, /run existe et un lien /var/run vers /run existe aussi.

Bien cordialement,

JKB

Re: Smokeping et ce de systemd

[Lucas Nussbaum]

(Merci de me Cc les réponses éventuelles, je ne suis pas la liste de
près)

Bonsoir,

On 24/03/19 at 19:46 +0100, BERTRAND Joël wrote:
>   Bonsoir à tous,
> 
>   Je viens d'avoir un plantage sévère sur un serveur (kernel panic avec
> le dernier noyau de testing). Au redémarrage, je m'aperçois que
> smokeping ne se lance pas :
> 
> Root rayleigh:[/run] > systemctl status smokeping.service
> ● smokeping.service - Latency Logging and Graphing System
>Loaded: loaded (/lib/systemd/system/smokeping.service; enabled;
> vendor preset: enabled)
>Active: failed (Result: timeout) since Sun 2019-03-24 18:06:51 CET;
> 1h 32min ago
>  Docs: man:smokeping(1)
>file:/usr/share/doc/smokeping/examples/systemd/slave_mode.conf
> 
> mars 24 18:05:21 rayleigh smokeping[11095]: All probe processes started
> successfully.
> mars 24 18:05:21 rayleigh smokeping[11097]: FPing: probing 7 targets
> with step 300 s and offset 279 s.
> mars 24 18:05:21 rayleigh systemd[1]: smokeping.service: Can't open PID
> file /run/smokeping/smokeping.pid (yet
> mars 24 18:06:51 rayleigh systemd[1]: smokeping.service: Start operation
> timed out. Terminating.
> mars 24 18:06:51 rayleigh smokeping[11095]: Got TERM signal, terminating
> child processes.
> mars 24 18:06:51 rayleigh smokeping[11096]: got TERM signal, terminating.
> mars 24 18:06:51 rayleigh smokeping[11097]: got TERM signal, terminating.
> mars 24 18:06:51 rayleigh smokeping[11095]: All child processes
> successfully terminated, exiting.
> mars 24 18:06:51 rayleigh systemd[1]: smokeping.service: Failed with
> result 'timeout'.
> mars 24 18:06:51 rayleigh systemd[1]: Failed to start Latency Logging
> and Graphing System.
> 
>   Très bien.

Donc, systemd démarre smokeping, s'attend à ce qu'il crée un fichier
avec son PID (/run/smokeping/smokeping.pid), mais il ne le fait pas,
donc systemd décide qu'il n'a pas démarré correctement, et l'arrête.

>   Un tour dans les logs (les vrais) donne :
> 
> Mar 24 18:05:21 rayleigh smokeping[11086]: Starting syslog logging
> Mar 24 18:05:21 rayleigh smokeping[11086]: Note: logging to syslog as
> local0/info.
> Mar 24 18:05:21 rayleigh smokeping[11086]: Daemonizing
> /usr/sbin/smokeping ...
> Mar 24 18:05:21 rayleigh smokeping[11086]: creating
> /var/run/smokeping.pid: Permission denied
> Mar 24 18:05:21 rayleigh smokeping[11095]: Smokeping version 2.007003
> successfully launched.
> Mar 24 18:05:21 rayleigh smokeping[11095]: Entering multiprocess mode.
> Mar 24 18:05:21 rayleigh smokeping[11095]: Child process 11096 started
> for probe FPing6.
> Mar 24 18:05:21 rayleigh smokeping[11096]: FPing6: probing 2 targets
> with step 300 s and offset 201 s.
> Mar 24 18:05:21 rayleigh smokeping[11095]: Child process 11097 started
> for probe FPing.
> Mar 24 18:05:21 rayleigh smokeping[11095]: All probe processes started
> successfully.
> Mar 24 18:05:21 rayleigh smokeping[11097]: FPing: probing 7 targets with
> step 300 s and offset 279 s.
> Mar 24 18:05:21 rayleigh systemd[1]: smokeping.service: Can't open PID
> file /run/smokeping/smokeping.pid (yet?) after start: No such file or
> directory
> Mar 24 18:06:51 rayleigh systemd[1]: smokeping.service: Start operation
> timed out. Terminating.
> Mar 24 18:06:51 rayleigh smokeping[11095]: Got TERM signal, terminating
> child processes.
> Mar 24 18:06:51 rayleigh smokeping[11096]: got TERM signal, terminating.
> Mar 24 18:06:51 rayleigh smokeping[11097]: got TERM signal, terminating.
> Mar 24 18:06:51 rayleigh smokeping[11095]: All child processes
> successfully terminated, exiting.
> Mar 24 18:06:51 rayleigh systemd[1]: smokeping.service: Failed with
> result 'timeout'.
> 
>   Ce qui est intéressant, c'est le  "creating /var/run/smokeping.pid:
> Permission denied".

oui. Car du coup, ça veut dire que smokeping essaie de créer un fichier
.pid, mais pas à l'endroit attendu dans le fichier .service. Même s'il
avait réussi, systemd ne l'aurait pas trouvé et l'aurait tué.

>   Et là, je ne comprends pas. smokeping se lance en tant que smokeping.
> Mais systemd le sait, c'est sans son fichier de configuration :
> 
> [Service]
> # It would in theory be simpler to run smokeping with the --nodaemon
> option and
> # Type=simple, but smokeping does not work properly when in "slave" mode
> with
> # --nodaemon set.
> Type=forking
> RuntimeDirectory=smokeping
> PIDFile=/run/smokeping/smokeping.pid
> User=smokeping
> Group=smokeping
> StandardError=syslog

Qu'as-tu juste après ? Dans le paquet, j'ai:
ExecStart=/usr/sbin/smokeping --pid-dir=/run/smokeping

qui demande donc à smokeping d'écrire son fichier .pid dans
/run/smokeping.

Donc, soit:
- cette ligne n'est pas présente
- cette ligne ne fonctionne pas

Lucas

Smokeping et ce de systemd

[BERTRAND Joël]

Bonsoir à tous,

Je viens d'avoir un plantage sévère sur un serveur (kernel panic avec
le dernier noyau de testing). Au redémarrage, je m'aperçois que
smokeping ne se lance pas :

Root rayleigh:[/run] > systemctl status smokeping.service
● smokeping.service - Latency Logging and Graphing System
   Loaded: loaded (/lib/systemd/system/smokeping.service; enabled;
vendor preset: enabled)
   Active: failed (Result: timeout) since Sun 2019-03-24 18:06:51 CET;
1h 32min ago
 Docs: man:smokeping(1)
   file:/usr/share/doc/smokeping/examples/systemd/slave_mode.conf

mars 24 18:05:21 rayleigh smokeping[11095]: All probe processes started
successfully.
mars 24 18:05:21 rayleigh smokeping[11097]: FPing: probing 7 targets
with step 300 s and offset 279 s.
mars 24 18:05:21 rayleigh systemd[1]: smokeping.service: Can't open PID
file /run/smokeping/smokeping.pid (yet
mars 24 18:06:51 rayleigh systemd[1]: smokeping.service: Start operation
timed out. Terminating.
mars 24 18:06:51 rayleigh smokeping[11095]: Got TERM signal, terminating
child processes.
mars 24 18:06:51 rayleigh smokeping[11096]: got TERM signal, terminating.
mars 24 18:06:51 rayleigh smokeping[11097]: got TERM signal, terminating.
mars 24 18:06:51 rayleigh smokeping[11095]: All child processes
successfully terminated, exiting.
mars 24 18:06:51 rayleigh systemd[1]: smokeping.service: Failed with
result 'timeout'.
mars 24 18:06:51 rayleigh systemd[1]: Failed to start Latency Logging
and Graphing System.

Très bien. Un tour dans les logs (les vrais) donne :

Mar 24 18:05:21 rayleigh smokeping[11086]: Starting syslog logging
Mar 24 18:05:21 rayleigh smokeping[11086]: Note: logging to syslog as
local0/info.
Mar 24 18:05:21 rayleigh smokeping[11086]: Daemonizing
/usr/sbin/smokeping ...
Mar 24 18:05:21 rayleigh smokeping[11086]: creating
/var/run/smokeping.pid: Permission denied
Mar 24 18:05:21 rayleigh smokeping[11095]: Smokeping version 2.007003
successfully launched.
Mar 24 18:05:21 rayleigh smokeping[11095]: Entering multiprocess mode.
Mar 24 18:05:21 rayleigh smokeping[11095]: Child process 11096 started
for probe FPing6.
Mar 24 18:05:21 rayleigh smokeping[11096]: FPing6: probing 2 targets
with step 300 s and offset 201 s.
Mar 24 18:05:21 rayleigh smokeping[11095]: Child process 11097 started
for probe FPing.
Mar 24 18:05:21 rayleigh smokeping[11095]: All probe processes started
successfully.
Mar 24 18:05:21 rayleigh smokeping[11097]: FPing: probing 7 targets with
step 300 s and offset 279 s.
Mar 24 18:05:21 rayleigh systemd[1]: smokeping.service: Can't open PID
file /run/smokeping/smokeping.pid (yet?) after start: No such file or
directory
Mar 24 18:06:51 rayleigh systemd[1]: smokeping.service: Start operation
timed out. Terminating.
Mar 24 18:06:51 rayleigh smokeping[11095]: Got TERM signal, terminating
child processes.
Mar 24 18:06:51 rayleigh smokeping[11096]: got TERM signal, terminating.
Mar 24 18:06:51 rayleigh smokeping[11097]: got TERM signal, terminating.
Mar 24 18:06:51 rayleigh smokeping[11095]: All child processes
successfully terminated, exiting.
Mar 24 18:06:51 rayleigh systemd[1]: smokeping.service: Failed with
result 'timeout'.

Ce qui est intéressant, c'est le  "creating /var/run/smokeping.pid:
Permission denied".

Et là, je ne comprends pas. smokeping se lance en tant que smokeping.
Mais systemd le sait, c'est sans son fichier de configuration :

[Service]
# It would in theory be simpler to run smokeping with the --nodaemon
option and
# Type=simple, but smokeping does not work properly when in "slave" mode
with
# --nodaemon set.
Type=forking
RuntimeDirectory=smokeping
PIDFile=/run/smokeping/smokeping.pid
User=smokeping
Group=smokeping
StandardError=syslog

Je n'ai pas touché à ce fichier, il y assez de choses pas maîtrisées
dans systemd (par les concepteurs, il suffit de regarder la non
répétabilité des séquences de démarrage sur des serveurs chargés en
daemons de tous genres) pour que je n'y mette pas les mains.

D'autres daemons ont exactement la même configuration (à savoir User et
Group) et ne posent pas de problème particulier.

D'où ma question : où est le problème et comment le corriger ? Je
précise à toutes fins utiles qu'avant ce kernel panic, smokeping se
lançait parfaitement bien (noyau 4.19.0-1, panic avec le 4.19.0-2 - je
ne sais pas si smokeping tournait -, lancement impossible avec le 4.19.0-4).

Bien cordialement,

JKB

Re: de systemd !...

[BERTRAND Joël]

daniel huhardeaux a écrit :
> Le 25/07/2018 à 18:34, BERTRAND Joël a écrit :
>> [...]
>>> auto eth1
>>> iface eth1 inet static
>>>  address 192.168.254.1
>>>  netmask 255.255.255.0
>>>  network 192.168.254.0
>>>  broadcast 192.168.254.255
>>>  gateway 192.168.254.254
>>>  mtu 1492
>>>  post-up ifup eth1:1 || true
>> Juste une question... À quoi sert le || true ?
> 
> Ca retourne vrai en cas d'erreur ce qui ne bloquera pas la suite de
> l'exécution des commandes
> 

Merci.

Re: de systemd !...

[daniel huhardeaux]

Le 25/07/2018 à 18:34, BERTRAND Joël a écrit :

[...]

auto eth1
iface eth1 inet static
 address 192.168.254.1
 netmask 255.255.255.0
 network 192.168.254.0
 broadcast 192.168.254.255
 gateway 192.168.254.254
 mtu 1492
 post-up ifup eth1:1 || true

Juste une question... À quoi sert le || true ?


Ca retourne vrai en cas d'erreur ce qui ne bloquera pas la suite de 
l'exécution des commandes


--
Daniel

Re: de systemd !...

[BERTRAND Joël]

didier gaumet a écrit :
> Remarques préliminaires: je suis plutôt nul en réseau, je n'ai jamais
> paramétré de serveur et je me cantonne basiquement à NetworkManager sur
> mon laptop
> 
>  Mais j'ai cru comprendre que Systemd se basait en interne sur les
> nouveaux noms barbares d'interfaces réseau ("predictable device names")
> même si la configuration réseau héritée d'une précédente version de
> Debian utilise encore les anciens noms (genre eth0)?
>  Et que la nouvelle manière de configurer le réseau privilégiée par
> Systemd c'était dans la sphère Systemd plutôt que dans le fichier
> /etc/network/interfaces?
> (cf https://www.freedesktop.org/software/systemd/man/systemd.network.html)
> 
>  Pas taper si ce n'est pas pertinent: je ne suis pas du tout compétent
> dans le domaine...
> 

Les noms d'interface sont figés. J'en ai eu assez rapidement marre des
noyaux qui énuméraient les interfaces dans des sens différents...

Cordialement,

JKB

Re: de systemd !...

[BERTRAND Joël]

daniel huhardeaux a écrit :
> Le 25/07/2018 à 13:40, BERTRAND Joël a écrit :
>> daniel huhardeaux a écrit :
>>> Si tu fais un /sbin/ifdown -a --read-environment --exclude=lo suivi d'un
>>> ip addr show, il ne devrait rester que lo. Si j'ai compris, en fait
>>> systemctl start network plante mais un /sbin/ifup -a --read-environment
>>> --exclude=lo manuel fonctionne ?
>> C'est tout à fait cela.
>>
>>> Si tu fais systemctl stop openvpn@[vpn1|vpn2] suivi de systemctl stop
>>> network puis tu remontes le réseau (VPN coupé donc) as tu également
>>> l'erreur?
>> Je ne peux pas couper le VPN, c'est un serveur de prod. J'ai
>> l'impression que la commande n'échoue que lors du boot où elle est
>> lancée par systemd. Au début, je pensais que systemd cherchait à
>> utiliser tap0/tap1 avant qu'openvpn ne les ait montées, mais ce n'est
>> visiblement pas le cas. Je ne peux pas non plus virer les interfaces
>> virtuelles pour tester.
> Je ne sais pas quelle version Debian tu as mais j'avais rencontré des
> problèmes de ce type avec Jessie. J'avais modifié mon fichier interfaces
> du style (je sais, ça marchait avant, mais bon ;)):
> 
> auto eth1
> iface eth1 inet static
> address 192.168.254.1
> netmask 255.255.255.0
> network 192.168.254.0
> broadcast 192.168.254.255
> gateway 192.168.254.254
> mtu 1492
> post-up ifup eth1:1 || true

Juste une question... À quoi sert le || true ?

> post-up ifup eth1:2 || true
> post-up ifup eth1:3 || true
> post-up ifup eth1:4 || true
> post-up ifup eth1:5 || true
> pre-down ifdown eth1:1
> pre-down ifdown eth1:2
> pre-down ifdown eth1:3
> pre-down ifdown eth1:4
> pre-down ifdown eth1:5
> 
> 
> iface eth1:1 inet static
> address 192.168.254.81
> netmask 255.255.255.0
> 
> iface eth1:2 inet static
> address 192.168.254.82
> netmask 255.255.255.0
> 
> iface eth1:3 inet static
> address 192.168.254.83
> netmask 255.255.255.0
> 
> iface eth1:4 inet static
> address 192.168.254.84
> netmask 255.255.255.0
> 
> iface eth1:5 inet static
> address 192.168.254.85
> netmask 255.255.255.0

Cordialement,

JKB

Re: de systemd !...

[Frédéric MASSOT]

Le 25/07/2018 à 14:27, daniel huhardeaux a écrit :
> Le 25/07/2018 à 13:40, BERTRAND Joël a écrit :
>> daniel huhardeaux a écrit :
>>> Si tu fais un /sbin/ifdown -a --read-environment --exclude=lo suivi d'un
>>> ip addr show, il ne devrait rester que lo. Si j'ai compris, en fait
>>> systemctl start network plante mais un /sbin/ifup -a --read-environment
>>> --exclude=lo manuel fonctionne ?
>> C'est tout à fait cela.
>>
>>> Si tu fais systemctl stop openvpn@[vpn1|vpn2] suivi de systemctl stop
>>> network puis tu remontes le réseau (VPN coupé donc) as tu également
>>> l'erreur?
>> Je ne peux pas couper le VPN, c'est un serveur de prod. J'ai
>> l'impression que la commande n'échoue que lors du boot où elle est
>> lancée par systemd. Au début, je pensais que systemd cherchait à
>> utiliser tap0/tap1 avant qu'openvpn ne les ait montées, mais ce n'est
>> visiblement pas le cas. Je ne peux pas non plus virer les interfaces
>> virtuelles pour tester.
> Je ne sais pas quelle version Debian tu as mais j'avais rencontré des
> problèmes de ce type avec Jessie. J'avais modifié mon fichier interfaces
> du style (je sais, ça marchait avant, mais bon ;)):


Une doc sur le wiki de Debian, il semble que la config soit un peu
différente selon que ifupdown se sert de ifconfig ou de ip :

https://wiki.debian.org/fr/NetworkConfiguration#Adresses_IP_multiples_pour_une_interface




-- 
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===

Re: de systemd !...

[daniel huhardeaux]

Le 25/07/2018 à 13:40, BERTRAND Joël a écrit :

daniel huhardeaux a écrit :

Si tu fais un /sbin/ifdown -a --read-environment --exclude=lo suivi d'un
ip addr show, il ne devrait rester que lo. Si j'ai compris, en fait
systemctl start network plante mais un /sbin/ifup -a --read-environment
--exclude=lo manuel fonctionne ?

C'est tout à fait cela.


Si tu fais systemctl stop openvpn@[vpn1|vpn2] suivi de systemctl stop
network puis tu remontes le réseau (VPN coupé donc) as tu également
l'erreur?

Je ne peux pas couper le VPN, c'est un serveur de prod. J'ai
l'impression que la commande n'échoue que lors du boot où elle est
lancée par systemd. Au début, je pensais que systemd cherchait à
utiliser tap0/tap1 avant qu'openvpn ne les ait montées, mais ce n'est
visiblement pas le cas. Je ne peux pas non plus virer les interfaces
virtuelles pour tester.
Je ne sais pas quelle version Debian tu as mais j'avais rencontré des 
problèmes de ce type avec Jessie. J'avais modifié mon fichier interfaces 
du style (je sais, ça marchait avant, mais bon ;)):


auto eth1
iface eth1 inet static
address 192.168.254.1
netmask 255.255.255.0
network 192.168.254.0
broadcast 192.168.254.255
gateway 192.168.254.254
mtu 1492
post-up ifup eth1:1 || true
post-up ifup eth1:2 || true
post-up ifup eth1:3 || true
post-up ifup eth1:4 || true
post-up ifup eth1:5 || true
pre-down ifdown eth1:1
pre-down ifdown eth1:2
pre-down ifdown eth1:3
pre-down ifdown eth1:4
pre-down ifdown eth1:5


iface eth1:1 inet static
address 192.168.254.81
netmask 255.255.255.0

iface eth1:2 inet static
address 192.168.254.82
netmask 255.255.255.0

iface eth1:3 inet static
address 192.168.254.83
netmask 255.255.255.0

iface eth1:4 inet static
address 192.168.254.84
netmask 255.255.255.0

iface eth1:5 inet static
address 192.168.254.85
netmask 255.255.255.0


--
Daniel

Re: de systemd !...

[didier gaumet]

Remarques préliminaires: je suis plutôt nul en réseau, je n'ai jamais
paramétré de serveur et je me cantonne basiquement à NetworkManager sur
mon laptop

 Mais j'ai cru comprendre que Systemd se basait en interne sur les
nouveaux noms barbares d'interfaces réseau ("predictable device names")
même si la configuration réseau héritée d'une précédente version de
Debian utilise encore les anciens noms (genre eth0)?
 Et que la nouvelle manière de configurer le réseau privilégiée par
Systemd c'était dans la sphère Systemd plutôt que dans le fichier
/etc/network/interfaces?
(cf https://www.freedesktop.org/software/systemd/man/systemd.network.html)

 Pas taper si ce n'est pas pertinent: je ne suis pas du tout compétent
dans le domaine...

Re: de systemd !...

[BERTRAND Joël]

daniel huhardeaux a écrit :
> Si tu fais un /sbin/ifdown -a --read-environment --exclude=lo suivi d'un
> ip addr show, il ne devrait rester que lo. Si j'ai compris, en fait
> systemctl start network plante mais un /sbin/ifup -a --read-environment
> --exclude=lo manuel fonctionne ?

C'est tout à fait cela.

> Si tu fais systemctl stop openvpn@[vpn1|vpn2] suivi de systemctl stop
> network puis tu remontes le réseau (VPN coupé donc) as tu également
> l'erreur?

Je ne peux pas couper le VPN, c'est un serveur de prod. J'ai
l'impression que la commande n'échoue que lors du boot où elle est
lancée par systemd. Au début, je pensais que systemd cherchait à
utiliser tap0/tap1 avant qu'openvpn ne les ait montées, mais ce n'est
visiblement pas le cas. Je ne peux pas non plus virer les interfaces
virtuelles pour tester.

JKB

Re: de systemd !...

[daniel huhardeaux]

Le 25/07/2018 à 09:38, BERTRAND Joël a écrit :

daniel huhardeaux a écrit :

Salut. Perso je commencerai par retirer gateway, broadcast et network
sur les interfaces eth1:1 à eth1:6. Si tu fais un ifconfig -a ou ip addr
show après avoir lancé le réseau, qu'indique t'il ?


Bonjour,

rayleigh:[~] > ip addr show
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1000
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
 inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth1:  mtu 1492 qdisc htb state UP
group default qlen 1000
 link/ether 00:08:02:af:da:70 brd ff:ff:ff:ff:ff:ff
 inet 192.168.254.1/24 brd 192.168.254.255 scope global eth1
valid_lft forever preferred_lft forever
 inet 192.168.254.81/24 brd 192.168.254.255 scope global secondary eth1:1
valid_lft forever preferred_lft forever
 inet 192.168.254.82/24 brd 192.168.254.255 scope global secondary eth1:2
valid_lft forever preferred_lft forever
 inet 192.168.254.83/24 brd 192.168.254.255 scope global secondary eth1:3
valid_lft forever preferred_lft forever
 inet 192.168.254.84/24 brd 192.168.254.255 scope global secondary eth1:4
valid_lft forever preferred_lft forever
 inet 192.168.254.85/24 brd 192.168.254.255 scope global secondary eth1:5
valid_lft forever preferred_lft forever
 inet 192.168.254.86/24 brd 192.168.254.255 scope global secondary eth1:6
valid_lft forever preferred_lft forever
 inet6 fe80::208:2ff:feaf:da70/64 scope link
valid_lft forever preferred_lft forever
3: eth2:  mtu 1500 qdisc htb state UP
group default qlen 1000
 link/ether 00:08:02:af:da:71 brd ff:ff:ff:ff:ff:ff
 inet 192.168.253.1/24 brd 192.168.253.255 scope global eth2
valid_lft forever preferred_lft forever
 inet6 2001:7a8:a8ed:253::1/64 scope global
valid_lft forever preferred_lft forever
 inet6 fe80::208:2ff:feaf:da71/64 scope link
valid_lft forever preferred_lft forever
4: eth0:  mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
 link/ether 50:46:5d:72:ef:a2 brd ff:ff:ff:ff:ff:ff
 inet 192.168.0.128/24 brd 192.168.0.255 scope global eth0
valid_lft forever preferred_lft forever
 inet6 2001:7a8:a8ed::128/64 scope global
valid_lft forever preferred_lft forever
 inet6 fe80::5246:5dff:fe72:efa2/64 scope link
valid_lft forever preferred_lft forever
5: tap0:  mtu 1336 qdisc pfifo_fast
state UNKNOWN group default qlen 100
 link/ether 46:96:a3:00:cb:02 brd ff:ff:ff:ff:ff:ff
 inet 192.168.2.1/24 brd 192.168.2.255 scope global tap0
valid_lft forever preferred_lft forever
 inet6 fe80::4496:a3ff:fe00:cb02/64 scope link
valid_lft forever preferred_lft forever
6: tap1:  mtu 1338 qdisc htb state
UNKNOWN group default qlen 100
 link/ether 16:bb:0c:7a:92:46 brd ff:ff:ff:ff:ff:ff
 inet 192.168.1.1/24 brd 192.168.1.255 scope global tap1
valid_lft forever preferred_lft forever
 inet6 2001:7a8:a8ed:1::1/64 scope global
valid_lft forever preferred_lft forever
 inet6 fe80::14bb:cff:fe7a:9246/64 scope link
valid_lft forever preferred_lft forever

Je veux bien enlever network et gateway, mais cela a très bien
fonctionné par le passé (même avec systemd). C'est une mise à jour du
bousin qui a causé problème.



Si tu fais un /sbin/ifdown -a --read-environment --exclude=lo suivi d'un 
ip addr show, il ne devrait rester que lo. Si j'ai compris, en fait 
systemctl start network plante mais un /sbin/ifup -a --read-environment 
--exclude=lo manuel fonctionne ?


Si tu fais systemctl stop openvpn@[vpn1|vpn2] suivi de systemctl stop 
network puis tu remontes le réseau (VPN coupé donc) as tu également 
l'erreur?


--
Danie;

Re: de systemd !...

[BERTRAND Joël]

daniel huhardeaux a écrit :
> Salut. Perso je commencerai par retirer gateway, broadcast et network
> sur les interfaces eth1:1 à eth1:6. Si tu fais un ifconfig -a ou ip addr
> show après avoir lancé le réseau, qu'indique t'il ?
> 

Bonjour,

rayleigh:[~] > ip addr show
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: eth1:  mtu 1492 qdisc htb state UP
group default qlen 1000
link/ether 00:08:02:af:da:70 brd ff:ff:ff:ff:ff:ff
inet 192.168.254.1/24 brd 192.168.254.255 scope global eth1
   valid_lft forever preferred_lft forever
inet 192.168.254.81/24 brd 192.168.254.255 scope global secondary eth1:1
   valid_lft forever preferred_lft forever
inet 192.168.254.82/24 brd 192.168.254.255 scope global secondary eth1:2
   valid_lft forever preferred_lft forever
inet 192.168.254.83/24 brd 192.168.254.255 scope global secondary eth1:3
   valid_lft forever preferred_lft forever
inet 192.168.254.84/24 brd 192.168.254.255 scope global secondary eth1:4
   valid_lft forever preferred_lft forever
inet 192.168.254.85/24 brd 192.168.254.255 scope global secondary eth1:5
   valid_lft forever preferred_lft forever
inet 192.168.254.86/24 brd 192.168.254.255 scope global secondary eth1:6
   valid_lft forever preferred_lft forever
inet6 fe80::208:2ff:feaf:da70/64 scope link
   valid_lft forever preferred_lft forever
3: eth2:  mtu 1500 qdisc htb state UP
group default qlen 1000
link/ether 00:08:02:af:da:71 brd ff:ff:ff:ff:ff:ff
inet 192.168.253.1/24 brd 192.168.253.255 scope global eth2
   valid_lft forever preferred_lft forever
inet6 2001:7a8:a8ed:253::1/64 scope global
   valid_lft forever preferred_lft forever
inet6 fe80::208:2ff:feaf:da71/64 scope link
   valid_lft forever preferred_lft forever
4: eth0:  mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
link/ether 50:46:5d:72:ef:a2 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.128/24 brd 192.168.0.255 scope global eth0
   valid_lft forever preferred_lft forever
inet6 2001:7a8:a8ed::128/64 scope global
   valid_lft forever preferred_lft forever
inet6 fe80::5246:5dff:fe72:efa2/64 scope link
   valid_lft forever preferred_lft forever
5: tap0:  mtu 1336 qdisc pfifo_fast
state UNKNOWN group default qlen 100
link/ether 46:96:a3:00:cb:02 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.1/24 brd 192.168.2.255 scope global tap0
   valid_lft forever preferred_lft forever
inet6 fe80::4496:a3ff:fe00:cb02/64 scope link
   valid_lft forever preferred_lft forever
6: tap1:  mtu 1338 qdisc htb state
UNKNOWN group default qlen 100
link/ether 16:bb:0c:7a:92:46 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.1/24 brd 192.168.1.255 scope global tap1
   valid_lft forever preferred_lft forever
inet6 2001:7a8:a8ed:1::1/64 scope global
   valid_lft forever preferred_lft forever
inet6 fe80::14bb:cff:fe7a:9246/64 scope link
   valid_lft forever preferred_lft forever

Je veux bien enlever network et gateway, mais cela a très bien
fonctionné par le passé (même avec systemd). C'est une mise à jour du
bousin qui a causé problème.

Bien cordialement,

JKB

Re: de systemd !...

[daniel huhardeaux]

Le 24/07/2018 à 13:07, BERTRAND Joël a écrit :

Bonjour à tous,

Considérons la partie réseau d'un serveur.

eth0 = LAN
eth1 = WAN1 (avec eth1:1->eth1:6) avec sept adresses IPv4 différentes
eth2 = WAN2 (avec une adresse IPv4 et un /64 Ipv6)
tap0 = openvpn TCP
tap1 = openvpn UDP

Cette configuration fonctionnait parfaitement avec init. Avec 
systemd, ça merdoie (mais qui s'en étonnerait encore). Je subodore un 
problème de dépendance entre les tap0/1 et le reste du réseau.


Les erreurs sont sur les modules :
- networking.service
- ifupdown-wait-online.service

Il n'y a pas de networkmanager, tout est fait à l'ancienne avec un 
fichier interfaces en pièce jointe.

[...]


Salut. Perso je commencerai par retirer gateway, broadcast et network 
sur les interfaces eth1:1 à eth1:6. Si tu fais un ifconfig -a ou ip addr 
show après avoir lancé le réseau, qu'indique t'il ?


--
Daniel

de systemd !...

[BERTRAND Joël]

Bonjour à tous,

Considérons la partie réseau d'un serveur.

eth0 = LAN
eth1 = WAN1 (avec eth1:1->eth1:6) avec sept adresses IPv4 différentes
eth2 = WAN2 (avec une adresse IPv4 et un /64 Ipv6)
tap0 = openvpn TCP
tap1 = openvpn UDP

	Cette configuration fonctionnait parfaitement avec init. Avec systemd, 
ça merdoie (mais qui s'en étonnerait encore). Je subodore un problème de 
dépendance entre les tap0/1 et le reste du réseau.


Les erreurs sont sur les modules :
- networking.service
- ifupdown-wait-online.service

	Il n'y a pas de networkmanager, tout est fait à l'ancienne avec un 
fichier interfaces en pièce jointe.


Root rayleigh:[~] > systemctl statuts networking.service
Unknown operation statuts.
Root rayleigh:[~] > systemctl status networking.service
● networking.service - Raise network interfaces
   Loaded: loaded (/lib/systemd/system/networking.service; enabled; 
vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2018-07-24 12:43:44 
CEST; 5min ago

 Docs: man:interfaces(5)
  Process: 1339 ExecStart=/sbin/ifup -a --read-environment 
(code=exited, status=1/FAILURE)
  Process: 1334 ExecStartPre=/bin/sh -c if [ "$CONFIGURE_INTERFACES" != 
"no" ] && [ -n "$(ifquery --read-environment --list --exclude=lo)" ]; 
then udevadm settle; fi (code=exited, s

 Main PID: 1339 (code=exited, status=1/FAILURE)

juil. 24 12:43:23 rayleigh ifup[1339]: RTNETLINK answers: File exists
juil. 24 12:43:23 rayleigh ifup[1339]: ifup: failed to bring up eth1:4
juil. 24 12:43:23 rayleigh ifup[1339]: RTNETLINK answers: File exists
juil. 24 12:43:23 rayleigh ifup[1339]: ifup: failed to bring up eth1:5
juil. 24 12:43:23 rayleigh ifup[1339]: RTNETLINK answers: File exists
juil. 24 12:43:23 rayleigh ifup[1339]: ifup: failed to bring up eth1:6
juil. 24 12:43:34 rayleigh ifup[1339]: Waiting for DAD... Done
juil. 24 12:43:44 rayleigh systemd[1]: networking.service: Main process 
exited, code=exited, status=1/FAILURE
juil. 24 12:43:44 rayleigh systemd[1]: networking.service: Failed with 
result 'exit-code'.
juil. 24 12:43:44 rayleigh systemd[1]: Failed to start Raise network 
interfaces.

Root rayleigh:[~] > systemctl status ifupdown-wait-online.service
● ifupdown-wait-online.service - Wait for network to be configured by 
ifupdown
   Loaded: loaded (/lib/systemd/system/ifupdown-wait-online.service; 
enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2018-07-24 12:47:30 
CEST; 4min 26s ago
  Process: 430 ExecStart=/lib/ifupdown/wait-online.sh (code=exited, 
status=1/FAILURE)

 Main PID: 430 (code=exited, status=1/FAILURE)

juil. 24 12:47:30 rayleigh systemd[1]: ifupdown-wait-online.service: 
Main process exited, code=exited, status=1/FAILURE
juil. 24 12:47:30 rayleigh systemd[1]: ifupdown-wait-online.service: 
Failed with result 'exit-code'.
juil. 24 12:47:30 rayleigh systemd[1]: Failed to start Wait for network 
to be configured by ifupdown.
Warning: Journal has been rotated since unit was started. Log output is 
incomplete or unavailable.

Root rayleigh:[~] >

	Je suppose que la seconde erreur est une conséquence de la première. 
Donc je teste /sbin/ifup -a -n --read-environment... qui ne renvoie 
aucune erreur ! De toute façon, ce fichier ne prend ni en compte tap0 ni 
tap1.


La question est donc de savoir comment corriger la chose.

Bien cordialement,

JKB
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.0.128
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255

iface eth0 inet6 static
address 2001:7a8:a8ed:0::128
netmask 64

auto eth1
iface eth1 inet static
address 192.168.254.1
netmask 255.255.255.0
network 192.168.254.0
broadcast 192.168.254.255
gateway 192.168.254.254
mtu 1492

auto eth1:1
iface eth1:1 inet static
address 192.168.254.81
netmask 255.255.255.0
network 192.168.254.0
broadcast 192.168.254.255
gateway 192.168.254.254

auto eth1:2
iface eth1:2 inet static
address 192.168.254.82
netmask 255.255.255.0
network 192.168.254.0
broadcast 192.168.254.255
gateway 192.168.254.254

auto eth1:3
iface eth1:3 inet static
address 192.168.254.83
netmask 255.255.255.0
network 192.168.254.0
broadcast 192.168.254.255
gateway 192.168.254.254

auto eth1:4
iface eth1:4 inet static
address 192.168.254.84
netmask 255.255.255.0
network 192.168.254.0
broadcast 192.168.254.255
gateway 192.168.254.254

auto eth1:5
iface eth1:5 inet static
address 192.168.254.85
netmask 255.255.255.0
network 192.168.254.0

org.freedesktop.login1.policy écrasé à chaque update de systemd

[Fabrice Regnier]

'lut la liste,

Par ce que je suis un poil fainéant, j'ai modifié 
org.freedesktop.login1.policy afin d'autoriser n'importe quel 
utilisateur à mettre le poste en veille ou à l'éteindre, cela m'évite de 
taper le pass de root lorsque j'appuie sur un bouton "mise en veille".


Mais lorsque systemd est mis à jour, j'observe à chaque fois la 
désactivation de mes modifications.


Aussi, pour l'instant, je n'ai rien trouvé de mieux que la bonne vieille 
méthode du cpold pour garder mes modifs mais je suis conscient que je 
supprime du même coup les nouvelles fonctionnalités du 
org.freedesktop.login1.policy.


Voici ma question: savez-vous s'il existe pour polkit-1/actions un 
système de conservation des règles utilisateurs qui viendraient 
surcharger les règles de base ?


Merki et bonnes fêtes à tous ;)

f.

Re: Trace sur l'écran de Systemd au démarrage et à l'arrêt

[mireero]

On 06/30/2015 04:10 PM, MERLIN Philippe wrote:

Bonjour,
J'ai deux ordinateurs ayant tous les deux un système Debian une Sid AMD64 et
une testing i386 ces deux ne réagissent pas de la même façon au démarrage
(boot) sur la testing chaque fois que systemd lance un service on voit
l'affichage du service lancé et si cela c'est bien passé [OK] en vert, sur la
Sid rien de tout cela l'écran reste muet juste l'apparition de login au bout
de plus de 30 secondes et lancement de xwindows, pas d'apparition non plus de
la progression du fsck ce qui est très gênant. J'aimerai que sur ma Sid je
vois apparaître les mêmes infos que sur la testing, j'ai cherché dans la doc
systemd mais je n'ai rien trouvé concernant ce problème, j'ai certainement mal
cherché. Es ce que la liste pourrais m'aider.
A l'avance Merci.
Philippe Merlin



Peut-être peux-tu aller voir la section sur syslog ici:
https://wiki.archlinux.org/index.php/Systemd

Et sûrement une fausse piste (chez moi j'ai bien les logs au démarrage, 
je dois les confondre avec syslog (qui est bien activé également ici)) :



$ cat /etc/systemd/system/syslog.service
[Unit]
Description=System Logging Service
Requires=syslog.socket
Documentation=man:rsyslogd(8)
Documentation=http://www.rsyslog.com/doc/

[Service]
Type=notify
ExecStart=/usr/sbin/rsyslogd -n
StandardOutput=null
Restart=on-failure

[Install]
WantedBy=multi-user.target
Alias=syslog.service


C'est la ligne StandardOutput=null qui m'intrigue.


Bref, je commence juste à m'intéresser à systemd, et comme c'est dans le 
titre de ton message, je t'en donne.


--
mireero

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/559cca39$0$3368$426a7...@news.free.fr

Re: Trace sur l'écran de Systemd au démarrage et à l'arrêt

[mireero]

On 06/30/2015 04:10 PM, MERLIN Philippe wrote:

Bonjour,
J'ai deux ordinateurs ayant tous les deux un système Debian une Sid AMD64 et
une testing i386 ces deux ne réagissent pas de la même façon au démarrage
(boot) sur la testing chaque fois que systemd lance un service on voit
l'affichage du service lancé et si cela c'est bien passé [OK] en vert, sur la
Sid rien de tout cela l'écran reste muet juste l'apparition de login au bout
de plus de 30 secondes


30 secondes, normal?

et lancement de xwindows, pas d'apparition non plus de

la progression du fsck ce qui est très gênant. J'aimerai que sur ma Sid je
vois apparaître les mêmes infos que sur la testing, j'ai cherché dans la doc
systemd mais je n'ai rien trouvé concernant ce problème, j'ai certainement mal
cherché. Es ce que la liste pourrais m'aider.
A l'avance Merci.
Philippe Merlin



Sans parler de systemd, n'aurais-tu pas un quiet splash sur ta sid 
dans (si tu utilises grub bien sûr) /etc/default/grub ?


--
mireero

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/55972dbe$0$3007$426a7...@news.free.fr

Trace sur l'écran de Systemd au démarrage et à l'arrêt

[MERLIN Philippe]

Bonjour,
J'ai deux ordinateurs ayant tous les deux un système Debian une Sid AMD64 et 
une testing i386 ces deux ne réagissent pas de la même façon au démarrage 
(boot) sur la testing chaque fois que systemd lance un service on voit 
l'affichage du service lancé et si cela c'est bien passé [OK] en vert, sur la 
Sid rien de tout cela l'écran reste muet juste l'apparition de login au bout 
de plus de 30 secondes et lancement de xwindows, pas d'apparition non plus de 
la progression du fsck ce qui est très gênant. J'aimerai que sur ma Sid je 
vois apparaître les mêmes infos que sur la testing, j'ai cherché dans la doc 
systemd mais je n'ai rien trouvé concernant ce problème, j'ai certainement mal 
cherché. Es ce que la liste pourrais m'aider.
A l'avance Merci.
Philippe Merlin

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/1742946.tyxhqEZX5n@portable

Re: Jessie et habitude vis à vis de systemd

[Lucas Nussbaum]

On 12/05/15 at 21:50 +0200, Christophe Mehay wrote:
 Je me permets de répondre car je souhaiterais apporter quelques précisions
 sur la raison pour laquelle unbound ici n'affiche pas d'erreur.
 
 Je pense que vous vous fourvoyez sur la façon dont systemd démarre les
 services, il n'y a pas de binaire compatible ou non avec systemd, la réalité
 c'est qu'un service initialisé avec systemd doit dans l'idéal ne pas forker
 lui-même,

Non, systemd supporte les deux cas (fork avec Type=forking, pas de fork
avec Type=simple). La motivation forte pour ne pas forker, c'est que ce
n'est pas forcément utile, donc autant ne pas le faire. Mais on a vu
dans cette discussion qu'utiliser Type=forking fournissait une manière
peu chère de signaler qu'une partie de l'initialisation du service
s'était bien passée, notamment pour détecter des problèmes de
configuration.

Mais c'est loin d'être parfait: le service pourrait très bien lire sa
config après avoir forké. Et il y a des opérations d'initialisation qui
sont souvent faites après le fork, par exemple ouvrir le port réseau du
service.  S'il y a un autre service qui écoute sur le port, ça serait
alors non détecté.

Du coup, la vraie solution, c'est utiliser /socket activation/, ou
Type=notify, pour que le service soit vraiment opérationnel à la fin de
son démarrage.

 et dans le cas présent, unbound n'utilise pas un service systemd
 mais le script de sysvinit démarré via systemd.
 
 Le soucis que l'on a avec ce système, c'est que systemd n'a plus de pid du
 processus attaché à lui-même, et il ne se contente que d'exécuter le script
 qui va forker unbound avec start-stop-daemon unbound.
 
 Pour systemd, le script a bien été exécuté et il a quitté correctement vu
 que c'est ce qu'on lui a demandé de faire.
 
 Le problème vient ici du fait que le mainteneur n'a pas fait de fichier
 .service conforme pour unbound mais a préféré utiliser le script de sysvinit
 au dessus de systemd, ce qui fonctionne dans le meilleur des cas, mais qui
 n'est pas correcte.

Oui et non. Pour utiliser les scripts sysv, systemd génère à la volée
des fichiers .service englobant le script d'init (visible avec systemctl
cat unbound). Et il le fait plutôt bien (gestion des en-têtes LSB, des
dépendances, etc, cf
http://www.freedesktop.org/software/systemd/man/systemd-sysv-generator.html).

Utiliser un fichier .service ne réglerait vraiment le problème que si le
service n'utilise pas Type=simple, mais ce n'est pas forcément simple ;)
Voir une discussion sur le cas de sshd (qui utilise type=simple, ce qui
empêche de détecter au lancement des erreurs de configuration):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778913#30

Lucas

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20150513054225.ga8...@xanadu.blop.info

Re: Jessie et habitude vis à vis de systemd

[Christophe Mehay]

Je me permets de répondre car je souhaiterais apporter quelques 
précisions sur la raison pour laquelle unbound ici n'affiche pas d'erreur.


Je pense que vous vous fourvoyez sur la façon dont systemd démarre les 
services, il n'y a pas de binaire compatible ou non avec systemd, la 
réalité c'est qu'un service initialisé avec systemd doit dans l'idéal ne 
pas forker lui-même, et dans le cas présent, unbound n'utilise pas un 
service systemd mais le script de sysvinit démarré via systemd.


Le soucis que l'on a avec ce système, c'est que systemd n'a plus de pid 
du processus attaché à lui-même, et il ne se contente que d'exécuter le 
script qui va forker unbound avec start-stop-daemon unbound.


Pour systemd, le script a bien été exécuté et il a quitté correctement 
vu que c'est ce qu'on lui a demandé de faire.


Le problème vient ici du fait que le mainteneur n'a pas fait de fichier 
.service conforme pour unbound mais a préféré utiliser le script de 
sysvinit au dessus de systemd, ce qui fonctionne dans le meilleur des 
cas, mais qui n'est pas correcte.



On 12/05/2015 11:18, Wallace wrote:

Le 12/05/2015 10:58, Lucas Nussbaum a écrit :

On 10/05/15 at 11:38 +0200, Wallace wrote:

Bonjour,
Je tâche depuis la sortie officielle de me dire que si systemd est
fourni c'est qu'il l'est sans bug et sans régression aussi par rapport à
mes tests pré sortie j'essaye de ne plus être négatif sauf que j'ai
vraiment l'impression d'avoir perdu.

Exemple récent, serveur physique chez un hébergeur, installée Jessie, il
est installé par défaut Bind pour la résolution dns, je veux changer et
mettre Unbound à la place.

service bind9 stop

Première remarque avant on savait si un processus était bien démarré ou
éteint là j'en sais strictement rien, mais après tout il pourrait juste
afficher les erreurs et ne rien afficher si tout se passe bien, de plus
mon zsh m'affiche le code retour si il est en erreur et là rien ok.

apt-get install unbound ok pas de soucis

Je télécharge la configuration localhost only que j'ai d'unbound qui
fonctionne sur Debian 6 et 7 et je lance

service unbound start

Là toujours rien d'affiché, mon shell me dit que la commande s'est bien
exécutée mais dans les faits unbound ne s'est pas lancé...
Là pour moi il y a clairement régression, avant j'avais une ligne qui
m'aurait dit erreur au démarrage, là rien et pire le code retour est bon
ce qui fait qu'il est impossible de scripter autour des services de
démarrage ...

Merci pour ton retour et tes explications.


En fait, ça dépend des cas.

Dans ton cas (erreur de configuration), le service est bien démarré,
mais juste après avoir démarré, il lit sa configuration, découvre
qu'elle est fausse, et sort immédiatement. Le problème, c'est que comme
le service avait bien démarré, systemctl ou 'service' avait déjà
retourné que tout s'était bien passé.

Je le prend vraiment comme une régression et je vois déjà les problèmes
que cela va apporter lorsque humainement on se dira tout va bien je n'ai
pas fait de modification sur ce daemon et on va le lancer sans se rendre
compte qu'il n'est pas correctement démarré parce qu'une évolution du
logiciel a fait déprécier des options par exemple.


Avec sysvinit, ça fonctionnait un peu différemment: comme le service
plantait avant de forker, start-stop-daemon détectait qu'il plantait et
affichait un message d'erreur. (qui d'ailleurs, ne résulte pas en un
code de retour différent de 0)

La bonne solution avec systemd serait probablement que unbound
prévienne systemd qu'il s'est correctement initialisé. C'est possible
avec un Type=notify, et systemd-notify / sd_notify.

Mais à part ça, c'est dur de trouver une solution: combien de temps
systemd devrait-il attendre après le lancement d'un service pour
conclure que c'est bon, il tourne depuis X secondes, on peut dire que
s'il a a pas planté jusque là, il fonctionne vraiment! ?

Cela met bien en évidence les faiblesses de ce système quand un fork
était plus logique dans le contrôle des processus.
Le timeout va dépendre pas mal du type de logiciel, par exemple une base
de donnée qui doit faire des vérifications au démarrage cela peut
prendre pas mal de temps. De ce point de vue sysvinit avait déjà ses
limites, un timeout existait et j'ai souvent vu des mysql mettre du
temps à démarrer et avoir un retour comme quoi le processus n'était pas
lancé alors qu'il n'avait juste pas fini ses traitements.

L'envoie du signal par l'application, pourquoi pas mais je vois mal
toutes les applications en mode daemon faire des modifications dans ce
sens sachant qu'après tout chacun est libre de choisir son init. Déjà
que la plupart des progiciels en entreprises préconisent un lancement
manuel à chaque démarrage et que depuis tant d'année faire un script
sysvinit cela semble trop compliqué pour eux ... Il va y avoir vraiment
deux mondes, les binaires aptes à communiquer avec systemd et les autres
... ça sera vraiment dommageable.


Ensuite réflex je fais un tail de /var/log/syslog pour

Re: Jessie et habitude vis à vis de systemd

[Lucas Nussbaum]

On 10/05/15 at 11:38 +0200, Wallace wrote:
 Bonjour,
 Je tâche depuis la sortie officielle de me dire que si systemd est
 fourni c'est qu'il l'est sans bug et sans régression aussi par rapport à
 mes tests pré sortie j'essaye de ne plus être négatif sauf que j'ai
 vraiment l'impression d'avoir perdu.
 
 Exemple récent, serveur physique chez un hébergeur, installée Jessie, il
 est installé par défaut Bind pour la résolution dns, je veux changer et
 mettre Unbound à la place.
 
 service bind9 stop
 
 Première remarque avant on savait si un processus était bien démarré ou
 éteint là j'en sais strictement rien, mais après tout il pourrait juste
 afficher les erreurs et ne rien afficher si tout se passe bien, de plus
 mon zsh m'affiche le code retour si il est en erreur et là rien ok.
 
 apt-get install unbound ok pas de soucis
 
 Je télécharge la configuration localhost only que j'ai d'unbound qui
 fonctionne sur Debian 6 et 7 et je lance
 
 service unbound start
 
 Là toujours rien d'affiché, mon shell me dit que la commande s'est bien
 exécutée mais dans les faits unbound ne s'est pas lancé...
 Là pour moi il y a clairement régression, avant j'avais une ligne qui
 m'aurait dit erreur au démarrage, là rien et pire le code retour est bon
 ce qui fait qu'il est impossible de scripter autour des services de
 démarrage ...

En fait, ça dépend des cas.

Dans ton cas (erreur de configuration), le service est bien démarré,
mais juste après avoir démarré, il lit sa configuration, découvre
qu'elle est fausse, et sort immédiatement. Le problème, c'est que comme
le service avait bien démarré, systemctl ou 'service' avait déjà
retourné que tout s'était bien passé.

Avec sysvinit, ça fonctionnait un peu différemment: comme le service
plantait avant de forker, start-stop-daemon détectait qu'il plantait et
affichait un message d'erreur. (qui d'ailleurs, ne résulte pas en un
code de retour différent de 0)

La bonne solution avec systemd serait probablement que unbound
prévienne systemd qu'il s'est correctement initialisé. C'est possible
avec un Type=notify, et systemd-notify / sd_notify.

Mais à part ça, c'est dur de trouver une solution: combien de temps
systemd devrait-il attendre après le lancement d'un service pour
conclure que c'est bon, il tourne depuis X secondes, on peut dire que
s'il a a pas planté jusque là, il fonctionne vraiment! ?

 Ensuite réflex je fais un tail de /var/log/syslog pour trouver un
 message d'erreur et là rien. J'introduis volontairement une ligne non
 conforme dans le fichier de configuration pour voir et là rien aussi,
 aucun log dans syslog.
 Je suppose que c'est systemd qui a attrapé ces logs mais vu que ce n'est
 pas du fichier texte et qu'il faut passer par une commande que j'arrive
 pas encore à retenir ...
 J'ai fait la même erreur dans le fichier config sur Debian 6 et 7 j'ai
 bien mes logs et le script de démarrage me précise bien que le processus
 n'a pas démarré.

Alors ça, par contre, ça m'étonne beaucoup. J'ai testé:
J'ai modifié /etc/unbound/unbound.conf pour y ajouter une erreur.
J'ai redémarré unbound (service unbound restart).
Je n'ai pas de message d'erreur à cause du problème ci-dessus.
Mais avec 'service unbound status, qui appelle en fait 'systemctl status
unbound', j'ai bien l'extrait de log:

# service unbound status
● unbound.service - (null)
   Loaded: loaded (/etc/init.d/unbound)
  Drop-In: /run/systemd/generator/unbound.service.d
   └─50-insserv.conf-$named.conf, 50-unbound-$named.conf
   Active: active (exited) since Tue 2015-05-12 10:44:36 CEST; 1min 17s ago
  Process: 1827 ExecStop=/etc/init.d/unbound stop (code=exited, 
status=0/SUCCESS)
  Process: 1834 ExecStart=/etc/init.d/unbound start (code=exited, 
status=0/SUCCESS)

May 12 10:44:36 debian unbound-anchor[1843]: /var/lib/unbound/root.key has 
content
May 12 10:44:36 debian unbound-anchor[1843]: success: the anchor is ok
May 12 10:44:36 debian unbound[1834]: Starting recursive DNS server: 
unbound/etc/unbound/unboundqqd'
May 12 10:44:36 debian unbound[1834]: read /etc/unbound/unbound.conf failed: 1 
errors in configur...file
May 12 10:44:36 debian unbound[1834]: [1431420276] unbound[1845:0] fatal error: 
Could not read co...conf
May 12 10:44:36 debian unbound[1834]: failed!
Hint: Some lines were ellipsized, use -l to show in full.

J'ai les mêmes messages avec 'journalctl', et dans /var/log/syslog

Aurais-tu désactivé la redirection vers syslog, par hasard ? (ForwardToSyslog= 
dans /etc/systemd/journald.conf)

Lucas

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20150512085826.ga6...@xanadu.blop.info

Re: Jessie et habitude vis à vis de systemd

[Wallace]

Le 12/05/2015 10:58, Lucas Nussbaum a écrit :
 On 10/05/15 at 11:38 +0200, Wallace wrote:
 Bonjour,
 Je tâche depuis la sortie officielle de me dire que si systemd est
 fourni c'est qu'il l'est sans bug et sans régression aussi par rapport à
 mes tests pré sortie j'essaye de ne plus être négatif sauf que j'ai
 vraiment l'impression d'avoir perdu.

 Exemple récent, serveur physique chez un hébergeur, installée Jessie, il
 est installé par défaut Bind pour la résolution dns, je veux changer et
 mettre Unbound à la place.

 service bind9 stop

 Première remarque avant on savait si un processus était bien démarré ou
 éteint là j'en sais strictement rien, mais après tout il pourrait juste
 afficher les erreurs et ne rien afficher si tout se passe bien, de plus
 mon zsh m'affiche le code retour si il est en erreur et là rien ok.

 apt-get install unbound ok pas de soucis

 Je télécharge la configuration localhost only que j'ai d'unbound qui
 fonctionne sur Debian 6 et 7 et je lance

 service unbound start

 Là toujours rien d'affiché, mon shell me dit que la commande s'est bien
 exécutée mais dans les faits unbound ne s'est pas lancé...
 Là pour moi il y a clairement régression, avant j'avais une ligne qui
 m'aurait dit erreur au démarrage, là rien et pire le code retour est bon
 ce qui fait qu'il est impossible de scripter autour des services de
 démarrage ...
Merci pour ton retour et tes explications.

 En fait, ça dépend des cas.

 Dans ton cas (erreur de configuration), le service est bien démarré,
 mais juste après avoir démarré, il lit sa configuration, découvre
 qu'elle est fausse, et sort immédiatement. Le problème, c'est que comme
 le service avait bien démarré, systemctl ou 'service' avait déjà
 retourné que tout s'était bien passé.
Je le prend vraiment comme une régression et je vois déjà les problèmes
que cela va apporter lorsque humainement on se dira tout va bien je n'ai
pas fait de modification sur ce daemon et on va le lancer sans se rendre
compte qu'il n'est pas correctement démarré parce qu'une évolution du
logiciel a fait déprécier des options par exemple.

 Avec sysvinit, ça fonctionnait un peu différemment: comme le service
 plantait avant de forker, start-stop-daemon détectait qu'il plantait et
 affichait un message d'erreur. (qui d'ailleurs, ne résulte pas en un
 code de retour différent de 0)

 La bonne solution avec systemd serait probablement que unbound
 prévienne systemd qu'il s'est correctement initialisé. C'est possible
 avec un Type=notify, et systemd-notify / sd_notify.

 Mais à part ça, c'est dur de trouver une solution: combien de temps
 systemd devrait-il attendre après le lancement d'un service pour
 conclure que c'est bon, il tourne depuis X secondes, on peut dire que
 s'il a a pas planté jusque là, il fonctionne vraiment! ?
Cela met bien en évidence les faiblesses de ce système quand un fork
était plus logique dans le contrôle des processus.
Le timeout va dépendre pas mal du type de logiciel, par exemple une base
de donnée qui doit faire des vérifications au démarrage cela peut
prendre pas mal de temps. De ce point de vue sysvinit avait déjà ses
limites, un timeout existait et j'ai souvent vu des mysql mettre du
temps à démarrer et avoir un retour comme quoi le processus n'était pas
lancé alors qu'il n'avait juste pas fini ses traitements.

L'envoie du signal par l'application, pourquoi pas mais je vois mal
toutes les applications en mode daemon faire des modifications dans ce
sens sachant qu'après tout chacun est libre de choisir son init. Déjà
que la plupart des progiciels en entreprises préconisent un lancement
manuel à chaque démarrage et que depuis tant d'année faire un script
sysvinit cela semble trop compliqué pour eux ... Il va y avoir vraiment
deux mondes, les binaires aptes à communiquer avec systemd et les autres
... ça sera vraiment dommageable.

 Ensuite réflex je fais un tail de /var/log/syslog pour trouver un
 message d'erreur et là rien. J'introduis volontairement une ligne non
 conforme dans le fichier de configuration pour voir et là rien aussi,
 aucun log dans syslog.
 Je suppose que c'est systemd qui a attrapé ces logs mais vu que ce n'est
 pas du fichier texte et qu'il faut passer par une commande que j'arrive
 pas encore à retenir ...
 J'ai fait la même erreur dans le fichier config sur Debian 6 et 7 j'ai
 bien mes logs et le script de démarrage me précise bien que le processus
 n'a pas démarré.
 Alors ça, par contre, ça m'étonne beaucoup. J'ai testé:
 J'ai modifié /etc/unbound/unbound.conf pour y ajouter une erreur.
 J'ai redémarré unbound (service unbound restart).
 Je n'ai pas de message d'erreur à cause du problème ci-dessus.
 Mais avec 'service unbound status, qui appelle en fait 'systemctl status
 unbound', j'ai bien l'extrait de log:

 # service unbound status
 ● unbound.service - (null)
Loaded: loaded (/etc/init.d/unbound)
   Drop-In: /run/systemd/generator/unbound.service.d
└─50-insserv.conf-$named.conf, 50-unbound-$named.conf
 

Re: Jessie et habitude vis à vis de systemd

[Wallace]

Le 11/05/2015 01:59, Francois Lafont a écrit :
 Bonsoir,

 Le 10/05/2015 14:36, Guillaume a écrit :
  
 Il me semble qu'il est recommandé de remplacer la commande `service` par 
 `systemctl`
 Perso il me semble avoir lu sur cette liste que, justement, on pouvait
 toujours utiliser service qui était une sorte de wrapper qui utilisait
 en backend la bonne commande en fonction du système init et que justement
 c'était très bien comme ça car on n'avait pas à s'embêter. Du coup, les
 questions du PO me semblent légitimes. Je n'ai aucune réponse en l'occurrence
 vu que j'y connais rien encore à systemd.

Je confirme service est bien un wrapper qui sait piloter le bon init
derrière.



signature.asc
Description: OpenPGP digital signature

Re: Jessie et habitude vis à vis de systemd

[Francois Lafont]

Bonsoir,

Le 10/05/2015 14:36, Guillaume a écrit :
 
 Il me semble qu'il est recommandé de remplacer la commande `service` par 
 `systemctl`

Perso il me semble avoir lu sur cette liste que, justement, on pouvait
toujours utiliser service qui était une sorte de wrapper qui utilisait
en backend la bonne commande en fonction du système init et que justement
c'était très bien comme ça car on n'avait pas à s'embêter. Du coup, les
questions du PO me semblent légitimes. Je n'ai aucune réponse en l'occurrence
vu que j'y connais rien encore à systemd.

-- 
François Lafont

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/miordr$oid$1...@ger.gmane.org

Re: Jessie et habitude vis à vis de systemd

[Guillaume]

Bonjour,

Il me semble qu'il est recommandé de remplacer la commande `service` par 
`systemctl`


Le 10/05/2015 11:38, Wallace a écrit :

Bonjour,
Je tâche depuis la sortie officielle de me dire que si systemd est
fourni c'est qu'il l'est sans bug et sans régression aussi par rapport à
mes tests pré sortie j'essaye de ne plus être négatif sauf que j'ai
vraiment l'impression d'avoir perdu.

Exemple récent, serveur physique chez un hébergeur, installée Jessie, il
est installé par défaut Bind pour la résolution dns, je veux changer et
mettre Unbound à la place.

service bind9 stop

Première remarque avant on savait si un processus était bien démarré ou
éteint là j'en sais strictement rien, mais après tout il pourrait juste
afficher les erreurs et ne rien afficher si tout se passe bien, de plus
mon zsh m'affiche le code retour si il est en erreur et là rien ok.

apt-get install unbound ok pas de soucis

Je télécharge la configuration localhost only que j'ai d'unbound qui
fonctionne sur Debian 6 et 7 et je lance

service unbound start

Là toujours rien d'affiché, mon shell me dit que la commande s'est bien
exécutée mais dans les faits unbound ne s'est pas lancé...
Là pour moi il y a clairement régression, avant j'avais une ligne qui
m'aurait dit erreur au démarrage, là rien et pire le code retour est bon
ce qui fait qu'il est impossible de scripter autour des services de
démarrage ...

Ensuite réflex je fais un tail de /var/log/syslog pour trouver un
message d'erreur et là rien. J'introduis volontairement une ligne non
conforme dans le fichier de configuration pour voir et là rien aussi,
aucun log dans syslog.
Je suppose que c'est systemd qui a attrapé ces logs mais vu que ce n'est
pas du fichier texte et qu'il faut passer par une commande que j'arrive
pas encore à retenir ...
J'ai fait la même erreur dans le fichier config sur Debian 6 et 7 j'ai
bien mes logs et le script de démarrage me précise bien que le processus
n'a pas démarré.

Alors je veux bien me remettre en question mais ça fait beaucoup de
changements non justifiés pour un simple remplacement de système d'init.
Syslog a une utilité et j'aimerais bien qu'il l'a garde.

Alors si vous aviez des conseils sur comment réagir dans ce cas typique
mais tellement anodin qu'il ne devrait même pas être toléré de demander
des conseils je suis preneur.

Je résume mes besoins :
- avoir la valeur retour du lancement d'un daemon dans le shell au
lancement de la commande service
- avoir les erreurs éventuelles au lancement de la même commande comme avant
- pouvoir désactiver le catch des logs de systemd et laisser le daemon
loguer en syslog comme avant

Merci pour votre aide.

-




--
Guillaume

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/554f50db.7040...@gwilhom.fr

Re: Jessie et habitude vis à vis de systemd

[maderios]

On 05/10/2015 11:38 AM, Wallace wrote:


Je résume mes besoins :
- avoir la valeur retour du lancement d'un daemon dans le shell au
lancement de la commande service
- avoir les erreurs éventuelles au lancement de la même commande comme avant
- pouvoir désactiver le catch des logs de systemd et laisser le daemon
loguer en syslog comme avant


Bonjour
Ces questions ont déjà été amplement traitées et résolues sur cette 
liste (et ailleurs) il y a moins d'un mois. C'est donc disponible dans 
les archives de la liste.

--
Maderios

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/554f34c7.8080...@gmail.com

Re: [HS]Jessie et habitude vis à vis de systemd

[Txo]

Le 10/05/2015 11:38, Wallace a écrit :
 Je suppose que c'est systemd qui a attrapé ces logs mais vu que ce n'est
 pas du fichier texte et qu'il faut passer par une commande que j'arrive
 pas encore à retenir ...

Systemd décline toute responsabilité pour perte de mémoire de
l'utilisateur et pour l'assassinat de Henri IV…

-- 
-- Dominique Marin http://txodom.free.fr  --
  «N'oubliez jamais que ce qu'il y a d'encombrant dans la morale
c'est que c'est toujours la morale des autres.»
--   Léo Ferré--

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/554f2c18.2000...@free.fr

Jessie et habitude vis à vis de systemd

[Wallace]

Bonjour,
Je tâche depuis la sortie officielle de me dire que si systemd est
fourni c'est qu'il l'est sans bug et sans régression aussi par rapport à
mes tests pré sortie j'essaye de ne plus être négatif sauf que j'ai
vraiment l'impression d'avoir perdu.

Exemple récent, serveur physique chez un hébergeur, installée Jessie, il
est installé par défaut Bind pour la résolution dns, je veux changer et
mettre Unbound à la place.

service bind9 stop

Première remarque avant on savait si un processus était bien démarré ou
éteint là j'en sais strictement rien, mais après tout il pourrait juste
afficher les erreurs et ne rien afficher si tout se passe bien, de plus
mon zsh m'affiche le code retour si il est en erreur et là rien ok.

apt-get install unbound ok pas de soucis

Je télécharge la configuration localhost only que j'ai d'unbound qui
fonctionne sur Debian 6 et 7 et je lance

service unbound start

Là toujours rien d'affiché, mon shell me dit que la commande s'est bien
exécutée mais dans les faits unbound ne s'est pas lancé...
Là pour moi il y a clairement régression, avant j'avais une ligne qui
m'aurait dit erreur au démarrage, là rien et pire le code retour est bon
ce qui fait qu'il est impossible de scripter autour des services de
démarrage ...

Ensuite réflex je fais un tail de /var/log/syslog pour trouver un
message d'erreur et là rien. J'introduis volontairement une ligne non
conforme dans le fichier de configuration pour voir et là rien aussi,
aucun log dans syslog.
Je suppose que c'est systemd qui a attrapé ces logs mais vu que ce n'est
pas du fichier texte et qu'il faut passer par une commande que j'arrive
pas encore à retenir ...
J'ai fait la même erreur dans le fichier config sur Debian 6 et 7 j'ai
bien mes logs et le script de démarrage me précise bien que le processus
n'a pas démarré.

Alors je veux bien me remettre en question mais ça fait beaucoup de
changements non justifiés pour un simple remplacement de système d'init.
Syslog a une utilité et j'aimerais bien qu'il l'a garde.

Alors si vous aviez des conseils sur comment réagir dans ce cas typique
mais tellement anodin qu'il ne devrait même pas être toléré de demander
des conseils je suis preneur.

Je résume mes besoins :
- avoir la valeur retour du lancement d'un daemon dans le shell au
lancement de la commande service
- avoir les erreurs éventuelles au lancement de la même commande comme avant
- pouvoir désactiver le catch des logs de systemd et laisser le daemon
loguer en syslog comme avant

Merci pour votre aide.

-



signature.asc
Description: OpenPGP digital signature

A propos de Systemd

[maderios]

Bonjour
Puisque Systemd va devenir l'init  de Debian, je me permets de poster 
ici le lien qui mène à un long et excellent article en français sur la bête.

https://linuxfr.org/news/mise-aux-poings-sur-systemd
--
Maderios


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/539b1453.5010...@gmail.com

Re: A propos de Systemd

[Fabrice Regnier]

merci ce lien!

à voir les commentaires, on s'aperçoit que systemd va faire parler de 
lui encore longtemps...


f.


Le 13/06/2014 17:30, maderios a écrit :

Bonjour
Puisque Systemd va devenir l'init  de Debian, je me permets de poster
ici le lien qui mène à un long et excellent article en français sur la
bête.
https://linuxfr.org/news/mise-aux-poings-sur-systemd


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/539b2867$0$2136$426a7...@news.free.fr

Re: A propos de Systemd

[Philippe Gras]

Le 13 juin 14 à 17:10, maderios a écrit :


Bonjour
Puisque Systemd va devenir l'init  de Debian, je me permets de  
poster ici le lien qui mène à un long et excellent article en  
français sur la bête.

https://linuxfr.org/news/mise-aux-poings-sur-systemd
--
Maderios

C'est intéressant en effet, et bien expliqué. Merci de l'avoir  
partagé !

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet  
unsubscribe

vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/539b1453.5010...@gmail.com



--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/c61d4a94-20a8-481e-aa40-dd4304c1d...@worldonline.fr