Forum Linux.debian/ubuntu Message cron redondant.

Posté par  . Licence CC By‑SA.
Étiquettes :
0
30
mai
2013

Salut Linux FR.

Voilà je pense qu'un ou deux spécialistes de la question pourra m'aider là je ne vois pas trop ça doit être tout bête pourtant.

J’eus fut un temps installé duplicity pour tester, ce n'est plus le cas.

mathieu@gamabomb:~$ sudo apt-get remove duplicity
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Le paquet duplicity n'est pas installé, et ne peut donc être supprimé
0 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.

Or quotidiennement je ne cesse de recevoir ce rapport du daemon Cron.

/etc/cron.daily/man-db:
/usr/bin/mandb: impossible d'ouvrir /usr/local/share/man/man1/duplicity.1: Permission non accordée
run-parts: /etc/cron.daily/man-db exited with return code 2

Dans ma crontab : 

mathieu@gamabomb:~$ sudo crontab -e
no crontab for root - using an empty one
No modification made

Que faire pour nettoyer l'affaire ?! Sans doute un lien avec man-db également mais je ne vois pas trop.

Merci les apaches.

  • # c'est dans cron

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

    c'est dans cron
    /etc/cron.daily/man-db
    tu edites ce fichier et tu supprimes la ligne qui embête.
    /etc/crond.daily il y a dans ce répertoire des scripts qui sont exécuté chaque jour.

  • # dans l'ordre

    Posté par  . Évalué à 1.

    [1] /etc/cron.daily/man-db**:
    [2] /usr/bin/mandb: impossible d'ouvrir /usr/local/share/man/man1/duplicity.1: Permission non accordée
    run-parts: /etc/cron.daily/man-db exited with return code 2

    on te dit que c'est le script man-db du dossier /etc/cron.daily qui t'envoie l'erreur.

    ensuite on te dit que c'est un probleme de droit sur un fichier
    certes tu as enlevé le logiciel duplicity, mais seulement avec apt-get remove
    il y a donc encore des fichiers qui trainent.

    en purgeant les fichiers man-db ne devrait plus raler

    pour eviter cela la prochaine fois, tu pourras faire apt-get remove --purge lenomdupaquet

    • [^] # Re: dans l'ordre

      Posté par  . Évalué à 0.

      Bon, vu le chemin du fichier de manuel (/usr/local/share/man/man1/duplicity.1), je pense que le duplicity installé ne faisait pas partie des paquets officiels. Je ne sais pas comment tout cela a été installé puis supprimé, mais apparemment il reste un fichier (un lien symbolique cassé ?) dans /usr/local/share/man/man1.
      Je pense que la solution est simplement de supprimer ce fichier (/usr/local/share/man/man1/duplicity.1), après avoir vérifié à quoi il ressemble…

      • [^] # Re: dans l'ordre

        Posté par  . Évalué à -1. Dernière modification le 30 mai 2013 à 17:26.

        Salut,

        Effectivement de mémoire j'avais installé via les paquets officiels, mais comme la version était buguée (bug déclarée et corrigé avec la version suivante), j'ai effectué une MAJ manuelle.

        En effet le fichier /usr/local/share/man/man1/duplicity.1 n'est que le man du produit et contient en première ligne :

        .TH DUPLICITY 1 "October 28, 2012" "Version 0.6.20" "User Manuals" \" -*- nroff -*-

        Or dans les paquets debian nous en sommes à la 0.6.18.

        J'ai supprimé ce fichier (et je n'ai pas surtout pas touché au contenu de /etc/cron.daily/man-db )

        Sinon qu'est ce que le cron vient tripoter quotidiennement les fichiers manuels, en cas de maj de ce dernier, recompilation des index ou quelque chose du genre ?

        D'ailleurs une question me vient à l'esprit suite à ce problème, je suis sur la branche "stable" debian, les paquets intégrés sont donc sensés donc être également stable non ?!

        Or pour duplicity je vous assure que ce n'est pas encore bon pour être dropé en prod.

        • [^] # Re: dans l'ordre

          Posté par  . Évalué à 0.

          cron exécute quotidiennement mandb afin de créer ou de mettre à jour les index des pages de manuels. Ces index sont utiles pour accélérer certaines opérations et pour permettre à des commandes comme apropos de fonctionner.

          Sous Debian stable (wheezy) on a effectivement la version 0.6.18 qui devait être la version courante au moment du freeze. Les versions sous testing et sid sont un peu plus récentes (0.6.21, sortie en janvier, disponible dans sid). Mais bon, quels sont ces bugs, corrigés dans les versions les plus récentes, qui t'empêche d'utiliser la version de wheezy ? Je t'avoue que je n'utilise duplicity que sur quelques serveurs perso mais que je n'ai pas encore rencontré de problème…

          • [^] # Duplicity 0.6.18 en prod : mauvaise idée !!

            Posté par  . Évalué à 0.

            Je permets de revenir suite au problème avec duplicity, puisque j'ai remis les mains dedans et j'ai à nouveau rencontré le même problème sur Debian 7.1 avec duplicity 0.6.18 fournit dans les repo officiel.

            Je confirme il y un gros BUG lorsqu'on utilise la couche SFTP pour sauvegarder.

            Je te conseille de faire un essaie de sauvegarde (--no-encryption ou pas d'ailleurs) d'un de tes répertoires vers un accés SFTP tu verras que l'outil te dégueule une palanguée d'exceptions Python et qu'il est impossible de sauvegarder plus loin que la racine de ton SFTP.

            Surtout lorsque tu t'attardes un peu plus sur les Changelog et que tu constates la tonne de correctifs et de merge qu'apportent les 3 dernières versions duplicity 0.6.18 en prod … hum … hum … hum …

            Peut-être utilises-tu un autre protocole mieux implémenté (FTP ?!), mais à tu déjà essayé de faire une restau ?

Suivre le flux des commentaires

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