Database Develop

[Q] Does OB Kernel support init.d ?

Referring to this post [LINK], i'd like to know if someone have experience or tried this script

Don't know about original firmware, but Quasar kernel inside Nova ROM does support init.d indeed. Knzo already initializes lowmemorykiller adj and minfree parameters in his init.d script to 0,3,5,7,14,15 and 1536,2048,6656,7168,7680,8192 accordingly. What exactly is affected is still a mystery to me but I'll intend to find it out. Same goes for VM parameters. This is all just some kind of low level tweaking and I'm sure there are threads in this forum explaining it. I'll look around and post a follow-up here if I'll find anything useful.
Concerning the script itself it really doesn't hurt to try it out and just keep using it if you feel the difference. If not - delete it.
I don't know what it is with me and short scripts, but you can ditch the conditional statements as these files are there without checking anyway. The following script does the same as Juwe11's original script. Added comments with current values. Keep in mind that first 2 parameters are set by Nova ROM.
Code:
#!/system/bin/sh
# values taken from Juwe11 script
echo "0,1,2,4,6,15" > /sys/module/lowmemorykiller/parameters/adj # 0,3,5,7,14,15
echo "2560,4096,6144,12288,14336,18432" > /sys/module/lowmemorykiller/parameters/minfree # 1536,2048,6656,7168,7680,8192
echo "10" > /proc/sys/vm/swappiness # 0
echo "50" > /proc/sys/vm/vfs_cache_pressure # 1
echo "3000" > /proc/sys/vm/dirty_expire_centisecs # 1000
echo "500" > /proc/sys/vm/dirty_writeback_centisecs # 2000
echo "22" > /proc/sys/vm/dirty_ratio # 90
echo "4" > /proc/sys/vm/dirty_background_ratio # 70

At the moment i'm using the stock rom with original kernel, so i have to understand if this one use or not init.d.
@aprold: thanks for your input

Stock ROM doesn't support init.d.
I also don't recommend those values, the dirty ratios are too low and you shouldn't set adj values without their respective oom groupings.
Besides, swappiness=10 doesn't make any sense for us.
aprold said:
Keep in mind that first 2 parameters are set by Nova ROM.
Click to expand...
Click to collapse
Nope, Nova changes them all.

knzo said:
Nope, Nova changes them all.
Click to expand...
Click to collapse
Thank you for correcting me! Forgot that sysctl.conf is modified by you as well. Still educating myself on these kernel parameters...

knzo said:
Stock ROM doesn't support init.d.
...............
Click to expand...
Click to collapse
Does "stock" ROM + Quasarv8 kernel support init.d? How to take advance of it? I tried to make init.d folder with root explorer and put a script inside, but my script seems to be ignored..
Is there a way to achieve this?

