Forum général.cherche-logiciel Gestionnaire de tâches évolué

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
6
15
mai
2024

Bonjour à tous,

Pour mon poste utilisateur je cherche une solution simple pour lancer des tâches suivant un contexte.

Par exemple : je veux lancer la sauvegarde de mon ~/home lorsqu'une connexion réseau est détectée.

Lorsque je dis simple c'est en comparaison au gestionnaire de tâches qu'on peut retrouver sur Windows qui s'avère être efficace et assez facile à utiliser/maintenir. Il a l'avantage de pouvoir gérer des tâches avec un lancement horaire et/ou alors des tâches avec un lancement par rapport à un contexte.

Avant il existait gnome-schedule qui aurait pu répondre partiellement à mon besoin, mais à priori il n'est plus dispo, en tout cas sur ma Fedora 39. Après avoir pas mal recherché sur le net je suis toujours ramené vers cron (ou équivalent) ou alors un truc à base de service systemd mais à chaque je trouve que la solution est trop complexe à mettre en place ou maintenir pour une fonction qui me parait tellement basique.

Avez-vous déjà mis en place des solutions équivalentes ?

Merci d'avance.

  • # Snap ?

    Posté par  (site web personnel) . Évalué à 3. Dernière modification le 15 mai 2024 à 17:47.

    On peut en général recréer un paquet disparu : juste il faut une Fedora/RHEL sous la main, et dans mon cas ce sera pas avant quelques jours.

    En attendant, il a l'air dispo via Snap (oui je sais…).
    Après avoir installé le nécessaire pour Snap, peux-tu essayer :

    sudo snap install gnome-schedule --edge

    • [^] # Re: Snap ?

      Posté par  (site web personnel) . Évalué à 2.

      J'utilise le plus rarement possible flathub sur mon pc car j'ai eu des comportements étonnant suivant l'app. Cela va de la lenteur extrême, à des problèmes d'accès à certains fichiers. Du coups si j'ai le choix je prends le rpm.

      Born to Kill EndUser !

  • # Cron pour les gouverner tous ?

    Posté par  . Évalué à 3. Dernière modification le 16 mai 2024 à 01:41.

    je suis toujours ramené vers cron (ou équivalent) ou alors un truc à base de service systemd mais à chaque je trouve que la solution est trop complexe à mettre en place ou maintenir pour une fonction qui me parait tellement basique.

    pourtant quoi de plus simple que cron ?

    avec au choix, tu es root de la machine :

    • ton script dans /etc/cron.hourly ou daily ou weekly ou monthly pour le faire tourner une fois par heure, jour, semaine, mois
    • un appel dans /etc/crontab pour definir des trucs plus chelou genre toutes les X minutes ou X jours, ou le premier dimanche de chaque mois, lance le script Y, si ca te fait un fichier trop compliqué un fichier par job dans /etc/cron.d/
      • /etc/cron.d/monjobA
      • /etc/cron.d/monjobB
    • crontab -e -u unuser pour editer le fichier crontab d'un utilisateur (remplace -e par -l pour juste en afficher le contenu)

    • [^] # Re: Cron pour les gouverner tous ?

      Posté par  . Évalué à 3. Dernière modification le 16 mai 2024 à 09:05.

      Personnellement je lance mes tâches utilisateurs avec des services et timers systemd, ça juste marche.

      Avec le service, on peut facilement demander le réseau en prérequis (en utilisant la cible network-online.target), avec le timer on peut demander à ce que ce soit lancé chaque semaine/jour/whatever.

      Certes il n'existe pas de GUI pour ça à ma connaissance et c'est dommage, mais je ne reviendrai pas à cron pour ce type de planification.

      • [^] # Re: Cron pour les gouverner tous ?

        Posté par  . Évalué à 3.

        Je n'utilise plus que des timer systemd depuis plusieurs années mais je dois avouer que j'avais un peu galéré pour trouver comment lancer des timers pour des utilisateurs sans session ouverte. A l'époque, le "loginctl enable-linger username " n’était pas super bien documenté.

    • [^] # Re: Cron pour les gouverner tous ?

      Posté par  . Évalué à 0.

      cron pour des cripts ça bug de temps en temps (pas vraiment un bug hein ! ), c'est un utilisateur particulier, et ton script au petit oignon ne se lancera pas pour pleeeiiiin de raison, pas les droits, pas la syntaxe, les chemin ne lui plaise pas etc …

      je dirais si tu fait un truc de temps en temps c'est un peu ennuyeux de passer 3h a comprendre pour ton .sh qui déplace des fichiers ne se lance pas correctement, parfois même un binaire ne se lance pas :/

      il y a https://crontab.guru/ qui te change la vie maintenant mais reste toujours l'interrogation pourquoi ton script ne se lance pas ou ne fonctionne pas

      je suis assez d'accord avec l'auteur initial

  • # cme et Config::Model::Systemd

    Posté par  . Évalué à 2.

    Je viens de voir qu'il existe une interface graphique pour aider à configurer ses units systemd.

    Malheureusement pas packagée pour Mageia, mais on peut installer par le cpan.

    Si quelqu'un connait l'outil et peut nous éclairer.

    https://metacpan.org/pod/Config::Model::Systemd

  • # Systemd

    Posté par  (site web personnel) . Évalué à 5.

    Pour ton exemple Borgmatic a une conf timer+service qui lance quotidiennement un backup lorsque le réseau est connecté, sous réserve que l'alimentation soit branchée (dans le cas d'un portable).

    Adhérer à l'April, ça vous tente ?

    • [^] # Re: Systemd

      Posté par  (Mastodon) . Évalué à 3. Dernière modification le 28 mai 2024 à 08:37.

      C'est clair qu'il doit exister une règle systemd pour faire ça. Faut juste trouver la bonne target et lancer son service, qui peut même être lancé sous le compte utilisateur (et non pas pas root).

      En tous cas c'est vers systemd que je chercherais la solution, il est exactement à ça.

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # Commentaire supprimé

    Posté par  . Évalué à 1. Dernière modification le 02 juillet 2024 à 15:06.

    Ce commentaire a été supprimé par l’équipe de modération.

Suivre le flux des commentaires

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