Service, minidlna
Bonjour,
J'ai installé minidlna 1.0.20 afin de partager mes fichier avec mon lecteur bluray. J'ai configuré le fichier .conf comme dans beaucoup de tuto. minidlna ne fonctionne pas correctement, il a du mal à se lancer, à s'arrêter. régulièrement, il freeze, sans que je sache pourquoi. Voici ce que me donne le service après le boot de la machine :
Si vous pouviez m'aider à comprendre ce charabia et pourquoi ça ne fonctionne pas correctement.
Si je le relance manuellement, il fonctionne un certain temps avant de se bloquer. Le blocage semble du au fait qu'un client essai de lire les dossiers (impossible d'aller jusqu'à ouvrir un fichier)
D'ailleur si quelqu'un connais un programme ligne de commande pour tester le serveur, ça me ferai gagner du temps.
Merci
J'ai installé minidlna 1.0.20 afin de partager mes fichier avec mon lecteur bluray. J'ai configuré le fichier .conf comme dans beaucoup de tuto. minidlna ne fonctionne pas correctement, il a du mal à se lancer, à s'arrêter. régulièrement, il freeze, sans que je sache pourquoi. Voici ce que me donne le service après le boot de la machine :
# service minidlna status
minidlna.service - LSB: DLNA media server
Loaded: loaded (/etc/rc.d/init.d/minidlna)
Active: failed sunce (etc.)
Process: 2355 ExecStart=/etc/rc.d/init.d/minidlna start (code=exited, status=1/FAILURE)
CGroup: name=systemd:/system/minidlna.service
Si vous pouviez m'aider à comprendre ce charabia et pourquoi ça ne fonctionne pas correctement.
Si je le relance manuellement, il fonctionne un certain temps avant de se bloquer. Le blocage semble du au fait qu'un client essai de lire les dossiers (impossible d'aller jusqu'à ouvrir un fichier)
D'ailleur si quelqu'un connais un programme ligne de commande pour tester le serveur, ça me ferai gagner du temps.
Merci
10 réponses
Ce que tu nous as reporté n'aide pas vraiment, on voit juste que le processus (dont le PID était 2355 à ce moment là, invoqué via /etc/rc.d/init.d/minidlna start) a planté en retournant le code d'erreur 1.
En général quand un service est bien fait, il écrit des informations dans un fichier de log, typiquement dans /var/log. Si un tel fichier est présent ça nous sera sans doute plus utile...
Bonne chance
En général quand un service est bien fait, il écrit des informations dans un fichier de log, typiquement dans /var/log. Si un tel fichier est présent ça nous sera sans doute plus utile...
Bonne chance
Merci de ta réponse, en effet, il y a un fichier log, mais il n'aide pas trop, c'est pour ça que je n'en ai pas parlé :
/var/log/minidlna.log
à 9h18, c'est le démarrage manuel et mon PC s'est rebooter vers 8h50, c'est a dire que les erreurs de log apparaissent à l'extinction et qu'il n'y a pas de log au boot :-(
/var/log/minidlna.log
... [2012/10/19 08:48:46] minidlna.c:153: warn: received signal 15, good-bye [2012/10/19 08:48:47] minidlna.c:1244: error: Failed to remove pidfile /var/run/minidlna.pid: Aucun fichier ou dossier de ce type [2012/10/19 09:18:51] minidlna.c:862: warn: Starting MiniDLNA version 1.0.20 [SQLite 3.7.13]. ...
à 9h18, c'est le démarrage manuel et mon PC s'est rebooter vers 8h50, c'est a dire que les erreurs de log apparaissent à l'extinction et qu'il n'y a pas de log au boot :-(
Après quelques recherches, il semblerai que ça puisse être parceque le service est démarré après le réseau.
Comment démarrer le service après le réseau ? Je m'y paume beaucoup dans les rc*.d
La vrai soumission c'est quand les esclaves s'inquiètent du cours du coton.
Char Snipeur
Comment démarrer le service après le réseau ? Je m'y paume beaucoup dans les rc*.d
La vrai soumission c'est quand les esclaves s'inquiètent du cours du coton.
Char Snipeur
Pour commencer le log indique que tu as reçu un signal 15 (SIG TERM) ce qui veut dire que minidlna a été stoppé explicitement. En général c'est soit quand tu éteins ton linux, soit quand tu stoppes explicitement le service (service mon_service stop, anciennement /etc/init.d/mon_service stop).
Est-ce bien toi qui le stoppait explicitement ?
Le fait ensuite que dans les logs, minidlna n'arrive pas à supprimer le fichier /var/run/minidlna.pid laisse entendre que ce fichier n'a pas été créé (or il est sensé être créé au lancement du démon, et s'il n'est pas créé, c'est sans doute que le démon n'a pas été lancé). De plus ce fichier laisse entendre que ce programme a les droits en écriture pour écrire ce fichier.
D'où ces questions :
- lances-tu bien ce programme en root (ou via sudo) ?
- le lances tu via son script de lancement ?
(pour le stopper, remplace start par stop).
Normalement si le fichier /etc/init.d/minidlna est sensé avoir les bonnes dépendances pour être instancié au bon moment (en supposant que tu aies une distribution récente utilisant comme par exemple upstart).
Par rapport aux rc*.d, tu n'es pas sensé aller trafiquer dedans.
- Chaque répertoire correspond à un runlevel (cf /etc/inittab, par exemple 0 correspond à l'arrêt, 1 au mode single, 2 au mode normal et 6 au reboot sous debian).
- Ces liens symboliques sont créés par update-rc.d qui se charge de tout. En général tu n'invoques pas toi-même cette commande, c'est le paquet qui te permet d'installer le logiciel qui s'en charge. Donc tu n'es pas non plus sensé invoquer cette commande, sauf si ce service a été installé autrement que via un paquet debian.
Bonne chance
Est-ce bien toi qui le stoppait explicitement ?
Le fait ensuite que dans les logs, minidlna n'arrive pas à supprimer le fichier /var/run/minidlna.pid laisse entendre que ce fichier n'a pas été créé (or il est sensé être créé au lancement du démon, et s'il n'est pas créé, c'est sans doute que le démon n'a pas été lancé). De plus ce fichier laisse entendre que ce programme a les droits en écriture pour écrire ce fichier.
D'où ces questions :
- lances-tu bien ce programme en root (ou via sudo) ?
- le lances tu via son script de lancement ?
sudo service minidlna start
(pour le stopper, remplace start par stop).
Normalement si le fichier /etc/init.d/minidlna est sensé avoir les bonnes dépendances pour être instancié au bon moment (en supposant que tu aies une distribution récente utilisant comme par exemple upstart).
Par rapport aux rc*.d, tu n'es pas sensé aller trafiquer dedans.
- Chaque répertoire correspond à un runlevel (cf /etc/inittab, par exemple 0 correspond à l'arrêt, 1 au mode single, 2 au mode normal et 6 au reboot sous debian).
- Ces liens symboliques sont créés par update-rc.d qui se charge de tout. En général tu n'invoques pas toi-même cette commande, c'est le paquet qui te permet d'installer le logiciel qui s'en charge. Donc tu n'es pas non plus sensé invoquer cette commande, sauf si ce service a été installé autrement que via un paquet debian.
Bonne chance
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Ok alors une partie de ce que j'ai dit ne colle pas car il y avait des éléments spécifiques à debian et les distributions qui en dérivent. Pour gérer les services sous mandriva tu peux te référer à cette page :
http://wiki.mandriva.com/
Mais si minidlna ne se lance pas, ça ne t'emmènera pas plus loin. Que se passe-til si tu le le lances à la main (cf commande invoquée dans /etc/init.d/minidlna) ? Est-ce qu'un message d'erreur apparaît ? Est ce que le processus tourne ?
Bonne chance
http://wiki.mandriva.com/
Mais si minidlna ne se lance pas, ça ne t'emmènera pas plus loin. Que se passe-til si tu le le lances à la main (cf commande invoquée dans /etc/init.d/minidlna) ? Est-ce qu'un message d'erreur apparaît ? Est ce que le processus tourne ?
ps aux | grep minidlna
Bonne chance
Si je le lance explicitement (après boot complet) il tourne bien. C'est pour ça que je voulais changer l'ordre de démarrage des service, pour le mettre vers la fin. L'une des causes possible c'est que les répertoires que je partage sont dans /mnt (ntfs windows) qui semble monté assez tardivement.
Donc à par ce "fail" dans boot.log, pas beaucoup d'aide. J'ai mis le serveur à jour dernièrement, je verrai si il démarre correctement au prochain redémarrage.
Donc à par ce "fail" dans boot.log, pas beaucoup d'aide. J'ai mis le serveur à jour dernièrement, je verrai si il démarre correctement au prochain redémarrage.
Je ne vois pas trop en quoi le fait de monter une partition windows peut ou non être bloquant dans le cas présent.
Mais sinon il suffit de renommer le lien symbolique créé dans /etc/rc*.d et lui mettre un numéro de séquence plus élevé (valeur entière indiquée entre "S" et le nom du démon, par exemple "03" dans "S03bluetooth").
Bonne chance
Mais sinon il suffit de renommer le lien symbolique créé dans /etc/rc*.d et lui mettre un numéro de séquence plus élevé (valeur entière indiquée entre "S" et le nom du démon, par exemple "03" dans "S03bluetooth").
Bonne chance
Bon, ça ne fonctionne toujours pas, je l'ai mis en S99, seul wine se charge en 99, tout les autres ont une priorité supérieure.
En cherchant, j'ai trouvé une astuce d'ajouter "wait 5" au script de démarrage, mais ça ne fonctionne toujours pas.
En continuant mes recherches, j'ai remarqué que mon système utilise systemd et non "init" pour le démarrage. ça viens peut être de là, si toutes les modifications que j'ai fait dans rc.d ne sont pas lu...
Par contre, je n'ai pas compris comment configurer les priorités avec systemd.
En cherchant, j'ai trouvé une astuce d'ajouter "wait 5" au script de démarrage, mais ça ne fonctionne toujours pas.
En continuant mes recherches, j'ai remarqué que mon système utilise systemd et non "init" pour le démarrage. ça viens peut être de là, si toutes les modifications que j'ai fait dans rc.d ne sont pas lu...
Par contre, je n'ai pas compris comment configurer les priorités avec systemd.
systemd ? Mmmmh pour moi son utilise sysv-init soit upstart mais je n'ai jamais entendu parler de systemd... Par ailleurs sous debian (ou distribution dérivée) normalement tu n'as pas à créer ces liens à la main, normalement tout se fait plus ou moins automatiquement avec la commande update-rc.d...
oui, mais je suis sous mandriva, dérivé de fedora.
sysv-init, connais pas. systemd a le PID 1, et je l'ai trouvé sur internet.
Tout se fait automatiquement, en effet, SAUF pour le serveur minidlna. Quand j'essai de le configurer avec systemctl, il me dit qu'il me renvoie à chkconfig car le service n'est pas natif.
sysv-init, connais pas. systemd a le PID 1, et je l'ai trouvé sur internet.
Tout se fait automatiquement, en effet, SAUF pour le serveur minidlna. Quand j'essai de le configurer avec systemctl, il me dit qu'il me renvoie à chkconfig car le service n'est pas natif.