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 :
- Qu'est-ce que
system/xbin/sh
? - Qu'est-ce qui pourrait causer une utilisation aussi importante du CPU ?
- 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
ettop
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.
1 votes
Pour ce que le script est censé faire, il ne devrait s'exécuter qu'une seule fois au démarrage à mon avis. Au fait: le
/data/local/RootToolsMounts
ressemble à une sorte defstab
pour moi (mais ne cause définitivement pas de problème ici).0 votes
@StrangerLoop: Votre ROM est-elle livrée avec busybox, si c'est le cas, pouvez-vous utiliser la commande
tail
pour vérifier les dernières lignes du fichier journal, environ quinze lignes devraient suffire pour le moment. Commande Tail :tail -n 15 /data/init.d.loader.log
0 votes
À partir du script, cela semble très suspect. Si j'étais à votre place, OP, je suivrais le type sur XDA (puppet13th@xda) et je saurais exactement pourquoi il boucle sur tous les scripts du répertoire
etc
, remontant le système en réécriture sans votre connaissance et les exécutant en arrière-plan. Ma conclusion à la lecture ci-dessus est que c'est un script frauduleux peut-être dans le cadre d'un processus de rootage, qui a réussi à passer à travers en regardant/proc/pid/cmdline
, le niveau 2 est un problème,inti.d.loader
(cette portion a-t-elle été copiée ou est-ce une faute de frappe?) C'est inouï.0 votes
@t0mm13b Certainement une faute de frappe, cela devrait lire
init.d.loader
. J'ai contacté le développeur de la ROM sur droidrzr.com (le sujet sur ce site est celui qui est mis à jour par le développeur). Je vais également essayer de contacter puppet13th sur xda.0 votes
Heureux que ce soit une faute de frappe alors... :)
1 votes
Mon estimation actuelle est que le script a pris beaucoup de temps CPU car il utilise une façon 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 avoir posé 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 50 Mo, cela montre que le fichier journal n'est pas correctement coupé. Un autre problème préoccupant est que les scripts d'initialisation ne sont censés s'exécuter qu'une seule fois au démarrage, mais ce script est évidemment exécuté périodiquement.0 votes
Si ma supposition est correct, vous pourrez peut-être corriger temporairement cela en supprimant le fichier journal, mais éventuellement le ralentissement se produira à nouveau lorsque le fichier journal sera rempli à nouveau. 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, s'il s'agit d'une ROM non maintenue, vous devrez trouver un moyen de corriger le script.
0 votes
@LieRyan Vous aviez raison! Cela a corrigé le problème pour le moment, mais comme vous l'avez dit, il va réapparaître avec le temps. Je suis sur la dernière version de la ROM, malheureusement. Je vais contacter le développeur de la ROM et le développeur qui a écrit
init.d.loader
. Merci pour l'aide de tout le monde. Je l'apprécie!