/system/xbin/sh hohe CPU-Auslastung

Question

/system/xbin/sh hohe CPU-Auslastung

Software
Prozesse
Prozessor
4.1-jelly-bean
motorola-droid-razr

Fremde Schleife

Ich verwende OS Monitor, um die CPU-Auslastung zu überprüfen, da ich in letzter Zeit einen drastischen Leistungsabfall festgestellt habe. Die App zeigt, dass system/xbin/shsie zwischen 10 % und 70 % der CPU verbraucht. Dies geschieht ständig, der Prozess hört nie auf, ganz oben in der Liste zu erscheinen. Ich habe zwei Fragen:

Was ist system/xbin/sh?
Was könnte dazu führen, dass es so viel CPU auslastet?
Gibt es eine Möglichkeit zu verfolgen, welche Apps Anrufe tätigen system/xbin/sh?

Mehr Info:

Android-Version: 4.1.2
Telefon: Motorola DROID RAZR MAXX HD
ROM: Droid Nexesque v3.8 (AOSP-basiertes ROM) (über Safestrap)
Verwurzelt: ja
kein Antivirus oder ähnliches läuft

adb shell topAusgang:

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

adb shell psAusgang:

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

cat /proc/<pid>/cmdlineAusgang:

"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

/system/etc/init.d.loaderInhalt:

