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 ce
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 re
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
iel (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.
&g
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
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:
&
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=&qu
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
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... :-(
J
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 éven
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
>
> Su
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 p
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
er, 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 d
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'audie
e 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 vi
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.co
ng à 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 ch
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 t
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
>
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:
> > -
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
(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ço
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 Gra
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
>>> mt
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 que
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
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
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
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
--exclud
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 s
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 to
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,
raylei
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 qd
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
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 ave
'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
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 serv
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.
P
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
p-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é utilise
blè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/0
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
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
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 "serv
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
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 com
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 syste
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
ur 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
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,
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ça
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.debi
53 matches
Mail list logo