@rgabi88: Sorry, not here to answer your question, came to fulfil my promise to comment on the before-mentioned script. Although I sincerely recommend to ditch the stock ROM.
Here are the things I learned today, please correct me if you find anything incorrect. The information below is gathered mostly from around here and you've probably already seen the bits and pieces of it. I've just written it down here to organize my thoughts and conclude the topic. I'll try to compare Juwe's script values to Nova values and come up with some kind of conclusion on the differences. I don't pretend to answer here many questions, on the contrary - this little investigation of mine raised them even more. Perhaps someone can comment on the questions in red? It's sad that kernel.org has been down for couple of weeks by now due to the security breach and there was no single source to turn to.
/sys/module/lowmemorykiller/parameters/adj
This file contains oom_adj values that specify which processes are killed of when minfree low memory limit is reached. Valid values range from -17 to 15 and value for each process is stored in /proc/<pid>/oom_adj file. The following script (purely for illustration) shows you oom_adj value for all the processes where this values is greater than 0:
Code:
#!/system/bin/sh
ps > $TMPDIR/ps.txt
echo -e "ADJ\tPID\tPPID\tUSER\tNAME"
while read user pid ppid vsize rss wchan pc s name; do
[ -f "/proc/$pid/oom_adj" ] && adj=$(head -n1 /proc/$pid/oom_adj) || adj=0
[ $adj -gt 0 ] && echo -e "$adj\t$name"
done < $TMPDIR/ps.txt
rm $TMPDIR/ps.txt
Juwe's values 0,1,2,4,6,15
Nova values 0,3,5,7,14,15
Here you can see that processes with negative oom_adj values are never killed off. Also Nova tries to kill processes later than Juwe. Question: who does (and based on what) specify the oom_adj values for processes in the first place?
Useful info here and here.
/sys/module/lowmemorykiller/parameters/minfree
This file contains numbers that represent amount of free memory when certain kind of applications get killed off. Values are in 4 kB pages (e.g. 1024 pages equals 4 MB). Applications fall into these categories:
FOREGROUND_APP: running currently on the screen
VISIBLE_APP: open and running in the background
SECONDARY_SERVER: service ready for use by an application
HIDDEN_APP: idle but still alive
CONTENT_PROVIDER: application that provides data to the system
EMPTY_APP: open but not used any more
So, the minfree file format is:
FOREGROUND_APP,VISIBLE_APP,SECONDARY_SERVER,HIDDEN_APP,CONTENT_PROVIDER,EMPTY_APP
Juwe's values: 2560,4096,6144,12288,14336,18432
Nova values 1536,2048,6656,7168,7680,8192
As you can also see that Nova is not in such a hurry to kill applications off which is good in a way that RAM is always in use as much as possible. Why would it be good to have free RAM in Android anyway?
This link has been very informative: http://www.androidcentral.com/fine-tuning-minfree-settings-improving-androids-multi-tasking
/proc/sys/vm/swappiness
This determines how aggressively the kernel swaps memory pages
Juwe 10
Nova 0
Does 0 for Nova mean that swap is completely turned off there?
/proc/sys/vm/vfs_cache_pressure
Controls the tendency of the kernel to reclaim the memory which is used for caching of directory and inode objects.
Juwe 50
Nova 1
Based on these values one would say that Nova tries to cache directories and inodes for as long as possible. When exactly does it get flushed then?
/proc/sys/vm/dirty_expire_centisecs
Defines when dirty data is old enough to be eligible for writeout by the pdflush daemons (in 100ths of a second).
Juwe 3000
Nova 1000
Nova will do this after 10 seconds, this is 3 times faster compared to Juwe. Is this timekeeping done for every data page or in larger blocks?
/proc/sys/vm/dirty_writeback_centisecs
Interval between pdflush writeback wakeups where 'old' data is written out to disk (again in 100ths of a second)
Juwe 500
Nova 2000
I understand that compared to Juwe this is done 4 times less frequently after every 20 seconds. Aren't these two values related in the sense that dirty_expire_centisecs/dirty_writeback_centisecs 1000/2000 is the same as 2000/1000?
/proc/sys/vm/dirty_ratio
Percentage of total system memory, the number of pages at which a process which is generating disk writes will itself start writing out dirty data.
Juwe 22
Nova 90
Here we can see again that Nova delays the actual disk writes for as long as possible.
/proc/sys/vm/dirty_background_ratio
Here is the percentage where pdflush does the job itself.
Juwe 4
Nova 70
dirty_ratio and dirty_background_ratio must be percentages from two different things otherwise pdflush would do the job at 70 % and there would be nothing left for process to do at 90 %. The link below says it to be MemFree + Cached - Mapped which is whole different thing than MemTotal
More info here
I must apologise to you who looked for the answers here but encountered only more and more questions. I know now that I don't know anything yet.
Regards,
Aprold

Wow!!!!!!!

rgabi88 said:
Does "stock" ROM + Quasarv8 kernel support init.d? How to take advance of it? I tried to make init.d folder with root explorer and put a script inside, but my script seems to be ignored..
Is there a way to achieve this?
Click to expand...
Click to collapse
The answer is NO....stock Rom + Quasarv8 Kernel don't support init.d.
But I have another question to knzo!? Why Nova doesn't use init.d !?
Maybe i'll be a newbie in this kind of kitchen, but reading init.rc inside boot.img I don't see the script to initialize init.d, while in system/etc the dir /init.d exists.
Could u explain me why don't u use init.d !?

Nova USES init.d!

