Tiny Core Base > TCB Talk

hacking .X.d

(1/7) > >>

jur:
I have the following stuff in .X.d:

in a file called mystuff:

--- Code: ---( 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 &

--- End code ---
In a file called desktop:

--- Code: ---conky &
tint2 &

--- End code ---
in a file called iptables:

--- Code: ---loadapp iptables
sudo basic-firewall

--- End code ---

loadapp script:

--- Code: ---#!/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

--- End code ---


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: --- popup Downloading "$THIS_APP"... &
POPUP_PID=$!
tce-load -w "$THIS_APP"
kill $POPUP_PID

--- End code ---
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).

Navigation

[0] Message Index

[#] Next page