hacking .X.d

[jur]

I have the following stuff in .X.d:

in a file called mystuff:

Code: [Select]

( loadapp volumeicon && volumeicon & ) &
loadapp hwmon-2.6.33.3-tinycore.tcz &
loadapp pci-hotplug-2.6.33.3-tinycore.tcz &
#( loadapp acpid.tcz && sudo /usr/local/etc/init.d/acpid start ) &
# loadapp filesystems-2.6.33.3-tinycore.tcz &
loadapp hicolor-icon-theme.tcz &
loadapp v4l-dvb-2.6.33.3-tinycore.tcz &
loadapp gtk2_prefs &
loadapp zenity &

updates &
amixer sset 'Master' 64 >/dev/null &
amixer sset 'Headphone' 55 >/dev/null &
amixer sset 'Speaker' 55 >/dev/null &
In a file called desktop:

Code: [Select]

conky &
tint2 &
in a file called iptables:

Code: [Select]

loadapp iptables
sudo basic-firewall

loadapp script:

Code: [Select]

#!/bin/sh
[ -z "$1" ] && echo "Usage: loadapp <extension>[.tcz]" && exit 1
TCE_DIR=`cat /opt/.tce_dir`
THIS_APP=$(basename $1 .tcz)

if [ ! -f "$TCE_DIR"/optional/"$THIS_APP".tcz ]; then
popup Downloading "$THIS_APP"... &
tce-load -w "$THIS_APP"
killall popup
fi
if [ ! -f /usr/local/tce.installed/"$THIS_APP" ]; then
tce-load -i"$NOICON" "$TCE_DIR"/optional/"$THIS_APP"
fi
exit 0


My problem is, all the stuff is not being loaded reliably. Especially conky and tint2 sometimes do not start. I start these manually afterwards with no problem. And most of the time it works. I have noticed this behaviour a long time already , from the beginning of introduction of .X.d but because I can't find a reliable way of reproducing it, I have held off reporting.

conky and tint2 used to be loaded in .X.d using loadapp but were not reliable. I have tried improving things by moving them to OnBoot. That hasn't improved things so I moved these two items to their own file, again with no improvement.

[gerald_clark]

What a mess.
.X.d is for starting X applications.
Put your extensions in onboot.lst.

.X.d scripts will run every time X is started, not once per system load.

[jur]

I started using iptables last night; now conky and tint2 reliably do not start.

[jur]

Taking heed of gerald_clark's unhelpful remark, I moved mystuff out of .X.d.

Conky and tint2 in combination with iptables do not load.

[maro]

jur: You might find it to be strongly worded what gerald_clark wrote, but my initial thought on seeing your "mystuff" was fairly similar.

First off you are way to liberal with using '&' (i.e. sending a process to the background). There is always the risk of race conditions when doing that to the degree you are (mis-)using it. Your last two paragraphs in your OP are almost a perfect description of how race conditions are observed by a user (i.e. unreliable, hard to reproduce, ...). In my view you let an awful lot of tasks basically started all at once without paying attention to which event depends on what other events as precondition.

So lets start from first principles: Be very clear for each process from where in the startup sequence it should be started. That means '/opt/bootsync.sh' for system wide things that need to be executed (once per startup as 'root') before '/opt/bootlocal.sh' (which runs asychronously). As gerald_clark has already pointed out: '~/.X.d' scripts are run every time the X server starts, so ensure for those that should run only once that this is the case.

I think you should start from scratch and create a script for each task (e.g. to run 'conky') that contains all preconditions in that script (e.g. to download the extension(s), if not already downloaded, then to install, if not already installed, and finally to execute if not already running).

Another "eyesore" in my view is how you use 'killall' in your "loadapp". As all things are for you running basically in parallel the first process that reaches a 'killall' does so for ALL the popup processes (and not just for the one that should be terminated). Here is a code snippet (albeit untested) that should do the "proper" thing:

Code: [Select]

popup Downloading "$THIS_APP"... &
POPUP_PID=$!
tce-load -w "$THIS_APP"
kill $POPUP_PID
Now I personally don't see a real need for having all those "popups" anyway. If you want it for monitoring purposes I believe adding messages to a unique, temporary log-files (e.g. "/tmp/loadapp.$$.log") to be much better.

I believe that you will have to resolve all your race conditions first. Only after that should you focus on any remaining issues. My hunch is that there won't be any issues left (providing you do it right).

[jur]

Boiling it down to what actually happens... loadapp does not download stuff and does not killall popups at boot... all the extensions being loaded are already present so ignore that.

