CoolRaoul

Lancé au démarrage (tu ne nous a pas dit comment mais ça ne change fondamentalement pas grand chose) l’environnement est minimum, et c'est le perl syno ("/usr/bin/perl", qui m'a souvent provoqué des problèmes louches) et pas celui d'optware qui va être utilisé. Pour forcer l'utilisation du perl optware: mettre le bon PATH *dans* le script (PATH=/opt/bin:/bin:/usr/bin) S'assurer aussi que le script est lancé *apres* que le "mount -bind" de "/opt" soit effectué (démarrage optware). Egalement, il est fort possible que la base de données ne soit pas encore démarrée lorsque le script est lancé au boot. Sinon, pour comprendre pourquoi le log ne se créée pas, faudrait que tu explique quelle méthode tu utilises pour le démarrage auto du script.

Son *nom* sera visible mais, si les droits l'interdisent, son contenu ne le sera pas! Depuis le début tu entretiens la confusion entre "voir le *nom* du dossier" et "accéder au *contenu* du dossier" (en tout cas c'est ce que les gens qui te lisent risquent de conclure, vu comment tu présentes la chose). Ecrire "dès qu'on a un compte sur le Nas d'une manière ou d'une autre on arrive à voir les dossiers / sous dossiers" laisse entendre que DSFile permettrait de cour-circuiter la sécurité des dossiers, ce qui est bien évidemment faux: il se comporte strictement de le même façon que n'importe quel gestionnaire de fichiers sur n'importe quel système d'exploitation. J'ai déjà ?p=1319181316 , prenant le temps de décortiquer tous les détails. Il est peut-être temps d'arréter de relancer ce sujet dans plusieurs fils différents.

Récupérer le contenu du flux en format texte (avec wget par exemple): $ wget -nv -O - http://www.tv-radio.com/station/fip_mp3/fip_mp3-128k.m3u #EXTM3U #EXTINF:fip_mp3 http://mp3.live.tv-radio.com/fip/all/fiphautdebit.mp3 2013-04-08 13:35:21 URL:http://gisv3.tv-radio.com/station/fip_mp3/fip_mp3-128k.m3u [78/78] -> "-" [1] Et utiliser l'URL contenu dans le flux ("http://mp3.live.tv-radio.com/fip/all/fiphautdebit.mp3" ici par exemple) à la place.

Eviter notepad: il crée des fichiers avec des fins de ligne de type dos/windows (crlf), notepad++ est plus approprié (mais ça ne gène pas Apache normalement) ansi vs utf8 ne change rien au fichier ici puisque il ne contient que des caractères non accentués. Sinon, pour savoir ou et pourquoi ça coince éditer le fichier "/usr/syno/apache/conf/httpd.conf-user" remplacer #ErrorLog /var/log/httpd-error-user.log ErrorLog /dev/null par ErrorLog /var/log/httpd-error-user.log #ErrorLog /dev/null Relancer apache comme cela: env - /usr/syno/etc/rc.d/S97apache-user.sh restart Recharcher l'url ".../doc" et aller voir quelle est l'erreur dans "/var/log/httpd-error-user.log"

Puisque ce n'est pas la faute du script, faudrait poster dans un autre fil, sinon tes questions risquent de passer inaperçues Celui-ci par exemple:

Essayer de désactiver provisoirement le script et de faire des enregistrement avec l'EPG standard pour vérifier si ça vient du script (ce qui m'étonnerait) ou pas.

Le compte 'admin' ne doit pas être utilisé en connexion ligne de commande, utiliser root a la place.

Tu penses que son NAS s'est *déja* fait pirater?

Ben tu avais un dossier "indexdb" dans /tmp qui bouffait toute la place de la partition, apparu fin février sans doute suite a un composant DSM ou autre parti en vrille. le "rm" l'a supprimé et ton problème est résolu. Maintenant, savoir ce qu'il s'est passé il y plus d'un mois sur ton NAS...

Bof, une appli qui part en vrille sera toujours capable de finir par remplir /tmp, quelque soit sa taille.

On parle toujours de "/tmp" là?

Je reconnais que cela ne donne pas beaucoup d'informations pour prendre une décision Le 213+ sera quand meme plus réactif niveau CPU, la question a te poser est si tu as vraiment besoin des 4 baies je pense. Le 213+, avec une config 2 disques non RAID, le 2eme volume pour les backups du premier (et d'eventuels clients PC) devrait répondre mieux a tes specs je pense.

Sans rien faire, alors que "/tmp/indexdb" était là depuis le 28 février? Ça tient du miracle absolu Dans quel but? Tu es jaloux de Pluton qui en a un plus gros, c'est ça? L'important c'est pas la taille tu sais, hein...

Comparatif non mais la comparaison reste possible:http://www.synology.com/products/compare_spec.php?lang=fre&product_id_list=111,109#compare_show_top

Que veux-tu dire par ça?

Non, c'est pareil pour moi, meme taille, jamais eu de probleme de ce coté. Bigre, tu n'y vas pas de main morte pour un simple /tmp plein!

Utiliser le compte "root" (meme mot de passe qu'admin)

Tu aurais gagné du temps en commençant par le "rm -r" (ce qui aurait probablement rendu la reinstall inutile)

J'ai bien l'impression qu'il n'y a pas eu de formatage de la partition système.

J'ai ajouté une piste de solution à mon message entre temps

Bon, reste a trouver quelle application tu as pu installer qui créé ce volumineux répertoire "indexdb" **EDIT** Tous ces fichiers datent du meme moment le 28 février dernier, une merde a du se passer a ce moment la Je te conseille de faire un "rm -r /tmp/indexdb" suivi d'un reboot

Une recherche sur le forum t'aurait permis de trouver ceci:

Pour info, mon /tmp fait la même taille (59140 Kb) Si il est plein, faut commencer par aller voir ce qui le remplit non? Je commencerai par quelque chose du genre de: find /tmp -size +10k | xargs ls -ldh

Ma pierre à l'édifice:

A ta place je tenterai le reset