[Sony Ericsson Xperia Mini, Mini Pro, Xperia Pro, A] tobbbie:
It seems that all Xperia Kernels that stem back to the DoomLord kernel start the init.d execution twice. While you may think "better twice than never" the nearly parallel execution of scripts can create problems if they concurrently manipulate CPU related tables - or fail to do so due to security mechanisms built in. I was hunting the problem that cpu-clock manipulation from init.d did not work for the scripts generated by System Tuner - finally resulting in this finding.

I checked for sirkay 587c and 587d and for fly-kernel 0.8 as the latest of their breed, quite sure nobody has ever cared about this quirk.

The duplicate execution could be tracked back to the init.rc entries:

[COLOR=SeaGreen]#DooMLoRD: init.d scripts support
start sysinitsupport
class_start core
class_start main

#DooMLoRD: new init.d scripts support
service sysinitsupport /sbin/sysinitsupport.sh
class main
disabled
oneshot[/COLOR]

Which does:

#!/sbin/sh

# DooMLoRD: init.d support script (v1)

# [START] setting up
echo "[START] remounting system" > /data/local/tmp/sysinitsupportlog.txt
/sbin/busybox mount -o remount,rw /system >> /data/local/tmp/sysinitsupportlog.txt

# make init.d directory
echo "
[*] make init.d directory" >> /data/local/tmp/sysinitsupportlog.txt
/sbin/busybox mkdir -p /system/etc/init.d >> /data/local/tmp/sysinitsupportlog.txt

# correcting permissions of files in init.d directory
echo "
[*] correcting permissions of files in init.d directory" >> /data/local/tmp/sysinitsupportlog.txt
/sbin/busybox chmod 777 /system/etc/init.d/*

# [COLOR=DarkOrchid]make [/COLOR]init.d directory
echo "
[*] [COLOR=DarkOrchid]make [/COLOR]init.d directory" >> /data/local/tmp/sysinitsupportlog.txt
[COLOR=Red]/system/bin/logwrapper /sbin/busybox run-parts /system/etc/init.d[/COLOR]

# [DONE] all done exiting
echo "[DONE] all done exiting" >> /data/local/tmp/sysinitsupportlog.txt

And later also in init.rc:

[COLOR=SeaGreen]#DooMLoRD: run my mods
service mymods /sbin/execute_mods.sh
class main
oneshot[/COLOR]

Which then does:

#!/sbin/sh

# starting
echo "[ START ]" > /data/local/tmp/log_doom-mods.log
echo "" >> /data/local/tmp/log_doom-mods.log

[COLOR=Red]# execute tweaks
/system/bin/logwrapper /sbin/busybox run-parts /etc/init.d[/COLOR]
# execute FPS limit remove
/sbin/mount -t debugfs debugfs /sys/kernel/debug
/sbin/echo '0' > /sys/kernel/debug/msm_fb/0/vsync_enable
/sbin/umount /sys/kernel/debug
echo "FPS limit successfully removed " >> /data/local/tmp/log_doom-mods.log

# DONE
echo "" >> /data/local/tmp/log_doom-mods.log
echo "[ DONE ]" >> /data/local/tmp/log_doom-mods.log

You see that the execution of

[COLOR=Red]/system/bin/logwrapper /sbin/busybox run-parts /etc/init.d[/COLOR]

is actually done twice - from sysinitsupport.sh first and then again from execute_mods.sh

Also mind that the log-entry in the first is leading in the wrong direction (copy error from above). It should better read "execute init.d directory"

The related logs are found in \data\local\tmp.

You can check yourself with this little script in \etc\init.d:

#!/system/bin/sh

echo [] > /data/local/tmp/$PPID-exec-done
echo $PPID "init.d executed" >> /data/local/tmp/$PPID-exec-done
date >> /data/local/tmp/$PPID-exec-done

Mind the $PPID which is the parent PID of the executing command (the busybox "run-parts"). Per boot you should just get 1 file <PPID>-exec-done containing the timestamp if you get 2 then you know why...

I have attached the script wrapped in a zip file. Unpack it, copy to \etc\init.d (or if not sym-linked to \system\etc\init.d) and change attributes to "777". Reboot and look what you get in \data\local\tmp.

Once you know, remove the script again and delete the created files in \data\local\tmp.

Mind that the scripts referenced from init.rc are copied over again from the kernel part so any change of the scripts in the \system\sbin folder is useless. The kernel has to fix that, no way out here.