Huexxx said:
Nova USES init.d!
Click to expand...
Click to collapse
furb3t said:
.......... but reading init.rc inside boot.img I don't see the script to initialize init.d, ................
Click to expand...
Click to collapse
I'm confused...where i'm wronging?!?! to read init.rc or to decompile boot.img (i don't believe) or init.d can be initialized by another script !?

[Q]speedmod kernel up-thresholds/sampling rate

Hello, I'm using speedmod kernel k3-3, ondemand governor and wanted to change up-threshold and sampling rate, but after i reboot phone it goes to default. Is it possible to change it permanently? thnx

EdgaBimbam said:
Hello, I'm using speedmod kernel k3-3, ondemand governor and wanted to change up-threshold and sampling rate, but after i reboot phone it goes to default. Is it possible to change it permanently? thnx
Click to expand...
Click to collapse
Set CPU, apply on boot ?

Boy124 said:
Set CPU, apply on boot ?
Click to expand...
Click to collapse
system tuner, rom manager, setcpu, antutu cpu... none of them works after reboot settings goes to default.

Extract attached file and copy 99cpu to init.d folder and grant it all the permissions.
I have set Up Threshold to 95% and Sampling Rate to 45000.
You can change the values, just edit 99cpu.
Reboot and check if values stick. If it does not, download Script Manager from the play store. In Script Manager, browse to init.d > select 99cpu > tap Su and Boot > tap save.
Exit and reboot.
PS
---
I think that values won't stick. I always had problems with init.d scripts on SpeedMod kernel. Please reply if values stick.

Boy124 said:
Extract attached file and copy 99cpu to init.d folder and grant it all the permissions.
I have set Up Threshold to 95% and Sampling Rate to 45000.
You can change the values, just edit 99cpu.
Reboot and check if values stick. If it does not, download Script Manager from the play store. In Script Manager, browse to init.d > select 99cpu > tap Su and Boot > tap save.
Exit and reboot.
PS
---
I think that values won't stick. I always had problems with init.d scripts on SpeedMod kernel. Please reply if values stick.
Click to expand...
Click to collapse
ok thank you vm, going to try
edit: values didnt change. seems that this kernel not supporting init.d scripts or what?
edit2: it changed after i ran script via script manager, will try again to reboot
edit3: seems that after reboot need manually boot script. Btw init.d folder what permissions should have?

EdgaBimbam said:
ok thank you vm, going to try
edit: values didnt change. seems that this kernel not supporting init.d scripts or what?
edit2: it changed after i ran script via script manager, will try again to reboot
edit3: seems that after reboot need manually boot script. Btw init.d folder what permissions should have?
Click to expand...
Click to collapse
Anything you want to run on boot in the init.d should have the rwx-rwx-rwx permissions

carbonassassin said:
Anything you want to run on boot in the init.d should have the rwx-rwx-rwx permissions
Click to expand...
Click to collapse
yeh thanks btw i have put this script at init.d
#!/system/bin/sh
# Up Threshold and Sampling Rate - Boy124
echo "70" > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo "45000" > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate
have set permissions to rwx-rwx-rwx and after reboot it doesnt work, even with script manager su and boot enabled, after reboot it doesnt work. Works only after running script manually, wtf is that

maybe my tweaks are atm useless, maybe it doesnt starts at boot

On CF-Root 5.6, it changes up threshold but sampling rate remains default.
See this http://forum.xda-developers.com/showpost.php?p=26582847&postcount=72
---------- Post added at 12:12 AM ---------- Previous post was at 12:06 AM ----------
carbonassassin said:
Anything you want to run on boot in the init.d should have the rwx-rwx-rwx permissions
Click to expand...
Click to collapse
Thanks. I never bothered to learn about permissions.
Whenever I am confused, I grant all the permissions. And it works most of the time.

Boy124 said:
On CF-Root 5.6, it changes up threshold but sampling rate remains default.
See this http://forum.xda-developers.com/showpost.php?p=26582847&postcount=72
---------- Post added at 12:12 AM ---------- Previous post was at 12:06 AM ----------
Thanks. I never bothered to learn about permissions.
Whenever I am confused, I grant all the permissions. And it works most of the time.
Click to expand...
Click to collapse
hmmm so to sum up, speedmod kernel doesnt support init.d? maybe tomorrow will try franco kernel.

[LB] The definitive root Remount-Reboot fix!

As I've been working on the Stock ROM release of 10.1.1.A.1.307 some of my users started reporting that the issues I fixed for my 10.1.1.A.1.253 release started popping up again: whenever anyone with a locked bootloader tried to remount /system writable (remount,rw) it spontaneously sprung a reboot... very annoying, to say the least!
It gets even better (or worse, depends on how you look at it) when you consider any CWM version ever released for our Z/ZL models will ask us if we want it to prevent the ROM from flashing STOCK recovery...  /system/etc/install-recovery.sh is the culprit here as it is what CWM disables by making it non-executable when you say YES to the question 'ROM may flash stock recovery on boot, fix?'. It actually is an important part of the rooting process we all know. It stopped the RIC service and prevented the reboots from happening. If someone said YES, the issue mentioned in the previous paragraph would also start happening and some users have even reported loss of root and even bootloops because of this...
I've set out to find a fix for it, one that eliminates the chance a regular run-of-the-mill CWM user will ever encounter the question ever again.
For all of the regular users, download one of these:
Warning for Xperia T [ALL VERSIONS] Users: There is a problem with this patch combined with the CWM package for your phones, it seems to be busybox related. @garik.007 found the solution to this issue: BusyBox by Robert Nediyakalaparambil. Install that app, update your busybox and it will fix CWM and the remount-reboot fix
WINDOWS INSTALLER: [NUT]'s definitive remount-reboot fixer!
Make sure you have USB debugging turned ON.
Download the package, save it somewhere you remember
Unzip it somewhere you remember
Run the install.bat file and choose the superuser app you are using.
Done!
The phone should do what the installer tells you it's doing, so if it says your phone will reboot, it will. If it did NOT explicitly say that it would then something went wrong!
RECOVERY FLASHABLE: [NUT]'s definitive remount-reboot fixer!
This is a flashable ZIP, install using CWM or TWRP and you're done!
It is safe to use on any STOCK (Read: NOT CM Based) ROM version released for all Xperia phones with the ric binary incorporated in the ramdisk (/sbin/ric) up to now. To see if this fix will work for your device, check if the 'ctrlaltdel' command is executed from the init.sony[anything].rc scripts. If it is, this will work!
NOTE: As this fix needs busybox to function and will install or update busybox in /system/xbin if no busybox or no busybox binary which supports the 'nohup' applet was found in /system/bin, /system/xbin or /sbin.
NOTE 2: As soon as you have installed this rootfixer and you saw it replace the already installed busybox, remove any and all busybox installer apps you have, it will probably break the rootfixer if you update busybox using that app. The version this rootfixer installs is rock solid and is used by most if not every kernel dev working on Xperia line kernels.
NOTE 3: If you have an unlocked bootloader, you can actually also install it, it won't hurt and you'll be protected from the reboots if you re-lock your phone!
XDA:DevDB Information
The definitive root Remount-Reboot fix!, Tool/Utility for the Sony Xperia Z
Contributors
[NUT]
Version Information
Status: Stable
Stable Release Date: 2013-06-25
Created 2013-06-27
Last Updated 2015-02-05

Reserved
For the ROM chefs and other devs on XDA:
I'm proud to donate the following to the dev-community on XDA, for anyone who wants to integrate it in his/her ROM or rooting tool, there is no need to ask for permissions: you can!
This hijacks the toolbox command 'ctrlaltdel' executed from init.sony-platform.rc line 13. It will take it's place in a similar way as the chargemon gets replaced to make the recoveries possible on locked bootloaders. As it is a symlink to /system/bin/toolbox there is NO need to create a copy to something else to make this work. The script that takes it's place is this:
Code:
#!/system/bin/sh
#####
#
# Completely demolish the RIC service and make sure the phone will survive a remount of /system
#
# Author: [NUT] from XDA
#
ARGS="$1 $2"
# Check busybox path and export it
if [ -x "/system/xbin/busybox" ]; then
export BUSYBOX="/system/xbin/busybox"
elif [ -x "/system/bin/busybox" ]; then
export BUSYBOX="/system/bin/busybox"
elif [ -x "/sbin/busybox" ]; then
export BUSYBOX="/sbin/busybox"
fi
# Mount rootfs rw, if it isn't already
ROOTFSMOUNTEDRO=`$BUSYBOX grep "rootfs ro,relatime" /proc/mounts | $BUSYBOX wc -l`
if [ "$ROOTFSMOUNTEDRO" = "1" ]; then
$BUSYBOX touch /tmp/remountedrootfs
$BUSYBOX mount -o remount,rw /
fi
# Edit the init.rc so the service never gets to start
$BUSYBOX sed -i '/"# Start RIC"/N;s/service ric /sbin/ric/#service ric /sbin/ric/g' /init.sony.rc
$BUSYBOX sed -i '/"#service ric /sbin/ric"/N;s/ class main/# class main/g' /init.sony.rc
$BUSYBOX sed -i '/"# class main"/N;s/ user root/# user root/g' /init.sony.rc
$BUSYBOX sed -i '/"# user root"/N;s/ group root/# group root/g' /init.sony.rc
# chmod the ric binaries so they can't start anymore, as a failsafe
if [ -x "/sbin/ric" ]; then
$BUSYBOX chmod 644 /sbin/ric
fi
if [ -x "/system/bin/ric" ]; then
$BUSYBOX chmod 644 /system/bin/ric
fi
# Make sure the RIC service gets killed if it manages to start up...
# This process will drop in the background and keeps running untill it did!
$BUSYBOX nohup /system/bin/killric.sh &
# Execute the actual command now
exec /system/bin/toolbox ctrlaltdel $ARGS
As you can see I'm spawning a process into the background to kill the RIC service. Even though I commented out the service in init.sony.rc it still manages to start up as init reads and buffers all of it's scripting before it actually starts to do anything... so the service will run regardless of the changes we make to it. This step was just for any form of runlevel change to prevent that from triggering a restart. As a secondary measure it disables the binary all the way by setting 644 permissions on it.
Code:
#!/system/bin/sh
#####
#
# Check RIC looper, it will exit as soon as it found and killed it!
#
# Author: [NUT] from XDA
#
DoesFileExist() {
if [ -f "/tmp/killedric" ]; then
return 0
else
return 1
fi
}
# As the init.rc scripts seem to be running parallel, lets kill ric if it got started.
until DoesFileExist
do
RICCHECK=`$BUSYBOX ps | $BUSYBOX grep "/sbin/ric" | $BUSYBOX wc -l`
if [ $RICCHECK -gt 1 ]; then
$BUSYBOX pkill -f /sbin/ric
fi
if [ $RICCHECK -eq 1 ]; then
$BUSYBOX touch /tmp/killedric
fi
$BUSYBOX sleep 2
done
exit 0
This does a loop every 2 seconds and tries to pkill /sbin/ric. When successful it will exit.
To double check if these 2 scripts did their job you can check /tmp for 2 empty files:
- /tmp/remountedrootfs
and
- /tmp/killedric
If they exist, checking the processlist should end up empty when trying to find killric.sh, ctrlaltdel and /sbin/ric. If so, on a locked bootloader, you can now safely remount /system and rootfs (/) and survive it
This is my gift to the community, enjoy a trouble free root experience with it!
Thanks go to:
@DooMLoRD for the chat about the init process
@RoberM for testing and suggestions, he found out pkill does successfully kill the ric process in .307
@fards for the brainstorming in my .307 ROM thread
@Carceri for the brainstorming in my .307 ROM thread

Has this fix been implemented in latest dual boot recovery for locked boatloader?
Sent from my C6603 using xda app-developers app

shoey63 said:
Has this fix been implemented in latest dual boot recovery for locked boatloader?
Sent from my C6603 using xda app-developers app
Click to expand...
Click to collapse
No, but it will
XZDualRecovery 2.4 will get this fix as well.
In the mean time you can flash this just as well

Ok
Reason I ask is this:-
I Flashed stock .434, rooted it, flashed your dual boot recovery and did an OTA update to .253.
To my amazement, update worked, plus Root and your dual recovery were still intact! Also no reboot when accessing system as R/W:good:
I will apply your patch and see what happens when OTA for .307 comes through (eventually)

My phone switches off after the Xperia wave animation.
Facts:
Locked BL
on .253
Rooted
Did not have the R/W mount issue, but I flashed it anyway
Latest CWM/TWRP recovery
I have Fidelity V4 (If that is of any consequence here)
While flashing it detected that I had busybox (If that is of any consequence as well)
Restoring system from old backup fixed it.

Great job with fixing this and making it easy for other people to use in their ROMs.
At first I thought there was a problem with this fix due to a race condition: As far as I can see rootfs is mounted r/w before ric is killed, so I would expect that sometimes ric might start early, see that / is rw and reboot the phone. I was surprised that this did not happen, but actually it seems that ric does not check permissions on rootfs (I could mount it r/w with ric running without getting a reboot).
chmod 644 /sbin/ric is (for me at least) not just a failsafe. It is needed because otherwise ric keeps being respawned whenever it's killed giving another race condition where sometimes it might have time to reboot the phone before it is killed again.
So: This fix should work as long as ric behaves as it does on the kernel that comes with 307.
As I said I also made my own version of a fix in parallel. I wrote it in C as I needed access to some system calls. Basically it is an executable that can be run from whereever one wants to start a program. It runs as a daemon that waits for /sbin/ric to be started. Once it sees ric, it forces ric and itself to run on the same CPU, schedules itself with realtime priority on that CPU so ric never gets a chance to run, replaces the ric executable in /sbin/ric by a dummy version that justs sleeps and kills the original ric process. I could also have deleted it, but whatever respawns ric now don't have to try to start a new process all the time, since it will see that ric is still running.
I have tested my own solution for the past day or so and it seems to work fine. I'll probably post the binary and source code for it later.

008bond said:
My phone switches off after the Xperia wave animation.
Facts:
Locked BL
on .253
Rooted
Did not have the R/W mount issue, but I flashed it anyway
Latest CWM/TWRP recovery
I have Fidelity V4 (If that is of any consequence here)
While flashing it detected that I had busybox (If that is of any consequence as well)
Restoring system from old backup fixed it.
Click to expand...
Click to collapse
Hmm, maybe your ROM chef built in something that conflicts with this script. His own solution to RIC maybe?
Sent from my C6603 using xda app-developers app

[NUT] said:
Hmm, maybe your ROM chef built in something that conflicts with this script. His own solution to RIC maybe?
Sent from my C6603 using xda app-developers app
Click to expand...
Click to collapse
I'm using stock. I think the issue lies with me flashing Fidelity V4.0.
EDIT: I can confirm that Fidelity patch is the issue.

008bond said:
I'm using stock. I think the issue lies with me flashing Fidelity V4.0.
EDIT: I can confirm that Fidelity patch is the issue.
Click to expand...
Click to collapse
Cr*p, I'm out of thanks to give the usual way today, so:
Thanks for the useful info, you scared me a bit there
Carceri said:
Great job with fixing this and making it easy for other people to use in their ROMs.
At first I thought there was a problem with this fix due to a race condition: As far as I can see rootfs is mounted r/w before ric is killed, so I would expect that sometimes ric might start early, see that / is rw and reboot the phone. I was surprised that this did not happen, but actually it seems that ric does not check permissions on rootfs (I could mount it r/w with ric running without getting a reboot).
chmod 644 /sbin/ric is (for me at least) not just a failsafe. It is needed because otherwise ric keeps being respawned whenever it's killed giving another race condition where sometimes it might have time to reboot the phone before it is killed again.
So: This fix should work as long as ric behaves as it does on the kernel that comes with 307.
As I said I also made my own version of a fix in parallel. I wrote it in C as I needed access to some system calls. Basically it is an executable that can be run from whereever one wants to start a program. It runs as a daemon that waits for /sbin/ric to be started. Once it sees ric, it forces ric and itself to run on the same CPU, schedules itself with realtime priority on that CPU so ric never gets a chance to run, replaces the ric executable in /sbin/ric by a dummy version that justs sleeps and kills the original ric process. I could also have deleted it, but whatever respawns ric now don't have to try to start a new process all the time, since it will see that ric is still running.
I have tested my own solution for the past day or so and it seems to work fine. I'll probably post the binary and source code for it later.
Click to expand...
Click to collapse
The way i do the remount of / is no problem in 2 ways: it only remounts when really needed and as it is indirectly executed by init, it will never cause ric to intervene and trigger a reboot. If you have the reboot issue, remounting rootfs (/) from any root explorer app actually does cause a reboot.
About your ric killer application: nice! I've never programmed in C, otherwise I might have attempted something similar. But I know bash/ash scripting, so I fixed it the way I knew best
From my perspective you could make your daemon exit once it has killed /sbin/ric after changing it's permissions to 644. I've been testing my fix for a few days now (on stock kernel and re-locked bootloader) and the method in this thread completely prevents it from starting /sbin/ric ever again :victory:

My daemon does exit once it has killed ric and made sure it cannot start again.
Whatever respawns init keeps checking, so deleting the file, making it non executable or replacing it with a dummy all works. If you chmod 755 it again, ric does respawn on my phone, so something (probably init) keeps trying to start it if it isn't running.
On my phone (before killing ric) mounting / rw does not cause a reboot, but mounting /system rw does. Weird.

Carceri said:
My daemon does exit once it has killed ric and made sure it cannot start again.
Whatever respawns init keeps checking, so deleting the file, making it non executable or replacing it with a dummy all works. If you chmod 755 it again, ric does respawn on my phone, so something (probably init) keeps trying to start it if it isn't running.
On my phone (before killing ric) mounting / rw does not cause a reboot, but mounting /system rw does. Weird.
Click to expand...
Click to collapse
That would be init indeed, as it's a service without 'oneshot' (fires only once, then init stops monitoring) or 'disabled' (init never fires it but it waits for an explicit call to get that service started).
I've found a guide on the Android init daemon/process, I'll post a link to it in this thread tonight, it's an interesting read
I never tried to restart the init process to be able to disable the service though, might be attempting to do so some day. It is what the recoveries do with the chargemon hijack method, they stop all services, unmount everything, cleans up the ramdisk and then unpacks the recovery to start it's init binary.
I'll try that some time soon and see if that will work as well, that would probably be the cleanest way, it would render killric.sh and your application useless as they would no longer be needed, simplifying and 'niceifying' the entire process.

Yep, this fix works perfectly!
Flashed stock .307, unlocked bootloader, flashed @DooMLoRD kernel then rooted through recovery, flashed root fix, flashed stock .307 kernel and then restored TA partition.
Rebooted and used Root explorer in system with R/W permissions. No reboots
Congrats @[NUT] :good:

@Carceri
[NUT] said:
I never tried to restart the init process to be able to disable the service though, might be attempting to do so some day. It is what the recoveries do with the chargemon hijack method, they stop all services, unmount everything, cleans up the ramdisk and then unpacks the recovery to start it's init binary.
I'll try that some time soon and see if that will work as well, that would probably be the cleanest way, it would render killric.sh and your application useless as they would no longer be needed, simplifying and 'niceifying' the entire process.
Click to expand...
Click to collapse
I've been experimenting with that and so far I have not been very successful... apart from not working as i hoped (it reboots after the second init attempt), it also repeats a few parts of the boot process as crtlaltdel is executed too late during the init and thus it will allow you to enter recovery twice for example :silly:
It might be needed to re-hijack the chargemon process as this is executed precisely at the right time for this idea to work... but doing so will break compatibility with all available recoveries... and throws in some caveats for the recovery users... just the thing i was trying to fix for all and any of the Z/ZL lovers
Stuff to ponder on...
*ponders on* Maybe I can use the ctrlaltdel script to 'fix' anything that breaks and then trigger a reboot to make sure the user gets to boot in to a good working android...
chargemon would be my new rickiller script, it checks for the flagfile it creates itself, if it's not found it will do the RIC fix, then create's the flagfile and restarts init. With the second init it will find the flagfile and will execute the re-hijacked chargemon hijack script to offer recovery. If not chosen to enter recovery it will just continue boot.
Once ctrlaltdel gets started it checks if the md5sum of the chargemon script is what it's supposed to be. If not, it will create a backup of that chargemon file for execution by the re-hijacked chargemon script that it copies from a backup file somewhere (probably simply in /system/bin) corrects permissions and then triggers a reboot...

PRECAUTION: This post is on the file attached, it has no meaning regarding the OP: that fix works just fine.
Well, I'm putting my scripting online that i wrote on the above idea for those in the know, I'm not sure why it does not work but
THIS DOES NOT WORK
For anyone who wants to help out, you are welcome to take a look... you can even try it (put the 2 files inside /system/bin) but note the warning above...
To recover from the tantrum it throws, be sure to have an unlocked bootloader and DooMKernel installed. You will need TWRP to get you out of trouble, which is easy: mount system, use advanced -> filemanager and look inside /system/bin. chmod chargemon and ctrlaltdel to 644. Reboot and you're out of trouble.
Who has any idea why this does not work?

well, it sadly doesn't help me.. I'm on Odexed Stock ROM .307
if I try to rename / delete / add an apk into /system/app/ my phone still reboots..

FSN said:
well, it sadly doesn't help me.. I'm on Odexed Stock ROM .307
if I try to rename / delete / add an apk into /system/app/ my phone still reboots..
Click to expand...
Click to collapse
Can you check if there is a file called killedric in /tmp?
Sent from my C6603 using xda app-developers app

[NUT] said:
Can you check if there is a file called killedric in /tmp?
Sent from my C6603 using xda app-developers app
Click to expand...
Click to collapse
I don't have this file. Locked BL, flashed w/ TWRP 2.4.0.0

FSN said:
I don't have this file. Locked BL, flashed w/ TWRP 2.4.0.0
Click to expand...
Click to collapse
Right, then check things in succession, stop and report which you stopped at:
1. Check if /system/bin/killric.sh exists.
2. Open /system/bin/ctrlaltdel to see if it looks like the one on the OP.
3. Open a terminal app and see if killric.sh is running by typing the command 'ps | grep killric.sh'
If you have to say no to 1 and 2, reflash the zip. Then try again, if it still fails send me the logs from /cache/recovery
Sent from my C6603 using xda app-developers app

[NUT] said:
Right, then check things in succession, stop and report which you stopped at:
1. Check if /system/bin/killric.sh exists.
2. Open /system/bin/ctrlaltdel to see if it looks like the one on the OP.
3. Open a terminal app and see if killric.sh is running by typing the command 'ps | grep killric.sh'
If you have to say no to 1 and 2, reflash the zip. Then try again, if it still fails send me the logs from /cache/recovery
Sent from my C6603 using xda app-developers app
Click to expand...
Click to collapse
1. Yes
2. Yes
3. If it returns 1 it runs, right?
Could it have something to do with the exFAT patch (for 64GB sd cards)?

[MOD][P905] enable init.d support for stock rom LTE QUALCOMM ONLY!

At first, I am not liable for any harm or damage that may happen to your device!
If you have su and didn't trigger knox, I CANNOT guarantee that running this script won't cause 0x1!
Requirements:
1) P905/viennalte/Qualcomm based model ONLY (won't work on Exynos devices. MIGHT work on other Qualcomm LTE deices from Note Pro and Tab Pro series - feel free to repost but give credits!) running 4.4.2 stock;
2) root access with SuperSU (using cf-root - credits to chainfire);
3) busybox installed (I do recommend this paid installer: https://play.google.com/store/apps/details?id=stericson.busybox.donate , MOST PROBABLY free version will be more than enough, too, but I haven't tested it as I have license...)
4) Android Terminal Emulator installed ( free at: https://play.google.com/store/apps/details?id=jackpal.androidterm )
Installation:
1) download file init.d_qcom.sh using below link and put it in the root of internal memory (so it will be placed in: /sdcard/init.d_qcom.sh)
2) run Android Terminal Emulator
3) at command line, type:
Code:
su -c /sdcard/init.d_qcom.sh
(give it an access if requested)
4) voila.
Additional info for advanced users:
1) scripts in /system/etc/init.d shall be root:root 755 (and NOT 777 as stated in A LOT of sources, thou has to be a heavy idiot to give write access for system files to "world"...)
2) init.d is handled from one of the /system/etc qualcomm additional scripts as it refused to work using regular install-recovery.sh method...
3) scripts are triggered paralelly but I am using different method (find/nohup/su combination...), as this damn rom refused to simply execute "run-parts" applet...
4) init.d permission helper script included (just put your scripts in init.d and they'll receive proper permissions on reboot)
Download:
http://www12.zippyshare.com/v/32009778/file.html

Nice to see some developement for this tab!
Anyway to port it to exynos? :fingers-crossed:

prohackerbro said:
Nice to see some developement for this tab!
Anyway to port it to exynos? :fingers-crossed:
Click to expand...
Click to collapse
+1
sent from my amazing NotePro 12.2 via Tapatalk

Criminal23 said:
+1
sent from my amazing NotePro 12.2 via Tapatalk
Click to expand...
Click to collapse
I might try, however I do not own the device and the file structure is completely different.. Can you first enter via Android Terminal:
Code:
su
ls -l / >/sdcard/content.txt
ls -l /system/etc >>/sdcard/content.txt
And post the /sdcard/content.txt file which will be created (or its contents only)?
Also, i would be glad if you copy every *.rc file from root of filesystem to a dir , compress it to one file and post it too

esgie said:
I might try, however I do not own the device and the file structure is completely different.. Can you first enter via Android Terminal:
Code:
su
ls -l / >/sdcard/content.txt
ls -l /system/etc >>/sdcard/content.txt
And post the /sdcard/content.txt file which will be created (or its contents only)?
Also, i would be glad if you copy every *.rc file from root of filesystem to a dir , compress it to one file and post it too
Click to expand...
Click to collapse
Here you are
Criminal23

Criminal23 said:
Here you are
Criminal23
Click to expand...
Click to collapse
Criminal23 said:
Here you are
Criminal23
Click to expand...
Click to collapse
After looking into sent (and posted) files, I have to say that the init process in our devices are ABSOLUTELY different.
Qualcomm version triggers about 7-8 scripts lying in /system, which are provided by Qualcomm, which are pointed in configuring all the hardware provided with their chipset - in addition to init.???.rc files from the kernel. The clue was to add init.d execution command at the very end of one of those scripts (and that is done automatically with script attached in the first post).
Exynos version does not launch (almost - see below) ANY external script during the boot. Whole process seems to be performed by rc files lying in root of the filesystem, which are embedded in kernel's ramdisk and any edits won't preserve the reboot, so it cannot be done without repacking the kernel and that is something far more troublesome to perform without device in hand, without the firmware on disk and without a plenty of time.
BUT
it still runs /system/etc/install-recovery.sh which is an Android standard and which genuine purpose was to reflash recovery back to stock if a custom one was detected. Now, it is sometimes utlized to run somehing at boot, especially: it is used by SuperSu (in addition with other methods) to run its daemon. The problem is that kitkat introduced enforcing SELinux, that Samsung SELinux policy adds special security context for this file, that install-recovery.sh won't be launched if the file has no proper security label - and that while installing SuperSu, the context is set in a different way and in final, install-recovery.sh isn't launched, until we restore /system context, and restoring context to the system ends with... non working su, so we have to flash it again, breaking install-recovery.sh context... Did you get it? - it's a loop as fixing one thing breaks the second, and fix to the second breaks the first That is why on my qualcomm device i have chosen another script file to run the init.d - and as you don't have any other script except install-recovery.sh, I don't know where it might be put...
BUT also I cannot guarantee that the behavior above is not qualcomm-exclusive and it is possible that on exynos device everything will work without problem!
That's why you may want to try standard method for all the devices (term init - uses install-recovery.sh method described above):
http://forum.xda-developers.com/showthread.php?t=1933849
and if it won't work then you have to wait for - at least - repacked kernel with init.d support embedded into init.rc files or run your script by an external app, ie SManager. Just be aware that even if term init work, it may stop working every time you flash SuperSu, so remember to run the script again then.
Sorry for not being too helpful.

How to disable zram permanently (at boot).

I am using Carbon kitkat for i9070.
By default zram is enabled in it.
On every boot, I just disable it using swapoff /dev/block/zram0
But the problem I am facing is occasional freeze during which the most resource intensive process is "kswapd0"
So I want to disable zram permanently without using any app or script. Can any dev or geek help me out with the terminal command to disable zram permanently?
@AntaresOne , sorry to disturb you dev, but you are my only hope right now.
@shut_down ?

rajag33 said:
I am using Carbon kitkat for i9070.
By default zram is enabled in it.
On every boot, I just disable it using swapoff /dev/block/zram0
But the problem I am facing is occasional freeze during which the most resource intensive process is "kswapd"
So I want to disable zram permanently without using any app or script. Can any dev or geek help me out with the terminal command to disable zram permanently?
@AntaresOne , sorry to disturb you dev, but you are my only hope right now.
@shut_down ?
Click to expand...
Click to collapse
I am not sure, because I do not use Carbon now (I am on CM 10.1). But it used preload partition for it, probably some custom made zram option from TC. But I do not know how to disable it...

@shut_down Thank you buddy... Let me call some one for help. This zram thingy is really bugging me. kswapd freezes phone even when zram is off and no swap enabled.

Swap and zram are different.
Swap uses preload partition. Using both swap and zram at the same time will make your phone lag.
To disable zram on boot, make an init.d script and put it in /system/etc/init.d folder.
Sent from my GT-I9070

anantttt said:
Swap and zram are different.
Swap uses preload partition. Using both swap and zram at the same time will make your phone lag.
To disable zram on boot, make an init.d script and put it in /system/etc/init.d folder.
Sent from my GT-I9070
Click to expand...
Click to collapse
@anantttt Buddy, I know everything about zram and swap as I am a debian Linux user for years. There is no swap enabled in my phone. Disabling zram in ubuntu Linux is an easy process. But in case of android, I don't know the exact commands to deliver in terminal. Basically, I think it can be disabled without using scripts. Anyway, thank you for answering. Do you know how to create a init.d script to disable zram at boot?
I think the better way is to disable the kernel module corresponds with swap and zram...... Hope, I will soon find a workaround.....

rajag33 said:
@anantttt Buddy, I know everything about zram and swap as I am a Linux user for years. There is no swap enabled in my phone. Disabling zram in Linux is an easy process. But in case of android, I don't know the exact commands to deliver in terminal. Basically, I think it can be disabled without using scripts. Anyway, thank you for answering. Do you know how to create a init.d script to disable zram at boot?
I think the better way is to disable the kernel module corresponds with swap and zram...... Hope, I will soon find a workaround.....
Click to expand...
Click to collapse
Modifying kernel is a tedious work and my knowledge is limited.
For making init.d script See if this helps
http://forum.xda-developers.com/showthread.php?t=2503884
Sent from my GT-I9070