CoolRaoul Posté(e) le 29 novembre 2014 Partager Posté(e) le 29 novembre 2014 Depuis longtemps je me suis aperçu que synoaudiod (/var/packages/AudioStation/target/sbin/synoaudiod) consomme du CPU en permanence. Ce matin j'ai voulu en avoir le coeur net et décidé d'investiguer plus avant A l'aide de la commande "truss", cross compilée avec le SDK, j'ai pu observer ce comportement select(1024, [3], NULL, NULL, {0, 0}) = 0 (Timeout) gettimeofday({1417247511, 826053}, NULL) = 0 open("/dev/mixer7", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer6", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer5", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer4", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer3", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer2", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer1", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) gettimeofday({1417247511, 829573}, NULL) = 0 open("/tmp/AudioStation/player.list.json", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 8 fstat64(8, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40091000 write(8, "{"last_update":1417247511,"uuid:"..., 582) = 582 close( = 0 munmap(0x40091000, 4096) = 0 open("/dev/mixer7", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer6", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer5", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer4", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer3", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer2", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer1", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) nanosleep({0, 100000000}, NULL) = 0 et ca continue en boucle. Le plus étrange sont ces ouvertures/ecriture/fermeture frénétiques (10 fois par seconde!) dans "/tmp/AudioStation/player.list.json" Qui saurait me dire à quoi sert ce process et quels sont les conséquences de l'inhiber? J'aurais bien ouvert un ticket de support chez Syno, mais hélas j'ai un point de montage "/opt", et même si ce n'est pas du optware, sous ce prétexte, on me refuse toute aide tant que je n'ai pas effectué un reset usine de mon NAS. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
CoolRaoul Posté(e) le 30 mai 2015 Auteur Partager Posté(e) le 30 mai 2015 (modifié) Un an et demi plus tard, toujours pas de réponse et rien n'a changé J'espère qu'on ne me reprochera pas ce petit "up" Est-ce qu'une bonne âme ayant installé audiostation pourrait juste via la commande suivante: ls -l /tmp/AudioStation/player.list.json vérifier si chez lui aussi ce fichier est modifié en permanence (effectuer la commande à quelques moments d'intervalle pour constater si sa date de modification est constamment mise à jour) J'ai complètement désinstallé audiostation puis réinstallé sans que ça ne change rien. **EDIT** Solution de contournement en attendant mieux, je force proprement l’arrêt de synoaudiod en cron toutes les nuits: /var/packages/AudioStation/target/scripts/S96synoaudiod.sh stop (Et quand il est déjà arrêté c'est sans importance) Modifié le 30 mai 2015 par CoolRaoul 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Fenrir Posté(e) le 30 mai 2015 Partager Posté(e) le 30 mai 2015 (modifié) nas> ps | grep -i audio 13495 root 27112 S < /var/packages/AudioStation/target/sbin/synoaudiod 13504 root 79624 S < /var/packages/AudioStation/target/bin/pulseaudio --realtime=false 13524 root 13704 S < /var/packages/AudioStation/target/sbin/synorcd nas> ls -l /tmp/AudioStation/player.list.json -rw-r--r-- 1 root root 27 May 30 22:22 /tmp/AudioStation/player.list.json nas> ls -l /tmp/AudioStation/player.list.json -rw-r--r-- 1 root root 27 May 30 22:23 /tmp/AudioStation/player.list.json nas> ls -l /tmp/AudioStation/player.list.json -rw-r--r-- 1 root root 27 May 30 22:24 /tmp/AudioStation/player.list.json nas> stat /tmp/AudioStation/player.list.json File: "/tmp/AudioStation/player.list.json" Size: 27 Blocks: 8 IO Block: 4096 regular file Device: eh/14d Inode: 19589 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2015-05-25 23:06:52.000000000 Modify: 2015-05-30 22:25:32.000000000 Change: 2015-05-30 22:25:32.000000000 nas> top Mem: 914308K used, 100600K free, 0K shrd, 8656K buff, 568336K cached CPU: 0.0% usr 9.0% sys 0.0% nic 90.9% idle 0.0% io 0.0% irq 0.0% sirq en espérant que ça t'aide Modifié le 30 mai 2015 par Fenrir 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
CoolRaoul Posté(e) le 31 mai 2015 Auteur Partager Posté(e) le 31 mai 2015 (modifié) Le 30/5/2015 at 22:28, Fenrir a dit : en espérant que ça t'aide Merci, Donc il se confirme qu'il y a un défaut de conception dans AudioStation Parce qu'effectuer une séquence de ouverture/écriture/fermeture d'un fichier *10 fois par seconde* n'est vraiment pas raisonnable. En plus, vu que le process qui effectue l'opération est actif en permanence et le petit volume de données de ce fichier, suffirait de conserver l'info en mémoire et d'écrire qu'en cas de changements. Je pense en particulier à ceux qui (malgré nos conseils) choisissent d'activer l'hibernation: avec AudioStation qui tourne, il ne sont pas prés de la voir fonctionner non? Modifié le 24 avril 2016 par CoolRaoul 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
CoolRaoul Posté(e) le 23 avril 2016 Auteur Partager Posté(e) le 23 avril 2016 (modifié) A l'occasion d'un reboot suite update DSM je constate que ce problème est toujours présent! J'ai bien évidemment toujours mon job quotidien qui stoppe synaudiod donc pas de problème de mon coté. Mais je ne comprend pas à quoi peut bien servir ce service à l'activité débridée, sachant que bien qu'étant stoppé en permanence en ce qui me concerne, je n'ai jamais constaté de conséquence (en particulier DSaudio fonctionne sans problème). Modifié le 23 avril 2016 par CoolRaoul 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
CoolRaoul Posté(e) le 16 octobre 2016 Auteur Partager Posté(e) le 16 octobre 2016 UP désespéré... 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Mic13710 Posté(e) le 16 octobre 2016 Partager Posté(e) le 16 octobre 2016 Salut CoolRaoul, Je ne sais pas si ça peut t'aider, voici les mêmes commandes que Fenrir sur mon 214+ Bipbip> ps | grep -i audio 12532 root 80224 S < /var/packages/AudioStation/target/sbin/synoaudiod 12547 root 81444 S < /var/packages/AudioStation/target/bin/pulseaudio --r 12567 root 13288 S < /var/packages/AudioStation/target/sbin/synorcd 25779 root 4008 S grep -i audio Bipbip> ls -l /tmp/AudioStation/player.list.json -rw-r--r-- 1 root root 1005 Oct 16 19:00 /tmp/AudioStation/player.list.json Bipbip> ls -l /tmp/AudioStation/player.list.json -rw-r--r-- 1 root root 1005 Oct 16 19:01 /tmp/AudioStation/player.list.json Bipbip> ls -l /tmp/AudioStation/player.list.json -rw-r--r-- 1 root root 1005 Oct 16 19:02 /tmp/AudioStation/player.list.json Bipbip> stat /tmp/AudioStation/player.list.json File: "/tmp/AudioStation/player.list.json" Size: 1005 Blocks: 8 IO Block: 4096 regular file Device: fh/15d Inode: 15967 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2016-09-05 10:29:15.000000000 Modify: 2016-10-16 19:02:30.000000000 Change: 2016-10-16 19:02:30.000000000 Bipbip> top Mem: 1018780K used, 14976K free, 0K shrd, 46088K buff, 488200K cached CPU: 0.0% usr 4.5% sys 0.0% nic 95.4% idle 0.0% io 0.0% irq 0.0% sirq Je ne vois pas ce que je devrais voir donc je ne vois pas où il peut y avoir un problème. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Fenrir Posté(e) le 16 octobre 2016 Partager Posté(e) le 16 octobre 2016 Vu les "strings" présentes dans le binaire, j'ai l'impression que c'est un daemon à tout faire (pas très kiss), ça n'a donc rien de choquant qu'il tourne en permanence afin d'être à l'écoute des connexions/déconnexions des hauts parleur, d'un client DSAudio, d'un airplay, ... en gros c'est un ordonnanceur mal écrit. Pour ce qui est du fichier json, il est en mémoire (/tmp c'est du tmpfs). Enfin pour la consommation de ressources, chez moi c'est de l'ordre 2% de cpu, donc rien de méchant (même si ça reste bcp pour un daemon en sleep). Je n'ai pas de solution à te proposer autre que te le couper (ce que tu fais déjà). 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Rejoindre la conversation
Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.