2 votes

/système/xbin/sh une utilisation élevée du processeur

Je utilise OS Monitor pour surveiller l'utilisation du CPU car j'ai remarqué une diminution drastique des performances ces derniers temps. L'application montre que system/xbin/sh consomme entre 10% et 70% du CPU. Cela se produit constamment, le processus n'arrête jamais de figurer en tête de la liste. J'ai deux questions :

  1. Qu'est-ce que system/xbin/sh ?
  2. Qu'est-ce qui pourrait causer une utilisation aussi importante du CPU ?
  3. Y a-t-il un moyen de suivre quelles applications font des appels à system/xbin/sh ?

Plus d'informations :

  • Version Android : 4.1.2
  • Téléphone : Motorola DROID RAZR MAXX HD
  • ROM : Droid Nexesque v3.8 (ROM basée sur AOSP) (via safestrap)
  • Rooté : oui
  • Pas d'antivirus en cours d'exécution ou similaire

Sortie de adb shell top :

PID PR CPU% S  #THR     VSS     RSS PCY UID      Name
6214  0  97% R     1 182528K  92452K     root     /system/xbin/sh
...
6211  0   0% S     1   1428K    448K     root     /system/xbin/sh
6212  0   0% S     1  53500K  52596K     root     /system/xbin/sh    
...

Sortie de adb shell ps :

USER     PID   PPID  VSIZE  RSS     WCHAN    PC         NAME
root      1     0     544    404   ffffffff 00000000 S /init
...
root      6211  1     1428   448   ffffffff 00000000 S /system/xbin/sh
root      6212  6211  53500  52596 ffffffff 00000000 S /system/xbin/sh
root      6214  6212  293976 214156 ffffffff 00000000 R /system/xbin/sh
...

Sortie de cat /proc//cmdline :

"level 1" process: /system/xbin/sh /system/bin/debuggerd
"level 2" process: /system/xbin/sh /system/etc/init.d.loader
"level 3" process: /system/xbin/sh /system/etc/init.d.loader

Contenu de /system/etc/init.d.loader :

#!/system/xbin/sh
############# ############# #############
# init.d.loader par puppet13th@xda
# Version 0.7 19 June 2012
# pour exécuter le script en arrière-plan ajouter .bgrun au nom du script
# exemple : "myscript.bgrun"
# ############# ############# #############
logfile=/data/init.d.loader.log
loglength=65536
bgrunsign='.bgrun'
if [ -f $logfile ]
    then
    log=`cat $logfile`
    currentloglength=`length "$log"`
    if [ $currentloglength -gt $loglength ]
    then
    rm -f $logfile  fi
fi
echo " * `date` * init.d.loader start . . .">>$logfile
echo " ">>$logfile
if [ ! -d /system/etc/init.d ]
    then
    echo "  création du dossier init.d . . .">>$logfile
    mount -o remount rw /system >>$logfile 2>>$logfile
    if [ -f /system/etc/init.d ]
        then
        rm -f /system/etc/init.d >>$logfile 2>>$logfile
    fi
    mkdir /system/etc/init.d >>$logfile 2>>$logfile
