Journal Systemd à la maison

Posté par hugotrip le 14 avril 2021 à 00:29. Licence CC By‑SA.

Étiquettes :

avr.

2021

Bonjour nalles et naux,

Pour mon premier journal, je voudrais vous parler de l'intérêt de Systemd au niveau de l'utilisateur.
N'ayant ni fait des études, ni travaillé dans l'informatique, l'élite de ce site (qui n'apprendra donc rien dans ce journal) comprendra donc que mon langage manque de rigueur, et aura bien sûr l'indulgence et la bienveillance de ceux qui savent.

Mon premier service

au détour d'un site dont j'ai oublié le nom, j'ai découvert qu'il existait un mode utilisateur à systemd, qui permettait donc de lui demander de me rendre des services.
Et ça tombait bien, car je cherchais mollement à automatiser une synchronisation de clé USB, au branchement de celle-ci, et le peu que j'avais vu de udev me paraissait compliqué.
Ici, il suffit d'identifier l'unité correspondant au montage de ma clé USB, avec:

systemctl list-units -t mount

puis d'écrire le fichier synchro-usb.service qui va bien :

[Unit]
Description= Synchro maclef
Requires=maclef.mount
After=maclef.mount

[Service]
ExecStart=/Chemin/Vers/Mon/Script_de_synchro.sh

[Install]
WantedBy=maclef.mount

la section [unit] précise les conditions nécessaires à l'exécution du service, et la section [Install] permet ici d'indiquer qu'il faut rendre ce service de façon automatique au montage de ma clef.
On enregistre ce fichier dans le répertoire (à créer si nécessaire)

~/.config/systemd/user

puis on demande poliment à systemd de démarrer ce service :

systemctl --user start synchro-usb.service

Et puis aussi de l'activer :

systemctl --user enable synchro-usb.service

Et voilà.

Ok Systemd, …

Et je me suis rendu compte que Systemd pouvait être vraiment serviable : j'ai créé un service qui vérifiait mes comptes via ~~boobank~~ woob bank au login (WantedBy=default.target), pour me prévenir si le solde dépassait un certain plancher, mais avec les nouvelles contraintes d'authentification, ça ne marche plus :(.
Et j'ai aussi automatisé des sauvegardes de façon hebdomadaire : pour cela il faut créer fichier .timer qui porte le même nom que le fichier .service, qui n'a plus alors (forcément ?) à contenir de section [Install]. Un exemple de fichier .timer, pour vous montrer que la syntaxe peut être plus simple qu'avec cron :

[Unit]
Description=Backup du mercredi

[Timer]
OnCalendar=Wed 19:00
Persistent=true

[Install]
WantedBy=timers.target

la ligne persistent=true, permet que si mon ordi n'est pas allumé un mercredi à 19h, le service me soit quand même rendu, à la première occasion.

What else

S'il y en a qui utilisent aussi Systemd comme assistant personnel, je serai curieux de savoir quels autres services on peut lui demander.

# Pour du dev local

Posté par gUI (Mastodon) le 14 avril 2021 à 07:59. Évalué à 10. Dernière modification le 14 avril 2021 à 09:10.

J'ai utilisé récemment systemd --user pour une appli web en Python. Comme c'est du dev local et pas de la prod, je ne voulais pas (par principe, pas par contraintes techniques) utiliser un service root.

Par contre j'ai dû (en tant que root) dire à systemd que j'autorisais cet utilisateur à avoir des process qui tournent alors qu'il est déconnecté (sinon il tuait tout à la déconnexion) :

loginctl enable-linger <username>

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Second degrés

Posté par barmic 🦦 le 14 avril 2021 à 08:13. Évalué à 10.

N'ayant ni fait des études, ni travaillé dans l'informatique, l'élite de ce site (qui n'apprendra donc rien dans ce journal) comprendra donc que mon langage manque de rigueur, et aura bien sûr l'indulgence et la bienveillance de ceux qui savent.

