Synoaudiod Toujours Actif

[CoolRaoul]

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.

[CoolRaoul]

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

[Fenrir]

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

[CoolRaoul]

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

[CoolRaoul]

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

[CoolRaoul]

UP désespéré... 

[Mic13710]

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.

[Fenrir]

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