Aller au contenu

Synoaudiod Toujours Actif


CoolRaoul

Messages recommandés

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.

Lien vers le commentaire
Partager sur d’autres sites

  • 6 mois après...

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é par CoolRaoul
Lien vers le commentaire
Partager sur d’autres sites

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é par Fenrir
Lien vers le commentaire
Partager sur d’autres sites

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é par CoolRaoul
Lien vers le commentaire
Partager sur d’autres sites

  • 10 mois après...

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é par CoolRaoul
Lien vers le commentaire
Partager sur d’autres sites

  • 5 mois après...

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. :mrgreen:

Lien vers le commentaire
Partager sur d’autres sites

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à).

Lien vers le commentaire
Partager sur d’autres sites

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.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.