#!/system/xbin/sh
############# ############# #############
# init.d.loader by puppet13th@xda
# Version 0.7 19 June 2012
# to run script in background append .bgrun to script name
# example : "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 "  creating init.d folder . . .">>$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 : running init.d scripts . . .">>$logfile
for script in /system/etc/init.d/*
do
    if [ -x $script ]
    then
    bgrun=`grep $bgrunsign $script`>/dev/null
        if [ $? = 0 ]
        then
        echo "  - running $script in background . . .">>$logfile
        /system/xbin/sh $script & >>$logfile 2>>$logfile
        else
        echo "  - running $script . . .">>$logfile
        /system/xbin/sh $script>>$logfile 2>>$logfile
        fi
    fi
done
echo " ">>$logfile
echo " * `date` * init.d.loader end . . .">>$logfile
echo " ">>$logfile

/system/bin/debuggerdInhalt:

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

Suchen /data/localnach Dingen, die andere Tools möglicherweise noch "einstecken init" könnten: Es gibt vier leere Ordner und eine Datei mit dem Namen RootToolsMounts. /data/local/RootToolsMountsInhalt:

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

Betrachtet man /data/init.d.loader.log(~50 MB Datei), führt es die init.dSkripte ungefähr alle 10 Sekunden aus. Ich bin mit den zugrunde liegenden Komponenten von Android nicht allzu vertraut, daher bin ich mir nicht sicher, ob dies viel ist oder nicht. Die beiden Skripte darin /system/etc/init.d./sind init.d.loader.testund minfree.

/data/init.d.loader.logInhalt:

Die Protokolldatei wird mit diesen Einträgen gefüllt, die sich alle 10-12 Sekunden wiederholen

...
* Sun Feb 23 18:46:09 CST 2014 * init.d.loader
start...
i: running init.d scripts...
 - running /system/etc/init.d/init.d.loader.test...
 - running /system/etc/init.d/minfree...
* Sun Feb 23 18:46:09 CST 2014 * init.d.loader
end...
* Sun Feb 23 18:46:20 CST 2014 * init.d.loader
start...
i: running init.d scripts...
 - running /system/etc/init.d/init.d.loader.test...
 - running /system/etc/init.d/minfree...
* Sun Feb 23 18:46:20 CST 2014 * init.d.loader
end...
...

init.d.loader.testInhalt:

#!/system/xbin/sh
# init.d.loader tester
# check /data/init.d.loader.test
echo init.d.loader test >/data/init.d.loader.test

minfreeInhalt:

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

t0mm13b

PS: Hast du das gelesen

Fremde Schleife

@ t0mm13b Ich habe das gelesen, aber das scheint meinem Problem nicht zu helfen. Ich habe die psund topAusgänge für hinzugefügt /system/xbin/sh. Ich bin mir nicht sicher, ob dies helfen wird. Wenn das nicht hilft, werde ich wahrscheinlich nur das ROM löschen und von vorne beginnen. Es wird einfacher sein, als es App für App einzugrenzen.

Lüge Ryan

Es scheint, als ob dieses Skript in eine Endlosschleife oder ähnliches gerät. Können Sie den Inhalt der Protokolldatei des Skripts überprüfen: /data/init.d.loader.log und in den nächsten fünf Minuten beobachten, ob sich die Protokolldatei ändert oder in sie geschrieben wird?

Izzy

Für das, was das Skript tun soll, sollte es IMHO nur einmal beim Booten ausgeführt werden. Übrigens: Das /data/local/RootToolsMountssieht fstabfür mich nach einer Form von aus (macht hier aber definitiv keinen Ärger).

Lüge Ryan

@StrangerLoop: Kommt Ihr ROM mit busybox, wenn ja, können Sie den tail <filename>Befehl verwenden, um die letzten paar Zeilen in der Protokolldatei zu überprüfen, etwa fünfzehn Zeilen sollten vorerst ausreichen. Tail-Befehl:tail -n 15 /data/init.d.loader.log

t0mm13b

Aus dem Skript sieht das sehr verdächtig aus, wenn ich Sie OP wäre, würde ich den Typen auf XDA ( puppet13th@xda ) verfolgen und genau herausfinden, warum es alle Skripte im etcVerzeichnis durchläuft und das System als wiederbeschreibbar neu einhängt ohne Ihr Wissen und deren Ausführung im Hintergrund. Meine Schlussfolgerung aus dem Lesen des oben Gesagten ist, dass dies ein falsches Skript als Teil vielleicht eines Rooting-Prozesses ist, das durchgerutscht ist, wenn man sich /proc/pid/cmdlineLevel 2 ansieht, ist dies besorgniserregend inti.d.loader(war dies eingefügt oder ein Tippfehler?). Das ist unerhört.

Fremde Schleife

@t0mm13b Definitiv ein Tippfehler, es sollte lauten init.d.loader. Ich habe den Entwickler des ROM auf droidrzr.com kontaktiert (der Thread auf dieser Seite ist derjenige, der vom Entwickler aktualisiert wird). Ich werde auch versuchen, puppet13th auf xda zu bekommen.

t0mm13b

Gut, dass es dann ein Tippfehler ist... :)

Lüge Ryan

Meine aktuelle Vermutung ist, dass das Skript viel CPU-Zeit in Anspruch genommen hat, da es eine sehr ineffiziente Methode zur Berechnung der Protokolldateilänge verwendet, nämlich die gesamte Protokolldatei in den Speicher zu lesen und zu verwenden length. Dies sollte kein großes Problem sein, wenn die Protokolldatei klein ist, aber da Sie sagten, dass die aktuelle Größe der Protokolldatei mehr als 50 MB beträgt, zeigt dies, dass die Protokolldatei nicht richtig gekürzt wird. Ein weiteres besorgniserregendes Problem ist, dass Init-Skripte nur einmal beim Start ausgeführt werden sollen, dieses Skript jedoch offensichtlich regelmäßig ausgeführt wird.

Lüge Ryan

Wenn meine Vermutung richtig ist, können Sie dies möglicherweise vorübergehend beheben, indem Sie die Protokolldatei löschen, aber schließlich tritt die Verlangsamung erneut auf, wenn die Protokolldatei wieder gefüllt wird. Überprüfen Sie, ob Sie die neueste Version Ihres ROM haben, vielleicht ist es in der neuesten Version behoben? Andernfalls müssen Sie, wenn es sich um ein nicht gewartetes ROM handelt, einen Weg finden, das Skript zu reparieren.

Fremde Schleife

@LieRyan Du hattest Recht! Das hat das Problem vorerst behoben, aber wie Sie sagten, wird es mit der Zeit wieder auftreten. Ich bin leider auf der neuesten Version des ROM. Ich werde mich mit dem ROM-Entwickler und dem Entwickler, der geschrieben hat, in Verbindung setzen init.d.loader. Danke für die Hilfe aller. Ich schätze es!

Antworten (2)

/system/xbin/sh hohe CPU-Auslastung

@ t0mm13b Ich habe das gelesen, aber das scheint meinem Problem nicht zu helfen. Ich habe die psund topAusgänge für hinzugefügt /system/xbin/sh. Ich bin mir nicht sicher, ob dies helfen wird. Wenn das nicht hilft, werde ich wahrscheinlich nur das ROM löschen und von vorne beginnen. Es wird einfacher sein, als es App für App einzugrenzen.
Es scheint, als ob dieses Skript in eine Endlosschleife oder ähnliches gerät. Können Sie den Inhalt der Protokolldatei des Skripts überprüfen: /data/init.d.loader.log und in den nächsten fünf Minuten beobachten, ob sich die Protokolldatei ändert oder in sie geschrieben wird?
Für das, was das Skript tun soll, sollte es IMHO nur einmal beim Booten ausgeführt werden. Übrigens: Das /data/local/RootToolsMountssieht fstabfür mich nach einer Form von aus (macht hier aber definitiv keinen Ärger).
@StrangerLoop: Kommt Ihr ROM mit busybox, wenn ja, können Sie den tail <filename>Befehl verwenden, um die letzten paar Zeilen in der Protokolldatei zu überprüfen, etwa fünfzehn Zeilen sollten vorerst ausreichen. Tail-Befehl:tail -n 15 /data/init.d.loader.log
Aus dem Skript sieht das sehr verdächtig aus, wenn ich Sie OP wäre, würde ich den Typen auf XDA ( puppet13th@xda ) verfolgen und genau herausfinden, warum es alle Skripte im etcVerzeichnis durchläuft und das System als wiederbeschreibbar neu einhängt ohne Ihr Wissen und deren Ausführung im Hintergrund. Meine Schlussfolgerung aus dem Lesen des oben Gesagten ist, dass dies ein falsches Skript als Teil vielleicht eines Rooting-Prozesses ist, das durchgerutscht ist, wenn man sich /proc/pid/cmdlineLevel 2 ansieht, ist dies besorgniserregend inti.d.loader(war dies eingefügt oder ein Tippfehler?). Das ist unerhört.
@t0mm13b Definitiv ein Tippfehler, es sollte lauten init.d.loader. Ich habe den Entwickler des ROM auf droidrzr.com kontaktiert (der Thread auf dieser Seite ist derjenige, der vom Entwickler aktualisiert wird). Ich werde auch versuchen, puppet13th auf xda zu bekommen.
Meine aktuelle Vermutung ist, dass das Skript viel CPU-Zeit in Anspruch genommen hat, da es eine sehr ineffiziente Methode zur Berechnung der Protokolldateilänge verwendet, nämlich die gesamte Protokolldatei in den Speicher zu lesen und zu verwenden length. Dies sollte kein großes Problem sein, wenn die Protokolldatei klein ist, aber da Sie sagten, dass die aktuelle Größe der Protokolldatei mehr als 50 MB beträgt, zeigt dies, dass die Protokolldatei nicht richtig gekürzt wird. Ein weiteres besorgniserregendes Problem ist, dass Init-Skripte nur einmal beim Start ausgeführt werden sollen, dieses Skript jedoch offensichtlich regelmäßig ausgeführt wird.
Wenn meine Vermutung richtig ist, können Sie dies möglicherweise vorübergehend beheben, indem Sie die Protokolldatei löschen, aber schließlich tritt die Verlangsamung erneut auf, wenn die Protokolldatei wieder gefüllt wird. Überprüfen Sie, ob Sie die neueste Version Ihres ROM haben, vielleicht ist es in der neuesten Version behoben? Andernfalls müssen Sie, wenn es sich um ein nicht gewartetes ROM handelt, einen Weg finden, das Skript zu reparieren.
@LieRyan Du hattest Recht! Das hat das Problem vorerst behoben, aber wie Sie sagten, wird es mit der Zeit wieder auftreten. Ich bin leider auf der neuesten Version des ROM. Ich werde mich mit dem ROM-Entwickler und dem Entwickler, der geschrieben hat, in Verbindung setzen init.d.loader. Danke für die Hilfe aller. Ich schätze es!

Lüge Ryan · Answer 1

Meine aktuelle Vermutung ist, dass das Skript viel CPU-Zeit in Anspruch genommen hat, da es eine sehr ineffiziente Methode zur Berechnung der Protokolldateilänge verwendet, nämlich die gesamte Protokolldatei in den Speicher zu lesen und zu verwenden length. Dies sollte kein großes Problem sein, wenn die Protokolldatei klein ist, aber da Sie sagten, dass die aktuelle Größe der Protokolldatei mehr als 50 MB beträgt, zeigt dies, dass die Protokolldatei nicht richtig gekürzt wird. Ein weiteres besorgniserregendes Problem ist, dass Init-Skripte nur einmal beim Start ausgeführt werden sollen, dieses Skript jedoch offensichtlich regelmäßig ausgeführt wird.

Wenn meine Vermutung richtig ist, können Sie dies möglicherweise vorübergehend beheben, indem Sie die Protokolldatei löschen, aber schließlich tritt die Verlangsamung erneut auf, wenn die Protokolldatei wieder gefüllt wird. Überprüfen Sie, ob Sie die neueste Version Ihres ROM haben, vielleicht ist es in der neuesten Version behoben? Andernfalls müssen Sie, wenn es sich um ein nicht gewartetes ROM handelt, einen Weg finden, das Skript zu reparieren.

sîXXXÏs6 · Answer 2

Ich vermute nur , aber haben Sie versucht, die Größe des Protokollpuffers zu verringern? Die Funktion ist in den Entwickleroptionen aufgeführt >Settings>Developer Options>Logger Buffer Size

Das Community-Wiki ist nicht für Antworten wie diese gedacht, sondern für "kanonische" Antworten, zu denen die gesamte Community beitragen sollte.

/system/xbin/sh hohe CPU-Auslastung

Fremde Schleife

t0mm13b

Fremde Schleife

Lüge Ryan

Izzy

Lüge Ryan

t0mm13b

Fremde Schleife

t0mm13b

Lüge Ryan

Lüge Ryan

Fremde Schleife

Antworten (2)

Lüge Ryan

sîXXXÏs6

Dan Hulme

"Hintergrunddaten einschränken" mit Jelly Bean auf dem ASUS-Tablet tf300t

So finden Sie Dateien, die sich auf einen Prozess beziehen

Prozesse automatisch beenden, die über x % CPU kommen

Inoffizielle Roms 4.0 oder 4.1 für Galaxy Note? [Duplikat]

Wie kann ich Fotos von meinem Android (4.1) auf Picasa hochladen, ohne die Größe auf eine Auflösung von 2048 zu ändern?

Apple MacBook Pro Akku vs. Prozessor

Warum geht die Verwendung von Hintergrunddaten durch Google Keep plötzlich durch die Decke?

Können wir PowerPC-Macs auf OS X 10.7 aktualisieren, nachdem 10.8 herausgekommen ist?

Tasker doppelte WiFi-Aktivierung mit 'oder'-Anweisung

Externe SD-Karte kann auf CM11 nicht mehr gelesen werden