[Solved] what boot step executes scripts in /usr/local/tce.installed?

[GNUser]

I am trying to understand how these three parts of the boot process are kept in order:

1. Extensions listed in onboot.lst are loaded
2. mydata.tcz is restored
3. Scripts in /usr/local/tce.installed/ are executed

I looked at  /etc/init.d/tc-config  and I see where it takes care of step 1 (line 565* I think) and where it takes care of step 2 (line 624* I think). For the life of me I can't find what takes care of step 3. Does anyone know?

* /etc/init.d/tc-config of TCL13 alpha1 x86_64

[Paul_123]

tce-setup  processes onboot.lst, and calls tce-load for each extension.

[Rich]

Hi GNUser
When  tce-load  is called with the -b (BOOTING) option, it does not process the  tce.installed  script if it exists. It
echos the extensions name into  /tmp/setup.lst  for later execution by  tce-setup.

[GNUser]

Hi GNUser
When  tce-load  is called with the -b (BOOTING) option, it does not process the  tce.installed  script if it exists. It
echos the extensions name into  /tmp/setup.lst  for later execution by  tce-setup.

Thank you, Rich! The -b option to tce-load was the key. Now I understand how tce-load knows to behave differently during boot (during boot it postpones execution of tce.installed scripts until after mydata.tcz has been restored). Very cool

[GNUser]

Hi, Rich. Sorry to pester you, but I don't quite get it yet.
I see this in tce-setup (line 83):

Code: [Select]

tce-load -i -b -t `dirname $1` $applistPresumably that's where the onboot.lst extensions are loaded, with  -b  option telling tce-load to defer execution of tce.installed scripts.

Further down in tce-setup (line 171) I see this:

Code: [Select]

for F in `cat /tmp/setup.lst`; do "$F"; done
Presumably that's where the deferred tce.installed scripts are executed.

Somewhere between those two steps I would expect to see something that makes  tce-setup  wait for mydata.tgz to be restored, but I can't find it

[Rich]

Hi GNUser
It appears restore occurs near the end of  /etc/init.d/tc-config. Look for  tc-restore.sh.

[GNUser]

Right. What I don't get is this:
- tc-config calls tce-setup (on line 565), which takes care of steps #1 and #3 in my original post
- then tc-config calls tc-restore.sh (on line 624), which takes care of step #2 in my original post

So it seems that the steps occur in this order: #1, #3, #2...
...when we all know the order in which things actually happen is #1, #2, #3

Oh, well. There is no problem to solve here. I was just hoping to understand how this works.

If anyone knows the secret sauce that makes the boot process ensure step #2 is performed before step #3, please share. If I find it myself I will share.

[Rich]

Hi GNUser

...when we all know the order in which things actually happen is #1, #2, #3 ...

Really? I'm pretty sure restore happens last allowing it to override everything else. If you look at  tc-config:

Code: [Select]

        /usr/bin/tce-setup "booting" > /dev/null 2>&1 &
        rotdash $!The first line launches  tce-setup  in the background.
The  $!  is the PID assigned to  tce-setup.  rotdash blocks  tc-config  by displaying a rotating line ( \ | / - ) until
tce-setup  finishes.

Try this:

Code: [Select]

sleep 5 &  rotdash $!rotdash will block the command prompt from displaying until the sleep command completes.

[GNUser]

Really? I'm pretty sure restore happens last allowing it to override everything else. If you look at  tc-config...

Wow. My assumption was that tce.installed happened last so that user's config files are restored before any tce.installed scripts auto-launch services. I was so sure of my assumption that I thought I was misunderstanding something in the logic of the boot scripts. Rich, thank you very much for helping me get past my incorrect assumption.

If I ever put together an extension for some kind of service/daemon, I will need to remember this thread. I guess it is individual tce.installed scripts' responsibility to check if they are running during boot and, if so, to wait until after user's config files have been restored before they launch any services/daemons.

Is there a tried-and-true approach that  tce.installed  scripts use to ensure that user's data has been restored? Does the user data restoration step generate some kind of marker file? If not, perhaps  tce.installed  scripts could check if  tc-config  is running and, if so, wait for it to no longer be running.

[Rich]

Hi GNUser

... I guess it is individual tce.installed scripts' responsibility to check if they are running during boot and, if so, to wait until after user's config files have been restored before they launch any services/daemons. ...

I think it's up to the user to start services if and when they need them. They can start them via bootsync.sh,
bootlocal.sh, ~/.X.d, or the  Services  app found in ControlPanel and the popup menu under  SystemTools.
I start openssh, alsa, and dbus in bootlocal.sh. I start nfs from ~/.X.d.

... perhaps  tce.installed  scripts could check if  tc-config  is running and, if so, wait for it to no longer be running.

Don't do that. You'll block the remaining scripts from running and slow things down. Remember fontconfig:
http://forum.tinycorelinux.net/index.php/topic,23333.msg146167.html#msg146167

I think you may be over thinking this. Typically the startup scripts create directories/files they need in  /home/$USER,  or
creates an extra link to  /user/local  because some program was hardcoded to use  /user.  Sometimes they run commands
to update icon or font caches, or to  chmod/chown  of files or directories.

If you look through the files that don't have zero length in  /user/local/tc.installed/ , you can see the type of activity
that usually takes place.

[GNUser]

I think it's up to the user to start services if and when they need them.
...
Don't do that. You'll block the remaining scripts from running and slow things down. Remember fontconfig:
http://forum.tinycorelinux.net/index.php/topic,23333.msg146167.html#msg146167
...
I think you may be over thinking this.

Excellent advice all around, thank you. And good memory regarding the fontconfig issue! And, yes, it seems I'm overthinking this

We can mark this thread as solved

P.S. One of the things I like about a running TCL machine is that there are no mysterious services/daemons running in the background. The TCL user's high-level impression is that the computer does only exactly what the user asked for--no more, no less.

[Rich]

Hi GNUser

... We can mark this thread as solved ...

Done.