[Desire HD General] lynxboy:
So it seems that /init is a core process regarding the initialisation of the Android system and userspace hence the fact it cannot be killed using OSMonitor. It is always the first process that runs on Linux systems after boot and acts as a parent process which itself initialises then processes needed to get the OS going.

Here is a description of the Android Init Process from elinux,

'init'

A key component of the Android bootup sequence is the program 'init', which is a specialized program for initializing elements of the Android system. Unlike other Linux systems (embedded or otherwise), Android uses its own initialization program. (Linux desktop systems have historically used some combination of /etc/inittab and sysV init levels - e.g. /etc/rc.d/init.d with symlinks in /etc/rc.d/rc.[2345]). Some embedded Linux systems use simplified forms of these -- such as the init program included in busybox, which processes a limited form of /etc/inittab, or a direct invocation of a shell script or small program to do fixed initialization steps.

The init program processes two files, executing the commands it finds in them, called 'init.rc' and 'init.<machine_name>.rc', where <machine_name> is the name of the hardware that Android is running on. (Usually, this is a code word. The name of the HTC1 hardware for the ADP1 is 'trout', and the name of the emulator is 'goldfish'.

the 'init.rc' file is intended to provide the generic initialization instructions, while the 'init.<machine_name>.rc' file is intended to provide the machine-specific initialization instructions.

The Bug

The /init bug has presented itself on numerous handsets including the HTC Desire, Nexus One and Droid X models. It seems to be specific to Android 2.2 and reports the same symptoms on all handsets. Primarily this is due the 99% CPU usage causing system slowdown and left unchecked, high battery usage. It is not specific to HTC Sense ROMs as it also presents itself on stock releases. The only solution so far is a reboot. Hard Reboots and altering system settings seem to have no effect on the reproduction of this bug.

I can only speculate to what is causing the issue and hopefully a Dev can shed some more light.

Logically it seems as though a 'rogue' process is triggering /init to resume its primary function in regards to checking filesystems and attempting to spawn other system process. Due to some form of miscommunication between the processes in question, /init continues to perform these post boot tasks in a constant loop.

Think of it like this, if you try perform tasks straight after boot, the phone is unresponsive while the SD is mounted/checked and all other processes are fired up. The /init process is responsible for these tasks. If it were to loop, you would experience the symptoms we are having.

I found this on Wikipedia:

After /init has spawned all of the processes specified, init goes dormant, and waits for one of three events to happen:- processes it started to end or die, a power failure signal[clarification needed], or a request via /sbin/telinit to further change the runlevel.

So our trigger should hopefully be narrowed down to these three events.

Regarding what I posted before, the connection between sync and the bug has proven itself to be a false one.

I've also noticed that sometimes the bug can be present, however there is little impact on the responsiveness of the OS. It can seem as though everything is ok yet the CPU load can be extremely high, resulting in poor battery performance.

Anyway, hopefully more people can contribute to this thread so we can build up a better picture of what is going on. I will also try and grab a Logcat and ask anyone else near their PC when it happens to do the same.

There is a thread here which has users complaining of the same problems, yet no solutions are presented. Hopefully we can make a bit more noise and get some definitive answers.

Regards.