C'est peut être du second degrés, mais au cas où : il ne faut pas faire un complexe comme ça. L'informatique (contrairement à l'enrichissement du nucléaire par exemple) est un domaine que chacun peut expérimenter chez soit et où on trouve pleins de gens qui n'ont pas eu de formation initiale qui sont très bons (et des professionnels qui sont très mauvais).

De plus il ne faut pas viser l'élitisme. Décrire des choses simples aide toujours les gens qui découvrent. C'est du partage de connaissance, c'est important.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
- [^] # Re: Second degrés
  
  Posté par jyes le 14 avril 2021 à 08:35. Évalué à 10.
  
  Et il y a de nombreux lecteurs de ce site qui, comme moi, n’ont pas non plus de formation ni d‘expérience professionnelle dans le domaine. J’ai trouvé le journal intéressant. Maintenant qu’on a presque tous systemd d’installé, autant savoir s’en servir, alors merci à l’auteur du journal !
  - [^] # Re: Second degrés
    
    Posté par AncalagonTotof le 14 avril 2021 à 09:04. Évalué à -6.
    
    Il y en a aussi qui, avant d'en faire leurs études avaient environ 8 ans d'informatique derrière eux. Et qui, au premier TP, au lieu du "Hello, world!" traditionnel, codaient le calcul de factorielle en récursif … La tête de Grimomprez et Marengo ! ;-) Bisous au passage,super profs !
    Tout est relatif, à l'époque, c'était ZX81, HP 41, Atari ST …
    Les études apportent beaucoup, mais j'ai gardé de cette époque un goût pour les choses concises, une préoccupation de "ce qui se passe derrière".
    
    Aujourd'hui, c'est "ce qui se passe derrière" qui me préoccupe …
    Dernière entourloupe en date du couple systemd/NetworkManager (à moins qu'ils ne s'appellent autrement de nos jours), c'est sur ma bécane pro, en Debian Buster.
    
    Avant : boot, accès réseau. Oui, c'est tout, c'est con comme un pied de chaise et ça paraît basique.
    Après : boot, plus d'accès réseau. Pas tant que je n'ai pas démarré de session graphique (Plasma ici).
    
    Alors, on m'a aidé, il y a des solutions, le problème est résolu.
    
    Mais ce que je trouve inacceptable, c'est l'attitude des dev de ces services. Ils modifient des comportements basiques, connus depuis des dizaines d'années.
    Et sans prévenir. Avant, c'était bon. Après une update, c'est plus bon.
    
    Du coup, quand j'ai un Linux à installer maintenant, c'est Devuan, sans systemd, avec un init de vieux !
    Au moins, en cas de pépin, j'ai pas besoin de lire tout Internet pour trouver une solution, surtout si j'ai plus Internet à cause du pépin (FW).
    Je peux tirer les fils moi-même, à grands coups de find/grep et cie, nah !
    - [^] # Re: Second degrés
      
      Posté par freem le 14 avril 2021 à 11:34. Évalué à 10.
      Sur le fond, je suis d'accord, mais bon, je ne vois pas le rapport avec le sujet.
      Ici, on parle du fait (avéré, que l'on n'aime ou pas systemd) qu'il est simple de mettre en place un outil qui automatise des actions lors d'un événement, sans avoir à devenir root (tant que l'utilisateur est connecté, si j'ai bien compris gUI, ce qui est tout à fait logique de mon point de vue).
      
      Quitte à troller contre systemd, tu aurais été plus pertinent de relever le fait qu'il semble nécessiter 2 directives que j'aurais naïvement considéré comme faisant la même chose: Requires=maclef.mount, After=maclef.mount.
      
      Pour en revenir à ton problème, si une mise à jour de systemd sur une Debian stable casse ton système, ce n'est pas la faute de systemd, mais de Debian, qui n'a pas assez bien fait son travail.
      Tu as dès lors plusieurs solutions:
      
      passer à devuan, et te retrouver avec les bugs supplémentaires qu'elle contient, sans avoir d'avantage réel (debian permets toujours d'utiliser d'autres init, pour être exact, debian en à même ajouté)
      
      ne plus utiliser systemd sur debian. C'est ma solution. Elle nécessite quelques sacrifices, comme toujours lorsque l'on n'utilise pas les choix par défaut, mais selon le remplaçant choisit, la maintenance peut être vraiment, vraiment négligeable (quasi 0, en fait, comme pour systemd)
      
      contribuer à la résolution du problème. Cela passe par un rapport de bogues en bonne et due forme et un suivi, et peut aller jusqu'à proposer un workaround ou mieux, un correctif. Tu connais sûrement la chanson :)
      
      Je peux tirer les fils moi-même, à grands coups de find/grep et cie, nah !
      
      Un utilisateur n'ayant connu que systemd dira exactement la même chose, puisqu'il ne saura pas se dépêtrer du tas de spaghettis qu'est rc.d, le fameux outil de «gestion» des daemon historique, qui se pose traditionnellement au-dessus de sysVinit.
      
      Et me concernant, moi qui n'aime pas non plus systemd (pour mes propres raisons), si j'avais le choix entre un retour à ces plas de spaghettis shell (parfois même avec de vrais bouts de bâches dedans, vive l'écologie), je choisirai systemd. Il répond à un réel problème, que la traditionnelle combinaison sysVinit+rc.d échoue à résoudre.
      - [^] # Re: Second degrés
        
        Posté par barmic 🦦 le 14 avril 2021 à 11:49. Évalué à 8. Dernière modification le 14 avril 2021 à 11:49.
        
        Je peux tirer les fils moi-même, à grands coups de find/grep et cie, nah !
        
        Un utilisateur n'ayant connu que systemd dira exactement la même chose, puisqu'il ne saura pas se dépêtrer du tas de spaghettis qu'est rc.d, le fameux outil de «gestion» des daemon historique, qui se pose traditionnellement au-dessus de sysVinit.
        
        J'ai connu les 2 et je fais mon choix sans problème. sysVinit demande beaucoup de bricolage pour customiser ce que l'on fait. Passer son temps a faire utiliser apt divert pour faire ce dont on a besoin c'est très casse gueule.
        
        systemd et network manager sont tout à fait compréhensibles, il faut accepter qu'ils ne fonctionnent pas comme leurs alternatives, mais affirmer que ce que l'on connait depuis des dizaines d'années est plus simple qu'un truc nouveau me semble sujet à biais.
        
        En particulier pour le problème présenté. nm peut très bien s'appuyer sur l'ancien système est n'être qu'un proxy à ifupdown et j'ai observé ça sans aller sur internet juste avec les man de mon système + une lecture de quelques scripts (et je parle de scripts triviaux).
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
    - [^] # Re: Second degrés
      
      Posté par thomasv le 14 avril 2021 à 14:43. Évalué à 6.
      
      Avant : boot, accès réseau. Oui, c'est tout, c'est con comme un pied de chaise et ça paraît basique.
      Après : boot, plus d'accès réseau. Pas tant que je n'ai pas démarré de session graphique (Plasma ici).
      
      Alors, on m'a aidé, il y a des solutions, le problème est résolu.
      
      Ça m’intéresserait d’en savoir plus.
      As-tu observé le changement de comportement en faisant une mise à niveau de Stretch vers Buster, ou bien étais-tu déjà sur Buster quand ça s’est produit ?
      
      Te souviens-tu de la solution que tu avais utilisée ?
      
      Mais ce que je trouve inacceptable, c'est l'attitude des dev de ces services. Ils modifient des comportements basiques, connus depuis des dizaines d'années.
      Et sans prévenir. Avant, c'était bon. Après une update, c'est plus bon.
      
      As-tu ouvert un rapport de bug à ce sujet ? Au moins pour savoir si le changement de comportement était volontaire ou pas.
      - [^] # Re: Second degrés
        
        Posté par AncalagonTotof le 14 avril 2021 à 21:34. Évalué à -3.
        
        Solution plus bas.
        
        J'étais déjà en Buster depuis un bon moment. Peut-être même que j'avais fait une réinstalle directement en Buster, suite à "trop de bricolages", je ne me rappelle plus.
        
        Non, pas de rapport de bug. Je serais incapable de dire quand ça s'est passé exactement, et encore moins quels packets ont été mis à jour, vu que j'ai découvert ça fortuitement.
        
        J'ai un volume chiffré que je monte à la main à chaque boot. J'assume d'avoir la flemme (et pas le temps) de faire les choses bien. Donc c'est <CTRL>+<ALT>+<F1> à chaque fois, login root, mount, <CTRL>+<ALT>+<F7>, login graphique. Depuis quelques mois.
        
        Beaucoup plus récemment, j'ai ajouté un montage sshfs en tant que user, pas root. Mais comme j'ai souvent des documents de ce montage ouverts (surtout des PDF), et que j'aime bien que Okular les retrouve quand je me logue, j'ai modifié ma procédure pré-ouverture session graphique : après le montage du volume chiffré, su - , montage sshsf.
        
        C'est là que "ça marchait, et pi un jour, ça marche pu".
        Un poil de diagnostique : ah ? Pas d'IP sur mon interface réseau ? OK, dhclient a la mano.
        Le lendemain : pareil.
        Le surlendemain : pareil.
        Euh, ça commence à bien faire …
        
        Du coup j'ai crié "au secours" auprès de mes potes qui sont de vrai admin sys (parce que moi, c'est pas un full time job).
        
        Et une solution passe par la config réseau via NetworkManager en ligne de commande en étant root à l'aide de nmtui. Là, on a l'impression de se retrouver dans l'utilitaire de KDE/Plasma, mais en dialog console.
        J'ai configuré, ça a marché, sauf un conflit temporaire avec ma config faite en user sous Plasma.
        Depuis, ça semble tenir le coup, je croise les doigts.
        
        J'essaye de mettre du chaud et du froid, du sérieux et du cynique, du second degré dans mes posts. Donc je tiens à préciser aux pisse-froid qui ont tout pris au premier degré, et qui on moinsé mon post, que oui, ils ont raison, je suis vieux et les outils modernes ont des avantages. Mais mon cas de figure, en tant que dév-pas-vraiment-admin-loin-de-là, je pense qu'on peut le transposer dans un scénario catastrophe :
        
        un vrai admin
        
        qui gère des centaines de VM
        
        en Debian Buster
        
        mise à jour
        
        reboot de toutes les VM, pour n'importe quelle raison (la femme de ménage qui débranche pour passer l'aspirateur ? Rigolez pas, c'est vraiment arrivé)
        
        le(s) host(s) reboote(nt)
        
        les VM démarrent
        
        sans réseau
        
        Alors ça peut arriver ou pas ?
        Ça pourrait arriver aussi avec un truc de vieux ou pas ?
        
        Et pour être certain que tout le monde ait bien saisi le problème :
        - config qui marche
        - mise à jour
        - ÉNORME changement de comportement sur un point critique
        
        Faut aimer le risque pour continuer à aimer systemd et les trucs qui tournent autour ou prennent le même chemin.
        
        Ça va finir comment ? Login graphique impératif pour gérer un Linux ? Un Windows quoi ?
        
        [^] # Re: Second degrés
        
        Posté par Astaoth le 14 avril 2021 à 23:09. Évalué à 5.
        
        Mais mon cas de figure, en tant que dév-pas-vraiment-admin-loin-de-là, je pense qu'on peut le transposer dans un scénario catastrophe :
        - un vrai admin
        - qui gère des centaines de VM
        - en Debian Buster
        - mise à jour
        - reboot de toutes les VM, pour n'importe quelle raison (la femme de ménage qui débranche pour passer l'aspirateur ? Rigolez pas, c'est vraiment arrivé)
        - le(s) host(s) reboote(nt)
        - les VM démarrent
        - sans réseau
        
        Jamais eu ce cas en mettant à jour des Debian ou n'importe quelle distro justement, et sur un bon paquets de serveurs. Sinon faire des snapshots avec les upgrades de version n'est pas une mauvaise idée, et/ou redonder les services. De même, des serveurs ca se redémarre, entre autre quand une upgrade déploie un nouveau kernel.
        
        Ça pourrait arriver aussi avec un truc de vieux ou pas ?
        
        En tant qu'user de Archlinux depuis plus de 10 ans, honnêtement oui, totalement. En tant qu'user de FreeBSD pour des serveurs perso, j'ai fait exploser un OS en le mettant à jour … j'avais pas lu le patchnote qui indiquait une manip spécifique pour cette upgrade là.
        
        Systemd c'est juste un outil somme toute différent de SysVInit, avec ses points forts et ses points faibles. En revanche, les mainteneurs de distros n'ont pas changé lorsque Systemd est arrivé, les politiques de gestion des services non plus. Dans le cas de Debian ils savent très bien que c'est déployé sur des serveurs, et que ne pas fournir une connexion réseau au démarrage d'un serveur c'est un léger problème. Je ne pense pas que ton problème soit général mais plutôt spécifique à ton environnement.
        
        Emacs le fait depuis 30 ans.
      - [^] # Re: Second degrés
        
        Posté par Astaoth le 14 avril 2021 à 22:56. Évalué à 3.
        
        As-tu observé le changement de comportement en faisant une mise à niveau de Stretch vers Buster, ou bien étais-tu déjà sur Buster quand ça s’est produit ?
        
        Je trouverais ca curieux qu'en changeant de version de Debian il faille d'un coup obligatoirement avoir une session graphique pour avoir le réseau, vu le nombre de serveurs sous Debian.
        
        Te souviens-tu de la solution que tu avais utilisée ?
        
        Si tu utilises Network Manager, vérifie sa configuration, et aussi celle de networkd. Mes serveurs ont le réseau au démarrage sans config particulière, mon Arch perso qui boot en tty et que je traine depuis des années d'un PC à l'autre aussi.
        
        Mais ce que je trouve inacceptable, c'est l'attitude des dev de ces services. Ils modifient des comportements basiques, connus depuis des dizaines d'années.
        Et sans prévenir. Avant, c'était bon. Après une update, c'est plus bon.
        
        Ca parle de Arch là, nan ? :D
        
        Emacs le fait depuis 30 ans.
  - [^] # Re: Second degrés
    
    Posté par esdeem le 14 avril 2021 à 09:10. Évalué à 10.
    
    Je pertinente!
    
    Quand j'ai commencé à fréquenter ce site, j’étudiais l'archéologie et le grec ancien (avant 2004, ça fait ~~un bail~~ 3 baux), et je n'avais aucune expérience en informatique, sauf comme utilisateur.
    
    J'ai toujours trouvé ces retours d'expériences fort enrichissants.
    
    Depuis, l'informatique est devenue mon métier. Je dois dire que je trouve toujours ce genre de choses intéressant. D'une part, parce que ça me permet de comprendre comment les gens découvrent le fonctionnement de leur machine, d'autre part, parce que je ne connais pas tout parfaitement, surtout quand je n'ai pas à l'utiliser directement.
    
    /my life
    
    0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
