Best way to exec script on boot

[knauck]

If you want to execute a script on boot, use /etc/upstart. The following methods will NOT work:

• /etc/crontab/root with @reboot task
• /etc/init.d/
• /etc/rc.local

Make a file with the extension '.conf' and add a start condition and a stop condition as your first and second lines. Be sure your script and your .conf are unix format and not windows. (CRLF is bad and will make big problems.)

For example: /etc/upstart/fubar.conf

start on started lab126_gui
# This line tells init.d where in the boot process to start this script. Good
# places are "start on started framework" if you need it to run after the
# framework daemon is running. "start on started lab126_gui" tells it to run
# after the ui is up. That is the final phase of the boot process.

stop on stopping lab126_gui
# This tells the system when in the shutdown process to kill your script. If
# you are just running a single command, this isn't terribly important.

script
	# exec /bin/sh /your/script/here.sh
	exec /bin/bash /var/local/dev/somescript.sh
end script

** !! NOTICE !! ** !! NOTICE !! ** !! NOTICE !! ** !! NOTICE !! **

If you choose to remove whatever this conf points to, you MUST MUST MUST delete this from the upstart folder. If anything in this folder errors out there is a very good chance your kindle will fail to boot!

Original question:

Spoiler:

As title implies, I am looking for the best way to effectively run a single script at boot time. This may be done after framework has started.

So far I have tried using @reboot in crontab, a conf file in /etc/upstart, and a service in init.d, none of which worked...what am I missing?

[knauck]

Solved own problem. Updated OP to show solution for posterity.

[knc1]

Originally Posted by knauck

Solved own problem. Updated OP to show solution for posterity.

A variation on this problem solution which puts the scripts into user accessable storage published by dos1 about 5 months ago:
https://www.mobileread.com/forums/sho...d.php?t=198484

Also indexed under the K5 prefix.

[NiLuJe]

Wrapping up everything in tests is a good way to avoid everything blowing up if something's missing/wrong/broken.

(For debugging purposes (of the inlined parts of the script), testing your scripts with a shell in -e mode is also a good practice, especially if you rely on external tools with broken return codes).

Cf. dos1's tool for more examples, or the upstart jobs of the SS/Fonts hacks).

[knauck]

Originally Posted by NiLuJe

Wrapping up everything in tests is a good way to avoid everything blowing up if something's missing/wrong/broken.

(For debugging purposes (of the inlined parts of the script), testing test your scripts with a shell in -e mode is also a good practice, especially if you rely on external tools with broken return codes).

Cf. dos1's tool for more examples, or the upstart jobs of the SS/Fonts hacks).

Yeah and I forgot to mention that adding a return code of 0 is a good idea, too.

[damaru]

How can I go about it on the k3?

[NiLuJe]

@damaru: A classic SYSV init script .

Lemme dig up the interesting runlevels, but, OTOH, 5 is boot, 6 is reboot, 0 is shutdown, and 3 is update.

For example, the same script I linked to earlier, but in its K3 version: ScreenSavers hack. (Check the install script for more details on the whole symlinking into the right runlevel stuff).

[thomass]

Originally Posted by damaru

How can I go about it on the k3?

you can use kite

[damaru]

Originally Posted by NiLuJe

@damaru: A classic SYSV init script .

I kind of forget that we're on linux here

thanks!

[damaru]

Expanding on the init script - is it possible to disable the screensaver from that script?

would

lipc-set-prop com.lab126.powerd -i touchScreenSaverTimeout 1

work on k3?

[NiLuJe]

Nope, that doesn't disable screensavers, not at home right now, check the lipc-probe output for powerd. Once you have the right prop, just make sure your script starts after powerd, and you should be okay .

[twobob]

Disable screensaver:
lipc-set-prop com.lab126.powerd preventScreenSaver 1
Enable screensaver:
lipc-set-prop com.lab126.powerd preventScreenSaver 0

[silver18]

Originally Posted by NiLuJe

Wrapping up everything in tests is a good way to avoid everything blowing up if something's missing/wrong/broken.

Could you please explain this a little bit? Thanks!

[NiLuJe]

@silver18: Upstart runs its script portions more or less like a shell in 'honor return codes' (-e) mode. Meaning if *any* part of the script returns a non-zero return code, the full script/job will fail. Which might possibly halts the boot process, I'm not familiar enough with upstart and the job tree on the Kindle to be definitive on that, and I don't really want to be, so I just handle it with a touch of paranoia .

In the OP's examples, that means that if the file it tries to run doesn't exist, it'll fail to start the job, possibly not very gracefully, possibly halting the boot process.

So, simple workaround, check that the file exists before running it, (and eventually return 0 at the end for extra paranoia ^^):

exec /bin/bash /var/local/dev/somescript.sh

=>

[ -f /var/local/dev/somescript.sh ] && exec /bin/bash /var/local/dev/somescript.sh

Also, on a sidenote, I have no idea if relying on 'exec' in the script potion of an upstart job is safe at all. I'd just live with the fork, and just run it relying on the shebang.

[damaru]

That got resolve over IRC couldn't wait

continuing on launching a script on boot on k3, I would need a tad of help on it, I've createa a /etc/init.d/myscript file that launch the script in /mnt/us/documents/

both script are chmod +x and the script in the /mnt/us/documents works no problem when launched by itself then I should add a soft link in the rc5.d but I am not too sure how to call it?

like it should be S but then the number could be anything higher than what is there already? and I should also ln -s for the rc0 for when it stops?

Am I making thing way too complexe here? (or making any sense at all)