CoolRaoul

Pour les impatients, Il existe une autre option que j'ai mentionnée ici:

Voila: "ps" affiche la liste des processus en cours (sur d'autres versions de linux il aurait été necessaire d'ajouter des arguments pour l'avoir complète) "grep" filtre son entrée (qui ici est la sortie de la commande "ps" qui lui est connectée par "|" dit "pipe"), et ne laisse passer que les lignes contenant la chaîne de caractère spécifiée ("crond" dans ce notre cas)

Sympa le nom. Pour un euro (en bitcoins via le port USB) il éjecte une mousse bien fraîche je suppose?

La mienne ou ce qui est listé ci dessous? On voit deux process cron en cours d’arrêt et un autre en cours de démarrage. Rédémarre le NAS pour mettre tout ça propre

Tout est normal et j'en perd mon latin (j'ai pourtant un peu de bouteille dans le domaine) Ah moins que l'explication soit si grosse et devant mes yeux que je ne la voir même pas.

Tu n'aurais pas 5 services cron démarrés par hasard? (un "restart" qui ne parviendrai pas à arréter l'instance en cours) Que donne cette commande? /bin/ps | grep crond

Au passage je n'ai toujours pas trouvé comment visualiser la sortie d'erreur de ces commandes. Tout se passe "en aveugle" et je trouve ça un peu dommage (une erreur dans la conf apache et il ne redémarre pas mais rien n'est signalé dans le terminal). Si tu as une piste je suis preneur.

Pas facile de comprendre ce qui se passe: le shell effectue le parsing des arguments indépendamment de la commande. A tout hasard, vérifie ce que donnent chez toi les commandes type ls et type rm Ben moi, je pratique cet environnement (AIX et ksh) tout les jours depuis des années et je n'ai jamais rencontré cette anomalie. Bien entendu (tu penses que j'ai vérifié avant de répondre), comme sur tous les autres shells unix que je pratique d'ailleurs.

D'apr

Ca défie toute logique! Je n'ai *jamais* rencontré un tel comportement en shell (et je suppose que tu utilise bien le shell standard, "/bin/ash" je suppose ?)

Mais ça ne marchera pas pour le find car les espaces sont dans les chemins de fichiers trouvés par le find lui même. Dans ce cas, la bonne approche est: find . -name @eaDir -type d -print0 | xargs -0 rm -rf (les "0" sont des zeros, pas la lettre "O") A tester une fois "a blanc" (avec un "rm" on ne sait jamais) avec un echo: find . -name @eaDir -type d -print0 | xargs -0 echo rm -rf

Voila déjà la commande pour redémarrer apache: /usr/syno/sbin/synoservicecfg --restart httpd-user et pour le cron je ne serais pas surpris que: /usr/syno/sbin/synoservicecfg --restart crond fonctionne. PS: pourquoi avoir posté cette question dans ce fil? Pas terrible pour sa visibilité je trouve.

petit d

Non, ça c'était avant (avant DSM 5) Mais c'est bon, j'ai temporisé jusqu'au soir (et le fichier est n'est pas touché par l'update)

J'ai voulu en avoir le coeur net. Et en fait il existe de subtiles différences (pour le compte root en tout cas) lorsque une tache programmée est exécutée en mode programmé (planification) et quand on utilise juste le bouton "exécuter" (pour un simple test) Ce n'est que dans le premier cas que $HOME est bien positionné, et par suite "~" bien étendu. Je dirai volontiers que c'est un bug

A noter qu'elle est Incluse avec le DDNS gratuit de Synology.

Je serais intéressé de savoir si l'update écrase le contenu de "/etc/httpd/conf/httpd.conf-user" pour décider si je peux la faire à distance ou si j'attend d'être de retour à la maison.

Le pb de synchro n'était pas lié à l'update: je l'ai eu aussi en début d’après midi et ça duré quelques heures. Sans doute un coup de vapeur sur les serveurs DDNS de chez Syno.

Il est en effet possible que je n'ai pas bien compris quel sens il fallait donner à "liens de téléchargement" C'est aux "liens partagés" créés avec filestation auxquels je pensais (ma réponse s'appliquant à ce contexte). Faut reconnaître que l'exposé du problème est un peu vague

Pour le compte "root" c'est /root/.ssh/ Bizarre que l'expansion du "~" ne marche pas en cron, peut-être que $HOME est indéfini dans ce cas mais j'en doute

Sous DSM, la commande "ssh" est dans "/usr/syno/bin" Ce chemin n'est pas dans le PATH des commandes lancées en cron et/ou via le gestionnaire de tâches Faut donc ajouter : PATH=/usr/syno/bin/:/bin:/usr/bin en tête de ton script Et, pour faire bon poids, remplacer >> /volume1/web/log.txt par >> /volume1/web/log.txt 2>&1 sous peine de perdre la sortie d'erreur

Peut-être suffirait-il simplement de renseigner le nouveau nom hôte+domaine (fqdn) dans le panneau de conf DSM -> accès externe -> avancé -> "nom d’hôte ou IP statique" A essayer en tout cas

Si je comprend bien, le script dont tu a parlé un peu plus haut ("qui exécute toutes ces taches et a la fin il eteint le syn avec cette commande : nohup shutdown -h now") fonctionnait jusqu'alors et en lui ajoutant la commande ssh il ne fonctionne plus? La c'est incompréhensible je ne sais pas quoi dire. Faut commencer par supprimer la commande ssh et voir si il fonctionne toujours Et ensuite, tu peux ajouter la ligne ci dessous en tete de script (la ligne juste apres celle d'en-tete "#!/bin/sh"): exec > /tmp/monscript.log 2>&1 comme cela tu pourra aller lire le .log pour voir ce qui coince.

Je ne comprend pas pourquoi tu trouves "pas pratique d'y accéder" maintenant que tu as appris qu'il s'agit d'un répertoire alors que ça ne semblait pas te poser de problème quand tu pensais que c'était un fichier