- [^] # Re: Second degrés
  
  Posté par TuxMips le 14 avril 2021 à 08:59. Évalué à 10.
  
  L'informatique (contrairement à l'enrichissement du nucléaire par exemple) est un domaine que chacun peut expérimenter chez soit et où on trouve pleins de gens qui n'ont pas eu de formation initiale qui sont très bons (et des professionnels qui sont très mauvais).
  
  Je suis en total désaccord avec cette affirmation. Nous avions une remarquable page du wiki qui depuis un ou deux ans a disparue, voir peut être un peu plus, qui permettait précisément d'expérimenter chez soi le nucléaire ! On retrouve cette page dans la wayback machine.
  
  http://web.archive.org/web/20140704112837/http://linuxfr.org/wiki/apprenez-a-creer-votre-reacteur-nucleaire
  
  |__> je sors …..
  - [^] # Re: Second degrés
    
    Posté par blobmaster le 14 avril 2021 à 15:26. Évalué à 4.
    
    Voir aussi : https://fr.wikipedia.org/wiki/David_Hahn
- [^] # Re: Second degrés
  
  Posté par Elephant (site web personnel) le 14 avril 2021 à 10:15. Évalué à 10.
  
  Et même ayant fait des études et bossant dans le domaine, bah j’aurais jamais pensé à utiliser systemd comme ça. J’ai appris un truc donc.
  
  On est toujours le petit de quelqu’un !