So, what I effectively have is, assuming stuff is done alphabetically:

Code: [Select]

conky &
tint2 &
tce-load -i iptables
sudo basic-firewall

and that does not seem to work.

(Note that tint2 and conky HAVE to be backgrounded.)

[tinypoodle]

I couldn't see how X apps like conky & tint2 versus iptables (which has the firewall modules as a dependency) and a firewall script could be related.

[maro]

Please split things into separate scripts which contain sufficient checks and can be run (and tested) independently:

So (as one example) create a '~/.X.d/conky' with:

Code: [Select]

#!/bin/sh
which conky > /dev/null || ! date '+%T: conky not found" >> /tmp/conky_$$.log || exit 2
conky &

I assume that running conky & from an interactive shell works as expected.

[jur]

.X.d scripts are not preceded by #!/bin/sh

regarding my "liberal" use of '&', I recall that roberts wrote that stuff called in .X.d have to be backgrounded, that's the only reason I did it (except for conky and tint2).

(Why check for the presence of conky? it is loaded OnBoot.)

[gerald_clark]

(Why check for the presence of conky? it is loaded OnBoot.)

Because it is good programming practice.
The scripts in .X.d have no knowledge of what is or is not in .onboot.lst

[jur]

Regarding loading my apps in .X.d, I like to be at my desktop as quickly as possible at boot. So what's wrong with loading extensions which are not immediately needed a bit later (ie during .X.d)? bootlocal.sh can't be used. And there is no other startup provision.

[tinypoodle]

It has been very clearly (IMHO) stated by gerald_clark and then by maro (quoting gerald_clark) what is wrong.
You might actually lose time on each subsequent start of X, left alone potential unpredictable consequences.

Wondering what your most optimistic estimation of gaining time at boot is, and if it ever could sum up to the time invested of hacking boot sequence (I'd highly doubt it).

[danielibarnes]

So, what I effectively have is, assuming stuff is done alphabetically:

I wouldn't assume that. Create one script which does what you want in the order you want to be safe. Use functions to separate code like "loadapp".

Code: [Select]

conky &
tint2 &
tce-load -i iptables
sudo basic-firewall

and that does not seem to work.

I made a script called ~/.X.d/stuff with exactly the above and it worked every time. Can you confirm this duplicates your procedure? I did not reboot in between attempts, so I simply executed "startx" then exited back to the prompt. There are only a couple of things on which I might comment:

• basic-firewall includes a "read" command. I don't know if reading from the console might interfere with something. You might try sudo basic-firewall < /dev/null
• you only need to start iptables once, but it does no harm to attempt it every time because the basic-firewall script resets to a known state when executed.

[jur]

It has been very clearly (IMHO) stated by gerald_clark and then by maro (quoting gerald_clark) what is wrong.
You might actually lose time on each subsequent start of X, left alone potential unpredictable consequences.

Bull.

1. gerald_clark stated the obvious. Wasn't helpful at all.
2. maro didn't quote gerald_clark.
3. Backgrounding was stated by roberts as being necessary for commands in .X.d - I was merely doing what he said should be done.

The only reason I started this thread and what you are losing sight of, is that conky and tint2 do not start reliable. These are both X apps. Both are started according to their recommended use, and in .X.d which it is meant for.

I found that these 2 are not reliable, and stated this here, and produced a set of commands that reproduce this condition. The problem is not iptables nor is it the so-called mess that gerald_clark so unkindly referred to. The problem is conky and tint2.

And I do not lose time on each subsequent start of X. My loadapp script checks before doing stuff.

[roberts]

Cannot reproduce. Works as expected. The order of launching the two mentioned X programs, conky and tint2,  had no bearing. The order by default is not alpha and should not matter.

Tested three ways:
1.  the order as per the find clause (see find .X.d/ -type f).
2. wedging in a | sort  to ensure an alpha ordering (see find .X.d/ -type f | sort ).
3. wedging in a | sort -r to ensure a reverse alpha sort (see find .X.d/ -type f | sort -r).

No failures were observed both when exiting X and  startx as well as rebooting.

These tests were conducted with the recommended and supported methods of using Tiny Core.
That is not trying to background load multiple extensions. Much effort has been put forth to ensure the proper loading of extension. Using .xsession is not recommended. The backgrounding to launch loaded X programs within xsession is.

.X.d/tint2
  tint2 &
.X.d/conky
  conky &

If further information can be supplied, sans any custom scripts or background extension loading within .xsession/.X.d,  that can document such a claim, I will gladly look further.