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
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
te 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-
x) ; - 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 d
ription 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 scr
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 q
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 syst
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... :-(
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
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
>
>
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
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
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
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 ?
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 l
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
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
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
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
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
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
>>>
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
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
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
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
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
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
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
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,
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
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
'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
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
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
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
.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
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 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
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
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
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
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
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
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
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 :
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
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,
53 matches
Mail list logo
