framboise314.fr

Bonjour,
Merci, c'est pas mal comme solution :
Attente non systématique mais seulement lorsque cela est nécessaire
Et prise en charge du redémarrage : j'aime bien

Je vais essayer ce soir ou demain

Sinon, il y a une chose que je ne m'explique pas :
Si je crée mon service avec sysv (l'ancien système qui est toujours supporté aujourd'hui.... mais on ne sait pas pour combien de temps encore)
Et bien mon service démarre bien après le chargement du pilote.
Curieux : systemd lancerait ses services natifs avant ceux pris en charge par compatibilité (sysvgenerator) ?
M'enfin, de toute manière, je veux faire un service systemd natif (question de pérennité : rien de pire qu'une méthode qui fonctionnait et ne fonctionne plus ans plus tard)

Salut Piper.

J'ai créé quelques services mais aucun ne sont en attente d'un quelconque montage pour démarrer.

Pour ce qui est de la dépendance, je crois que l'unité en question doit déjà exister dans systemctl.
Pour un montage manuelle par "mount", je crois que cela ne fonctionne pas en tant que dépendance.
En fait, j'ai pas tout compris de son fonctionnement.

Je préfère faire une règle udev plutôt qu'un service si un montage est nécessaire.

Piper a écrit :question de pérennité : rien de pire qu'une méthode qui fonctionnait et ne fonctionne plus ans plus tard

C'est assez dans le style de linux de repenser tous les deux ans aux modifications que nous avons apportées à l'OS.
Ce fut le cas avec mes règles udev et le fameux paramètre "MountFlags=shared".
J'essaye de rester dans la normalité et non de faire du spécifique qui risque après de ne plus fonctionner correctement.

P.S.: si tu testes un montage comme ma clef USB, tu peux utiliser ceci : Le code retour à tester n'est plus "2" mais "1".

Cordialement.
Artemus24.
@+

C'est assez dans le style de linux de repenser tous les deux ans aux modifications que nous avons apportées à l'OS.

Pas d'accord :
Sous Linux, on peut avoir 10 ans pour faire des modifications (Ex : migration de python 2 à Python 3, toujours en cours depuis 2008 !, ou migration de sysv à systemd toujours en cours depuis 2010). Et chaque fois, nous sommes prévenu : des fonctions sont dépréciées : elles fonctionnent et mais provoquent un une notice, puis un warning ou du moins, la littérature indique clairement qu'il faut plutôt suivre telle voie plutôt que telle autre
Mieux : Ex , sous RedHat/Fedora/CentOS : firewalld a remplacé iptable mais iptable est toujours disponible, installable avec les dernières mises à jour si vous en avez besoin.

Sous windows, il en va tout autrement : brutalement et sans pratiquement aucune information, ce qui était courant ou toléré est interdit.
Les migrations de Windows 9.x à NT/XP ont été catastrophique pour les développeurs , les entreprises et les particuliers de même celles de NT/XP à Vista (encore pire)
Combien de périphériques parfaitement fonctionnels avez vous jeté à la poubelle parce que le driver était incompatible avec la nouvelle version de $indow$ et pas mis à jour ?
Combien vous a coûté l'achat de licences Office 2003 lors que passage de XP à Vista alors que vous avez Office 97 ou antérieur , acquises et fonctionnelles mais qui ne fonctionnaient pas sur votre nouveau matériel ?
Pire, combien de millions d'euros ont été dépensé par les entreprises , obligées de passer à une autre version de leur EDI de dev suite à un changement de version de windows ? (une licence d'un tel EDI coûte vite plusieurs milliers d'Euros)

Bon sinon, mon problème avec systemd (qui n'a rien avoir avec le montage d'un périphérique) semble bien être résolu grâce à ExecStartPre : merci !
Pour autant, je ne comprends pas pourquoi le soucis n'existe pas avec SysV sauf si systemd gère les services produit par SysVgenerator en dernier (mais google ne m'as pas fourni de réponses à ce sujet)

Salut Piper.

Piper a écrit :mon problème avec systemd (qui n'a rien avoir avec le montage d'un périphérique) semble bien être résolu grâce à ExecStartPre : merci !

Je suis heureux pour toi. Cela m'a permis de découvrir d'autres fonctionnalités des services. Cela peut toujours servir dans l'avenir.

Piper a écrit :Pas d'accord :

J'essaye d'utiliser le plus possible les outils standards des OS. Je ne suis pas contre un changement dans l'évolution, ce qui est tout à fait normal. Mais je désire une compatibilité ascendante dans l'outil que j'utilise, ce qui n'est pas toujours le cas. Le mieux est de basculer d'un ancien outil à un autre plus évolué. Par exemple les batchs windows et PowerShell. Je ne me suis toujours pas mis au PowerShell car je le trouve un peu trop compliqué à mon goût.

Tu as mis "Windows 9.x" qui n'existe pas ? Je suppose que tu voulais parler de "Windows 3.x", non ?

Je ne comprends pas trop ton "Pas d'accord" car tu es dans la même ligne de conduite que moi. Sans changer de version (passer de Buster à Bullseye par exemple), il arrive qu'une mise à jour provoque des problèmes. Cela manque de fiabilité dans la façon de procéder. Et comme tu l'indiques, c'est un manque de respect envers les développeurs et les utilisateurs de leur imposer un choix qui n'est pas le leur.

Cordialement.
Artemus24.
@+