- [^] # Re: Second degré
  
  Posté par Benoît Sibaud (site web personnel) le 14 avril 2021 à 11:11. Évalué à 10.
  
  Le dernier compte que j'ai eu à purger était justifié par le fait « de ne pas se sentir partie prenante la communauté du site », « n'étant pas informaticien » et étant « plutôt manuel ». Être accueillant / bienveillant, éviter l'élitisme, considérer la communauté dans toute sa diversité (et prendre en compte cette diversité (*)) est essentiel pour le site, pour son avenir et pour les communautés du libre en général d'ailleurs.
  
  (*) des exemples :
  - géographie : pays (et donc indirectement culture), métropole/outre-mer, capitale/province/régions
  - âge / génération
  - homme / femme
  - activité (pro/associative/etc.) dans l'informatique ou non
  - les sujets non logiciels (robotique, culture libre, DIY, etc.)
  - handicap
  - proche/membre d'un GULL / une asso libriste / un CHATON / un fablab ou non
  - à l'aise à l'écrit ou non
  - opensource ou logiciel libre
  - etc.
  - [^] # Re: Second degré
    
    Posté par hugotrip le 14 avril 2021 à 22:17. Évalué à 2.
    
    Rassurez-vous, c'était bien essentiellement du second degré.
    Je lis linuxfr sans participer depuis de nombreuses années, et donc je m'y plais suffisamment.
    Si j'ai ajouté cette précision, c'est simplement car malgré tout ce journal porte plutôt sur de la technique, dont je ne maîtrise pas tout le vocabulaire : je répondais juste par anticipation à d'éventuels commentaires sur des "erreurs de formulation", car par exemple le concept d'unité systemd reste quand même bien obscur pour moi ( d'où le fait que je me restreigne aux services, qui pour mon usage, sont plutôt bien nommés).
- [^] # Re: Second degrés
  
  Posté par kowalsky le 15 avril 2021 à 17:10. Évalué à 4.
  
  Et j'ajouterais que l'informatique c'est très large.
  Tu peux être bon ou expert dans un domaine et avoir tout à apprendre dans un autre domaine. En fait en informatique, à notre époque, être au top sur tout un domaine, c'est peu courant. Par exemple, pour dire, je maitrise à 100% le dev|linux|réseau, il faut être un peu menteur.
  - [^] # Re: Second degrés
    
    Posté par Pol' uX (site web personnel) le 15 avril 2021 à 17:55. Évalué à 3.
    
    Ou inconscient. Ça suffit aisément et c'est un profil qui se rencontre souvent. :)
    
    Adhérer à l'April, ça vous tente ?
# service user et timers

Posté par Psychofox (Mastodon) le 14 avril 2021 à 09:38. Évalué à 3.

j'utilise aussi systemd pour faire tourner un client onedrive non officiel.

Même si cron existe toujours les timers sont sympa aussi à utiliser.
- [^] # Re: service user et timers
  
  Posté par freem le 14 avril 2021 à 11:37. Évalué à 0.
  
  Tant qu'a avoir un outil qui gère les processus, je dirais que d'y intégrer le planificateur de tâche (qui gère des processus) fait clairement sens.
  Surtout quand on voit la gueule de la config de cron…
  - [^] # Re: service user et timers
    
    Posté par claudex le 14 avril 2021 à 12:05. Évalué à 7.
    
    La gueule de la config, je ne sais pas, ça ne me dérange pas trop dans cron, surtout que dans systemd, tu dois te taper 10 lignes réparties dans 2 fichiers au minimum.
    
    Par contre il y a plusieurs avantages de mon point de vue. Déjà, tu peux facilement voir si un job a été lancé et quand il sera lancé, et trouver les logs d'un job facilement. Ensuite, tu peux facilement lancer un job dans la mêmes conditions (notamment avec les mêmes variables d'environnement) avec systemctl start job.service. Ce qui est compliqué à faire avec cron (pas impossible bien sûr, mais le fait que ce ne soit pas out of the box est un problème).
    
    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
    - [^] # Re: service user et timers
      
      Posté par freem le 14 avril 2021 à 13:16. Évalué à 2.
      dans systemd, tu dois te taper 10 lignes réparties dans 2 fichiers au minimum.
      
      Je reconnais ne pas connaître les détails pour systemd, c'est peut-être moins concis, certes, je n'ai personnellement pas de bonne solution pour ça (ne faisant que très très rarement des planification de tâches, et jamais avec systemd).
      Par contre, pour cron, j'ai ce genre de choses:
      
      % cat /etc/cron.d/e2scrub_all 30 3 * * 0 root test -e /run/systemd/system || SERVICE_MODE=1 /usr/lib/x86_64-linux-gnu/e2fsprogs/e2scrub_all_cron 10 3 * * * root test -e /run/systemd/system || SERVICE_MODE=1 /sbin/e2scrub_all -A -r
      
      Désolé, mais… j'ose espérer que systemd à quand même une config plus lisible.
      Je préfère un truc verveux (bon, que ça soit coupé en 2 fichiers c'est dommage par contre) plutôt qu'un one-liner illisible sans être lourdement commenté (encore, ici, «la chance!» seul root est utilisé, donc tout s'aligne, et il n'y a que 2 lignes…).
      
      Les rares fois ou je dois utiliser cron, je lis le manuel, plusieurs fois pour être sûr, puis j'écris une ligne, et je la relis plusieurs fois, en comptant les espaces…
      Idéalement, je teste sur plusieurs périodes (jours/heures… pour les semaines ou les mois, c'est pas possible, et je crois qu'il peut pas gérer les années) que ça fonctionne vraiment, et dans tous les cas, je serre les fesses de pas m'être raté.
      
      Le tout, alors que fonctionnellement le but est simplement de gérer des processus et leurs journaux, ce qui est très clairement du ressort d'outils comme systemd ou les daemontools (sauf que eux n'ont pas cette fonctionnalité, sauf peut-être nosh?).
      J'ai beau ne pas être fan de systemd, il me semble difficile de considérer que sysVinit+rc.d+cron est une solution magnifique.
      daemontools|runit + cron est un peu moins bancal, mais on se tape quand même le fait que les gestionnaires de processus sont incapables de planifier la gestion de processus, ce qui est pourtant leur coeur de métier…
      
      En pratique, si ma machine est censée fonctionner non-stop, plutôt qu'installer cron, je préfère faire ça:
      
      #!/bin/sh #./run # une "lib" de 26 lignes que je me suis faite . /etc/runit/common echo "starting $SVNAME" test -e ./conf || die "config not found" exec $COMMAND
      
      #!/bin/sh #./finish . /etc/runit/common test -e ./conf || die "config not found" sleep $PERIOD
      
      #./conf PERIOD="1d" COMMAND="foobar"
      
      Ces fichiers sont placés dans un dossier type /etc/sv/task_$foo, qui contiens un sous dossier log, qui contiens un fichier run qui est un symlink vers /etc/runit/log.run.
      Du coup, ça fait pas mal de monde pour de simple tâches planifiées.
      
      Le résultat est moins bon et moins puissant qu'avec systemd (en plus ça pourrit mon arbo de processus :/) ou cron (sans parler d'anacron!), mais…
      Comparé à cron, j'ai nettement plus confiance dans le fonctionnement ainsi qu'une meilleure facilité pour consulter les journaux d'une tâche spécifique.
      
      Par chance je n'ai que rarement besoin d'y avoir recours. Sinon, le poids sur le système pourrais devenir problématique (dans le cas de runsvdir, il lance à chaque fois un processus pour gérer le daemon lui-même, et un autre pour les logs, ça fait donc 2 processus constants pour des tâches qui ne nécessitent des ressources que ponctuellement. Ce n'est pas énorme, mais c'est tout de même dommage de gaspiller, et ça ne se mets pas à l'échelle, contrairement à cron ou… systemd.)
      
      Ici, je pense que systemd gagne haut la main.
      - [^] # Re: service user et timers
        
        Posté par claudex le 14 avril 2021 à 13:28. Évalué à 5.
        
        Par contre, pour cron, j'ai ce genre de choses:
        
        Ben, tu prends aussi des trucs système qui vérifie si systemd existe avant de lancer la tâche, ça complique évidemment les choses. Un tâche simple avec cron qui se lance toutes les heures, c'est
        
        0 * * * * root /usr/local/bin/myscript.sh
        
        Je trouve que c'est assez lisible.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: service user et timers
        
        Posté par Zenitram (site web personnel) le 14 avril 2021 à 15:28. Évalué à 2. Dernière modification le 14 avril 2021 à 15:29.
        
        Je trouve que c'est assez lisible.
        
        C'est vrai qu'entre "0 * * * *" et "RestartSec=1h", le premier est clairement assez lisible, on comprend tout de suite ce que ça fait même en n'y ayant pas touché depuis un moment, et n'importe quel débutant va comprendre redémarrage toutes les heures… (ou pas).
        
        Syndrome de Stockholm ou masochisme?
        
        [^] # Re: service user et timers
        
        Posté par claudex le 14 avril 2021 à 15:44. Évalué à 4.
        
        Si c'est pour ne pas lire le thread, ça ne sert à rien de répondre.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: service user et timers
        
        Posté par vv222 (site web personnel) le 14 avril 2021 à 23:20. Évalué à 4.
        
        Le débutant, on ne lui propose pas :
        
        0 * * * * script.sh
        
        mais :
        
        @hourly script.sh
        
        (sauf si on est sadique)
        
        Ce n’est pas que pour le débutant d’ailleurs, il n’y a pas vraiment de raison d’utiliser 0 * * * * plutôt que @hourly.
        
        [^] # Re: service user et timers
        
        Posté par wismerhill le 15 avril 2021 à 17:19. Évalué à 5.
        
        il n’y a pas vraiment de raison d’utiliser 0 * * * * plutôt que @hourly.
        
        Certes, mais par contre si on a plusieurs scripts à lancer toutes les heures (jours, semaines, mois), c'est intéressant de mettre autre chose que 0 pour qu'ils ne se lancent pas tous au même moment.
        
        [^] # Re: service user et timers
        
        Posté par Yth (Mastodon) le 15 avril 2021 à 18:21. Évalué à 6.
        
        Ou sinon :
        ln -s /mon/script/a/lancer/toutes/les/heures.sh /etc/cron.hourly/
        Et ça va se lancer toutes les heures.
        
        Tu as aussi /etc/cron.daily/, /etc/cron.weekly/ et /etc/cront.monthly/
        En général, ce n'est pas une obligation, bien sûr, que ces répertoires existent, mais c'est souvent le cas.
        
        Après, ça gère quelques cas très généraux, et pas des cas particuliers, où ton script doit être lancé le second dimanche de chaque mois à 13h57 précisément.
        
        Yth.
        
        [^] # Re: service user et timers
        
        Posté par freem le 14 avril 2021 à 16:10. Évalué à 4.
        
        Ben, tu prends aussi des trucs système qui vérifie si systemd existe avant de lancer la tâche, ça complique évidemment les choses
        
        Pas vraiment. Le problème de balancer un one-liner proviens du fait que cron exécute directement un shell, j'imagine. En soit, je trouve que c'est déjà une erreur, moi, il ne devrais pas être nécessaire de passer par /bin/sh comme intermédiaire. Oui, ça impliquerais que les scripts seraient des fichiers séparés, probablement one-liners, mais ça éviterais ce cas précis (tout en supprimant une couche d'exécution, cela dit, puisque ce serait alors uniquement le noyau qui ferait l'exécution, qu'il fera de toute façon).
        
        Mon reproche est plutôt de la sorte de mélopée qui précède la commande: un nombre variable de nombres, qui peuvent parfois être des astérisques.
        Je comprend bien que je ne suis pas un habitué des crontabs, mais voila, je trouve 0 * * * * incompréhensible moi. Quand je lis ça, j'ai besoin d'aller lire la page du manuel. En soit, ce n'est pas un drame de devoir aller lire la doc, mais voila on ne parle pas vraiment d'une doc super claire. Ah, pardon, peut-être celle-ci… nope, celle-la? Ah, oui, enfin!
        La description de la partie la moins lisible est au milieu du bouzin, et ça deviens fun quand on commence à jouer avec les intervalles et les listes.
        J'allais dire qu'il n'y a même pas d'exemple, ce qui eut été faux:
        
        EXAMPLE CRON FILE top # use /bin/sh to run commands, no matter what /etc/passwd says SHELL=/bin/sh # mail any output to `paul', no matter whose crontab this is MAILTO=paul # CRON_TZ=Japan # run five minutes after midnight, every day 5 0 * * * $HOME/bin/daily.job >> $HOME/tmp/out 2>&1 # run at 2:15pm on the first of every month -- output mailed to paul 15 14 1 * * $HOME/bin/monthly # run at 10 pm on weekdays, annoy Joe 0 22 * * 1-5 mail -s "It's 10pm" joe%Joe,%%Where are your kids?% 23 0-23/2 * * * echo "run 23 minutes after midn, 2am, 4am ..., everyday" 5 4 * * sun echo "run at 5 after 4 every sunday"
        
        La, on commence a voir à quel point tout ça est lisible, en effet. Oui, c'est ironique.
        C'est concis, ça oui, clairement, mais lisibilité s'en ressens pas mal, je trouve. Après, oui, je suis d'accord, ma solution custom (et dégueu) n'est pas idéale non plus, systemd n'est pas non plus parfait, chacun à ses forces, mais je préfère vraiment éviter cron, j'ai toujours peur qu'il me pète à la gueule.
      - [^] # Re: service user et timers
        
        Posté par Gil Cot ✔ (site web personnel, Mastodon) le 15 avril 2021 à 22:19. Évalué à 8.
        
        Tu prends un exemple tiré par les cheveux comme justificatif argumentaire …qui au passage n'est pas si justifié que ça.
        
        Crontab traditionnel attend "une commande" point barre. Que ta commande soit kilométrique (du fait des chemins à rallonge ou des noms trop long ou les deux comme dans ton cas avec /usr/lib/x86_64-linux-gnu/e2fsprogs/e2scrub_all_cron) ou que tu utilises les possibilités de l'interpréteur de commande pour faire des tests et enchaînements de commandes (comme dans ton exemple test -e /run/systemd/system || SERVICE_MODE=1 /sbin/e2scrub_all -A -r) n'empêche qu'on attend là quelque chose vu comme une seule commande (même si en pratique ce peut être un bloc comme tu le fais ou un appel de fichier de script comme on fait traditionnellement.) Ah ça tombe bien, c'est la même chose avec le systemd-timer : tu as une ligne qui indique la commande et c'est toujours ne commande qui sera toujours à rallonge dans ton cas.
        
        Crontab est un tableau (c'est le sens du tab dans le nom) et ce que tu appelles un « one-liner » n'est qu'une ligne du tableau et c'est tout aussi lisible qu'un fichier CSV ou TSV (ah tiens, on peut utiliser des tabulations à la place des espaces dont le nombre n'est pas limité si tu tiens vraiment à indenter, mais bon…)
        
        Systemd-timer n'utilise pas un tableau regroupant toutes les tâches et leur périodicité, mais deux fichiers par unit de timer ; ce qui convient aux gens qui aiment avoir les chosent éparpillées un peu partout et démultiplier les fichiers. Mais comme il y a des commandes pour masquer le bazar sous-jacent ça plait.
        
        Les rares fois ou je dois utiliser cron, je lis le manuel, plusieurs fois pour être sûr, puis j'écris une ligne, et je la relis plusieurs fois, en comptant les espaces…
        
        La plupart des distributions Linux aujourd'hui, en tout cas pour CentOS et Debian, le fichier commence par des lignes de commentaire qui indique l'ordre des champs
        
        # Example of job definition: # .---------------- minute (0 - 59) # | .------------- hour (0 - 23) # | | .---------- day of month (1 - 31) # | | | .------- month (1 - 12) OR jan,feb,mar,apr ... # | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat # | | | | | # * * * * * user command to be executed
        
        Quand ça n'y est pas, je rajoute perso une ligne laconique du genre
        
        # mm hh jj MMM JJJ user task-job
        
        Il est facile d'écrire une interface, comme le font
        
        des services web d'hébergement de cron (Cf. setCronJob, webCronJob, easyCron, ou encore cron-job par exemple)
        
        des services d'administration d'hébergement comme webmin, [cPanel], Ajenti, etc.
        
        des programmes installés en local, comme : crontab-ui (web), Gnome Schedule (X/GTK), Zeit (X/Qt), cron-gui-launcher (X/Bash), et certainement d'autres
        
        Il est enfin possible de nos jours de s'aider un site web pour les usages rares/occasionnels sans y passer du temps : corntab, cronhub, cronmaker, free formater, crontab generator, crontab guru, rakko tools, etc.
        cronjob predicator et cron expression descriptor eux sont utiles dans l'autre sens en quelque sorte.
        
        “It is seldom that liberty of any kind is lost all at once.” ― David Hume
# systemd fait tout, sauf la vaisselle

Posté par Sébastien Rohaut le 14 avril 2021 à 10:10. Évalué à 10.

Si ça peut "rassurer" (ou pas, selon le contexte), j'ai beau être sysops de formation avec un gros background Linux sur de grosses plateformes, et avoir formé des centaines et des centaines de personnes, bah… Je découvre encore régulièrement des fonctionnalités, notamment dans systemd, qui gère à peu près tout…

Et donc, je n'avais jamais expérimenté les services utilisateurs, et je suis heureux de voir un journal qui en parle. Merci beaucoup. Et en plus, les timers, bah c'est pas la première chose qui vient à l'esprit, il y a une très grande majorité des sysops qui ne les connait pas ou ne les utilise pas avec systemd (qui remplace tout, donc cron aussi), voire qui ne connait que les fonctions systemd de base : gérer des services (et pas le réseau, les dns, les crontabs, les périphériques, les containers, les … bah tout…).

Merci donc pour ce journal fort agréable.
- [^] # Re: systemd fait tout, sauf la vaisselle
  
  Posté par barmic 🦦 le 14 avril 2021 à 11:38. Évalué à 10.
  Et en plus, les timers, bah c'est pas la première chose qui vient à l'esprit, il y a une très grande majorité des sysops qui ne les connait pas ou ne les utilise pas avec systemd (qui remplace tout, donc cron aussi), […]
  
  Pour moi c'est LA killer feature de systemd :
  - syntaxe plus confortable à lire
  - possibilité de voir quand il a était déclenché pour la dernière fois et quand est-ce que sera la prochaine
  - possibilité de lancer manuellement la tâche en ayant le même environnement (utilisateur, dossier de travail, variable d'environnement,…)
  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
  - [^] # Re: systemd fait tout, sauf la vaisselle
    
    Posté par Christophe le 14 avril 2021 à 12:05. Évalué à 3. Dernière modification le 14 avril 2021 à 12:06.
    
    J'aime beaucoup les timers aussi, qui remplacent assez simplement cron.
    
    Par contre, j'ai voulu mettre en place un timer qui se déclenche "environ tous les 4-5 jours" pour faire un backup régulier, lorsque je suis sur l'ordi… mais ce n'est simplement pas possible sur un ordinateur qu'on éteint tous les soirs.
    
    Il faut donc passer par un calendrier avec "Persistent=true".
    - [^] # Re: systemd fait tout, sauf la vaisselle
      
      Posté par Psychofox (Mastodon) le 14 avril 2021 à 16:23. Évalué à 8.
      
      Environ tous les 4-5 jours ça n'existe pas vraiment mais quelques pistes pour avoir des trucs assez flexible:
      
      OnCalendar=weekly te permet de le démarrer au moins une fois par semaine, ça s'en rapproche. Après si tu le démarres tous les lundis à environ 8h bam il va lancer la sauvegarde toujours à ce moment, ça peut être considéré ok ou pas.
      
      WakeSystem=true pour réveiller un système en veille. Tu peux imaginer seulement suspendre ton système chaque soir et lancer un backup la nuit quand tu dors de façon non intrusive avec un arrêt ou nouveau suspend direct derrière. Du coup ton backup est non intrusif et tu utilises peu d'électricité avant et après.
      
      OnBootSec=5h45min ou OnStartupSec=4h30min va démarrer le timer va attendre le délai donné respectivement après le boot ou le lancement de la session. Ça peut être utile si par exemple quand tu travailles tu sais que tu fais des longues sessions de 7 à 8h sans rebooter mais que le week-end tu vas peut-être vouloir l'utiliser sporadiquement et que tu ne veux pas que le backup se déclenche si tu ne veux garder le pc allumé que 15 minutes.
      
      Pour vraiment lancer tous les 4-5 jours le plus simple c'est de démarrer ton script tous les jours et de poser un lock. En vérifiant l'age du fichier de lock tu sais si tu dois poursuivre ou quitter le script.
      
      Mais bon perso je ne vois pas l'intérêt de ne pas faire des backups tous les jours, d'une manière générale plus ils sont fréquents, moins ils durent longtemps. Et tu ne peux pas décider quel jour tu vas faire la conneries de supprimer tel ou tel fichier ou quel jour ton disque dur va péter.
      - [^] # Re: systemd fait tout, sauf la vaisselle
        
        Posté par Christophe le 14 avril 2021 à 16:57. Évalué à 3.
        
        Oui, au départ j'étais déçu de ne pas pouvoir faire ce que je voulais. J'ai 3 petits scripts de backups, et je voulais éviter qu'ils se marchent trop sur les pieds. Mais petit à petit je réalise que j'aurais mis en place un backup imprévisible, avec des problèmes difficilement reproductibles.
        Donc finalement, ça m'a orienté vers une meilleure solution, ce qui n'est pas plus mal !
      - [^] # Re: systemd fait tout, sauf la vaisselle
        
        Posté par _kaos_ le 14 avril 2021 à 17:01. Évalué à 8. Dernière modification le 14 avril 2021 à 17:03.
        
        Salut,
        
        Et tu ne peux pas décider quel jour tu vas faire la conneries de supprimer tel ou tel fichier ou quel jour ton disque dur va péter.
        
        Archi faux !
        
        En général il tombe, soit (non exclusif) :
        
        la veille du jour où l'installation d'une solution de backup arrive en haut de la TODO list,
        
        un week-end ou jour férié, si on n'a pas de disque spare sous la main,
        
        le lendemain (forcément avant le backup s'il y en a, attention) de la réception d'un document important,
        
        et plein d'autres petites subtilités comme ça…
        
        En étant rigoureux sur son planning, ça se voit tout de suite.
        
        D'ailleurs, je vais vérifier le mien, afin d'anticiper et repousser la date.
        
        Mais… je l'ai foutu où ce planning ?
        
        Matricule 23415
        
        [^] # Re: systemd fait tout, sauf la vaisselle
        
        Posté par Gil Cot ✔ (site web personnel, Mastodon) le 15 avril 2021 à 22:22. Évalué à 1.
        
        Ah oui, loi de l'emmerdement maximale où tout tombe au mauvais moment et de préférence en cascade ; sacré Murphy.
        
        “It is seldom that liberty of any kind is lost all at once.” ― David Hume
- [^] # Re: systemd fait tout, sauf la vaisselle
  
  Posté par Pseudo007 le 15 avril 2021 à 16:46. Évalué à 5.
  
  Faut arrêter avec les "systemd fait tout".
  Systemd ne fera pas traitement de texte, pas serveur web, pas gestionnaire de base de données, etc.
  En chiffre.
  Le src.rpm de systemd fait 10Mo. L'ensemble des src.rpm de f34 fait 58Go.
  Donc systemd c'est 0,017 % d'une Fedora. Ce sont des chiffres pour donner un ordre de grandeur, rien de plus. Sur un installation desktop minimum (par exemple le profil "Fedora Workstation" sans rien de plus), ça doit faire maxi 0,5%. Si systemd faisait tout, on se passerait des 99,5 % qui constitue le "reste".
  
  Le problème des services utilisateurs est qu'il doivent être gérés.
  Cas plus intéressant, les démons utilisateurs qui ne doivent être là que lorsque la session est ouverte.
  Avec systemd, on est sûr qu'à la fin de la session le service utilisateur est tué. On peut aussi être sûr qu'il va être relancé s'il plante. On est sûr qu'il est comptabilité dans les ressources (dont la mémoire), etc. S'il y a des dépendances, systemd le gère.
  Il est donc complètement normal que systemd le fasse. Et ça sera plus fin. Avec SeLinux, il sera aussi vérifié que cette appli ne se connecte pas partout, etc.
  
  Cet aspect utilisateur de systemd ne fait que commencer. On pourra à l'avenir, en étant utilisateur, télécharge des applis tiers, qui ne sont pas de confiance, et les faire tourner sans risque (plus besoin comme aujourd'hui de créer un compte séparé ou un container, etc). Quand on arrête l'appli, on est sûr qu'elle est arrêtée. Ce qui avant était loin d'être évident…
  
  Quand on comprend le rôle de systemd, on comprend qu'il n'est pas là pour tout faire. Évidemment, certains diront que tel ou tel truc pouvait ne pas être dans systemd. Ya toujours des exceptions pour confirmer la règle.
  - [^] # Re: systemd fait tout, sauf la vaisselle
    
    Posté par bbo le 17 avril 2021 à 14:42. Évalué à 4.
    
    Systemd ne fera pas traitement de texte, pas serveur web, pas gestionnaire de base de données, etc.
    
    Exact, pour cela il y a Emacs ! Emacs fait même le "etc."
    
    ;)
    - [^] # Re: systemd fait tout, sauf la vaisselle
      
      Posté par jyes le 17 avril 2021 à 16:50. Évalué à 3.
      
      Dommage qu’il y manque un bon éditeur de texte, sinon le système Emacs/Systemd/Linux aurait tout pour séduire.
# Système D

Posté par AlexTérieur le 14 avril 2021 à 10:34. Évalué à 4.

Je ne suis pas informaticien tout comme toi et j'avoue ne pas avoir énormément participé ici mais le peu de fois que je l'ai fait j'ai trouvé que j'ai été plus que bien "accueilli", même si j'ai conscience du manque de connaissance par rapport à certains et de vocabulaire technique, personne ne me l'a reproché.
Voilà.
# Syncthing en mode utilisateur sur des machines partagées

Posté par Zertrin (site web personnel) le 14 avril 2021 à 10:36. Évalué à 4.

J'utilise systemd --user pour faire tourner le binaire de services comme syncthing sur des machines multi-utilisateurs où je ne serais pas en mesure de l'installer au niveau système et/ou ça ne serait pas pratique. Ça me permet de synchroniser des données utilisateur depuis/vers lesdites machines, en étant complètement encapsulé au niveau utilisateur et sans déranger les autres.

Seule action préalable nécessitant les droits admin: activer enable-linger pour pas que les services utilisateurs soient tués quand je me déconnecte.
- [^] # Re: Syncthing en mode utilisateur sur des machines partagées
  
  Posté par freem le 14 avril 2021 à 11:56. Évalué à 4. Dernière modification le 14 avril 2021 à 11:58.
  Pas systemd, certes, mais j'utilise le même genre de choses.
  
  Pour être plus explicite, voici mon .xinitrc actuel, bien que je pense migrer certaines choses vers ~/.profile ou équivalent, voire trouver une meilleure solution, plus portable, parce que les shell sont des horreurs de ce point de vue:
```
export SVDIR=$HOME/.config/services
runsvdir -P $SVDIR ............................................................ &
xrandr --output HDMI-3 --right-of HDMI-2
#urxvtd -o &
#unclutter -idle 2 -jitter 2 &
setxkbmap fr 
#(pidof mpd > /dev/null || mpd --no-daemon ~/.config/mpd/mpd.conf --stderr) &
xosview &
#claws-mail &
#/bigfiles/$USER/contrib/quassel/build/quasselclient &
numlockx on
exec ssh-agent chpst -P i3
```
  Toutes les lignes zombifiées (d'ailleurs, c'est l'occasion de les virer, je devrais peut-être également ajouter xosview, je ne sais pas trop, il n'est pas vraiment critique à mon usage…), en fait, elles sont maintenant gérées par runsvdir.
  
  Cela permets une vraie facilité de gestion et d'intégration, totalement indépendante de mon gestionnaire de fenêtres ou de mon bureau, ainsi que des avantages propres à diverses catégories d'outils:
  - mpd: tendance à planter quand interruption de connexion réseau (locale ou distance) lors de écoute de webradio;
  - unclutter: conflits avec certains jeux et applications qui capturent la souris;
  - toute application que je pourrais fermer par accident alors que j'ai besoin de la présence continuelle, telle que le MUA ou le client IRC, ou encore urxvtd;
  Au final, avec le temps je m'aperçois que j'utilise de plus en plus le mécanisme de gestion des daemon de mon système pour des tâches liées à l'utilisateur.
  Ce n'est pas spécifique à systemd (puisque je n'utilise pas), de fait, mais je trouve ce type d'usage très pertinent et puissant, peu importe l'implémentation. Par contre, rien de tout ça n'est aisément réalisable avec l'ancêtre sysVinit et cette pile de shell qu'est rc.d (sans parler de la taille des scripts à écrire! beurk!).
  
  Sur mon serveur perso, j'ai simplement créé une service runsvidir par mon utilisateur, ce qui semble être un équivalent de systemd --user, vu que pas de session interactive sur le serveur.
# systemd et autotrash

Posté par Maderios le 14 avril 2021 à 18:58. Évalué à 0.

Allergique à GVFS et Cie, n'ayant pas de poubelle, j'ai installé (Arch Aur) autotrash, service systemd démarré au niveau utilisateur.
https://github.com/bneijt/autotrash
# Et donc, on peut se passer de cron ?

Posté par tisaac (Mastodon) le 14 avril 2021 à 22:53. Évalué à 4.

Merci à l'auteur pour ce journal et à tous pour les commentaires.

C'est une impression ou bien quelqu'un qui le souhaiterait pourrait totalement se passer de cron ?
Ou bien il y a des trucs fondamentaux que cron propose qui n'ont pas d'équivalents en utilisant les possibilités de systemd ?

Surtout, ne pas tout prendre au sérieux !
- [^] # Re: Et donc, on peut se passer de cron ?
  
  Posté par claudex le 15 avril 2021 à 09:35. Évalué à 3.
  
  Il est tout à fait possible de se passer de cron.
  
  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
- [^] # Re: Et donc, on peut se passer de cron ?
  
  Posté par Adrien le 15 avril 2021 à 10:59. Évalué à 5.
  
  Oui. Par exemple pour ma sauvegarde j'utilise systemd comme présenté dans le journal, mais elle tourne toute les heures.
  
  Mon PC est un portable, pas souvent allumé. Donc lorsque j'allume le PC à 18h30, il fait la sauvegarde direct, si celle de 18h n'est pas passée.
  
  Avec Cron, il attend 19h… et le PC est de nouveau éteint.
  
  Perso j'ai l'impression que c'est l'inverse : systemd propose des choses que cron ne pourra jamais faire.
  - [^] # Re: Et donc, on peut se passer de cron ?
    
    Posté par TuxMips le 19 avril 2021 à 19:26. Évalué à 2.
    
    Donc par exemple, étant précisé que je ne suis pas développeur ni informaticien, je pourrais me servir de systemd pour réaliser le transfert de mes deux fichiers de sauvegardes de Signal qui se trouve sur la mémoire du téléphone vers la carte µSD ?
    
    En effet, mon smartphone est sous sailfish OS et Signal tourne dans un Android "conteneurisé". Signal n'accède donc pas à la carte µSD. Enfin en tous cas l'option dans les paramètres de Signal n'est pas accessible.
    
    Du coup avec systemd, je pourrais imaginer qu'à telle heure, le ou les fichiers se trouvant dans le répertoire de sauvegardes soient copiés ou mieux transféré vers la carte µSD ? Que le "couper/coller" que je réalise manuellement puisse se faire automatiquement, ce serait top !
    
    Merci de votre avis avant que je me lance dans l'opération (qui se terminera peut-être par des questions dans le forum) !
  - [^] # si un modo pouvait passer par là pour supprimer ce message
    
    Posté par TuxMips le 19 avril 2021 à 19:28. Évalué à 1. Dernière modification le 19 avril 2021 à 19:30.
    
    J'ai posté deux fois la même chose par inadvertance :-(
    désolé pour le bruit

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.