mount -o remount ro /system >>$logfile 2>>$logfile
fi
echo " ">>$logfile
echo " i : exécution des scripts init.d . . .">>$logfile
for script in /system/etc/init.d/*
do
    if [ -x $script ]
    then
    bgrun=`grep $bgrunsign $script`>/dev/null
        if [ $? = 0 ]
        then
        echo "  - exécution de $script en arrière-plan . . .">>$logfile
        /system/xbin/sh $script & >>$logfile 2>>$logfile
        else
        echo "  - exécution de $script . . .">>$logfile
        /system/xbin/sh $script>>$logfile 2>>$logfile
        fi
    fi
done
echo " ">>$logfile
echo " * `date` * fin du init.d.loader . . .">>$logfile
echo " ">>$logfile

Contenu de /system/bin/debuggerd :

#!/system/xbin/sh
# init.d.loader
/system/etc/init.d.loader
/system/bin/debuggerd.bin

Vérifier dans /data/local pour voir ce que d'autres outils auraient pu laisser à "brancher dans init": Il y a quatre dossiers vides et un fichier nommé RootToolsMounts. Contenu de /data/local/RootToolsMounts :

rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
/dev/block/platform/msm_sdcc.1/by-name/userdataorig /datamedia ext4 rw,relatime,user_xattr,barrier=1,data=ordered 0 0
/dev/block/platform/msm_sdcc.1/by-name/userdataorig /ss ext4 rw,relatime,user_xattr,barrier=1,data=ordered 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,relatime,user_xattr,barrier=1,data=ordered 0 0
/dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4 rw,nosuid,nodev,noatime,nodiratime,user_xattr,barrier=0,data=ordered,noauto_da_alloc,discard 0 0
/dev/block/platform/msm_sdcc.1/by-name/cache /cache ext4 rw,nosuid,nodev,noatime,nodiratime,user_xattr,barrier=1,data=ordered 0 0
/dev/block/platform/msm_sdcc.1/by-name/persist /persist ext4 rw,nosuid,nodev,relatime,user_xattr,barrier=1,data=ordered 0 0
/dev/block/platform/msm_sdcc.1/by-name/modem /firmware ext4 ro,nosuid,nodev,relatime,user_xattr,barrier=1,data=ordered 0 0
/dev/block/platform/msm_sdcc.1/by-name/pds /pds ext3 rw,nosuid,noexec,relatime,barrier=0,data=writeback 0 0
/dev/fuse /storage/sdcard0 fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
/dev/block/vold/179:97 /storage/sdcard1 vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0

En examinant /data/init.d.loader.log (fichier d'environ 50 Mo), il exéctute les scripts init.d environ toutes les 10 secondes. Je ne suis pas très familier avec les composants sous-jacents d'Android, donc je ne suis pas sûr si c'est beaucoup ou non. Les deux scripts dans /system/etc/init.d/ sont init.d.loader.test et minfree.

Contenu de /data/init.d.loader.log :

Le fichier journal est rempli de ces entrées se répétant toutes les 10 à 12 secondes

...
* Sun Feb 23 18:46:09 CST 2014 * init.d.loader
démarrage...
i: exécution des scripts init.d...
 - exécution de /system/etc/init.d/init.d.loader.test...
 - exécution de /system/etc/init.d/minfree...
* Sun Feb 23 18:46:09 CST 2014 * init.d.loader
fin...
* Sun Feb 23 18:46:20 CST 2014 * init.d.loader
démarrage...
i: exécution des scripts init.d...
 - exécution de /system/etc/init.d/init.d.loader.test...
 - exécution de /system/etc/init.d/minfree...
* Sun Feb 23 18:46:20 CST 2014 * init.d.loader
fin...
...

Contenu de init.d.loader.test :

#!/system/xbin/sh
# testeur de init.d.loader
# vérifier /data/init.d.loader.test
echo test init.d.loader >/data/init.d.loader.test

Contenu de minfree :

#!/system/xbin/sh
echo "2469,4938,6584,33756,36971,40186" > /sys/module/lowmemorykiller/parameters/minfree

0 votes

PS : Avez-vous lu ceci

0 votes

@t0mm13b J'ai lu cela, mais cela ne semble pas aider mon problème. J'ai ajouté les sorties ps et top pour /system/xbin/sh. Je ne suis pas sûr si cela va aider. Si cela ne fonctionne pas, je vais probablement simplement effacer la ROM et recommencer. Ce sera plus facile que de chercher l'application par application.

1 votes

Il semble que ce script soit pris dans une boucle infinie ou quelque chose du genre. Pouvez-vous vérifier le contenu du fichier journal du script : /data/init.d.loader.log et l'observer pendant les cinq prochaines minutes pour voir si le fichier journal change ou s'il est en train d'être écrit.

2voto

Thej Points 655

Ma supposition actuelle est que le script a pris beaucoup de temps CPU parce qu'il utilise une manière très inefficace de calculer la longueur du fichier journal, qui est de lire l'intégralité du fichier journal en mémoire et d'utiliser length. Cela ne devrait pas poser de problème si le fichier journal est petit, mais puisque vous avez dit que la taille actuelle du fichier journal est de plus de 50MB, cela montre que le fichier journal n'est pas correctement réduit. Un autre problème préoccupant est que les scripts d'initialisation sont censés s'exécuter une seule fois au démarrage, mais ce script est évidemment exécuté périodiquement.

Si ma supposition est correcte, vous pourrez peut-être résoudre temporairement ce problème en supprimant le fichier journal, mais éventuellement le ralentissement se produira à nouveau lorsque le fichier journal sera à nouveau rempli. Vérifiez si vous avez la dernière version de votre ROM, peut-être que le problème est résolu dans la dernière version ? Sinon, si c'est une ROM non maintenue, vous devrez trouver un moyen de corriger le script.

-1voto

sîXXXÏs6 Points 1

Je ne fais que DEVINER mais avez-vous essayé de réduire la taille du tampon de journal? La fonction est répertoriée dans les Options pour les développeurs >Paramètres>Options pour les développeurs>Taille du tampon de journal

0 votes

La communauté wiki n'est pas destinée à des réponses comme celle-ci, elle est destinée à des réponses "canoniques" auxquelles toute la communauté devrait contribuer.

androidalle.com

AndroidAlle est une communauté de androiders où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X