Adverse Effect of Change to dbus Extention

[SamK]

Having applied the most recent update of dbus.tgz, two apps fail to start (Firefox and File-Roller).  Both apps were working entirely satisfactorily before the update.  To resolve the issue the previous version of dbus has been restored.

The current version of dbus requires that it is started manually, where the previous version started automatically.  This gives rise to the following questions and observations:

Outwardly, this change 'breaks' an otherwise working system.  Would it not be preferable to explicitly seek the end user's agreement before doing this?

Is it not possible (during installation) to ask the user if automatic starting is to be retained?

When an app is not explicitly requested to be installed, but is added as a dependency, might it be reasonable to assume that it is required to be started in order to allow the parent app to function.

This appears to be a retrograde step in terms of the usability of TC in that both experienced and inexperienced users now have to realize that a dependent has to be manually started or added to a script in order to continue to use their apps.

I would favour a default of being automatically started with the ability to deactivate (onboot?).  This will allow advanced users the management/control they may require, while being more friendly to the less advanced user.

[Juanito]

Several users have said that they want daemons to be started when an extension is loaded and several users have have said that they do not want daemons to be started when an extension is loaded.

Rather than use an earlier version of the dbus extension, you can add a line to bootlocal.sh to start dbus, or other daemons on boot.

Thought is being given on how to handle this matter to most users satisfaction - as an example, having an extension auto-start a daemon on loading gave problems with recursive dependencies in some circumstances.

[Jason W]

I have been one to push for the use of init.d scripts to start daemons to give the user control over what processes are running.  And our true recursive dep loading does not allow the use of the tce.installed startup script to start daemons like dbus. 

We simply need a way to have extensions autostart their init.d scripts if desired.  I have several ways in mind.  I will take the blame for this not so smooth transition as I have pushed for the use of init.d scripts to start daemons with.

[gerald_clark]

Jason,

Until something better comes up, here is what I use to manage services.
I use a file /etc/services/.lst that lists services to run in the order desired.
I use "/opt/services start" to start the services, and "/opt/services stop" to
stop them in the reverse order.

I add "/opt/services start" to bootlocal.sh, and "/opt/services stop" to shutdown.sh.

Code: [Select]

# services
# Start/Stop services
# Read service list from /opt/.services
# services start starts services in the order listed
# services stop  stops  services in reverse order
#
SERVICE_LST=/opt/services.lst
SERVICE_RUN=/tmp/services.run   

if [ "$1" == "start" ] ; then
   rm -rf $SERVICE_RUN
   mkdir -p $SERVICE_RUN 2>/dev/null
   grep -v "^#" $SERVICE_LST | while read PROG
   do
       echo "$PROG start"
      $PROG start
       echo $PROG > $SERVICE_RUN/${PROG##*/}
       sleep 1
   done
elif [ "$1" == "stop" ] ; then
   ls -ctr $SERVICE_RUN | while read PROGNAME
   do
       PROG=`cat $SERVICE_RUN/$PROGNAME`
       echo "$PROG stop"
      $PROG stop
   done   
elif [ "$1" == "list" ] ; then
   cat $SERVICE_RUN/*
else
   echo "$0 : Invalid option $1"
   echo "$0 start/stop/list"
fi


Code: [Select]

# services.lst
/usr/local/etc/init.d/nfs-client
/usr/local/etc/init.d/alsasound
/usr/local/etc/init.d/nfs-server


[SamK]

Rather than use an earlier version of the dbus extension, you can add a line to bootlocal.sh to start dbus, or other daemons on boot.

Thanks for this suggestion - it had also been made during discussions in the irc channel.  It does, however, re-emphasise one of the the points I made previously.  It is a workable solution to the issue but is a rather obscure requirement to fulfill in order to conduct a simple task of running Firefox.  Doing this may not be questioned by TC veterans but may well defeat newcomers to the distro.

I decided to post in this section of the forum as the matter is due to an extension.  I wondered if it should have been posted in a different section as the effect is in my view, detrimental to TC (the distro) rather than just the particular extension.

From the perspective of  someone new to TC being unable to install and run a widely used browser without research and editing of the underlying files is likely to have a detrimental effect on the appeal and take-up of TC.

Thought is being given on how to handle this matter...

We simply need a way to have extensions autostart their init.d scripts if desired.  I have several ways in mind.

This is encouraging to learn.  Without being in any way contentious, might it be worthwhile delaying the dbus and similar changes until this has been introduced.   If not, it might be polite to explicitly obtain the users agreement and offer an option to decline the update. Once the autostart system has been resolved the warning could be removed and the update applied at that time.

[Jason W]

As I have yet to study up on the recursion used due to recent lack of time, I spoke too soon.  Order of dependency loading is and will be preserved, so dbus can be started by it's startup script.  We will fix this.

[Jason W]

bmarkus has updated wicd, and I have put the needed commands into the namoroka.tcz startup script to get the dbus info that it needs.  If there are other extensions that need dbus started or dbus info obtained for it to run, please list it here and it will be dealt with.  Namoroka does not need dbus running, it just needs a dbus command to acquire machine info, and that action is now in the startup script..  Same with Firefox.

[SamK]

If there are other extensions that need dbus started or dbus info obtained for it to run, please list it here and it will be dealt with.

File-Roller and Brasero are my first thoughts for this.

This is an extremely impressive response.  Many thanks.

[Jason W]

Fileroller and brasero also seem to simply need the machine id and not dbus running.  I hope Arslan does not mind I go ahead and add the commands to the startup scripts while I am fixing Firefox and Namaroka.

[Jason W]

On second thought, his existing startup scripts are complex and better for him to fix.

[Arslan S.]

not that complex will have a look

[Jason W]

I just rather you insert the commands where you want them in the script.  Thanks.

[Jason W]

And here is the command to insert in startup scripts for extensions that do not need dbus running but just need the machine id:

[ -d /var/lib/dbus ] || mkdir -p /var/lib/dbus
[ -f /var/lib/dbus/machine-id ] || dbus-uuidgen --ensure=/var/lib/dbus/machine-id

[Jason W]

This is the list of extensions that have a dbus extension as a dependency.  They will need to be reviewed as to whether they need dbus started for them to run or just the machine-id.    I will start looking into them when I get home tonight.

Code: [Select]

akonadi.tcz
avahi.tcz
bluez-gnome.tcz
bluez.tcz
brasero-dev.tcz
brasero-locale.tcz
brasero.tcz
chromium-browser-i686-locale.tcz
chromium-browser-i686.tcz
chromium-browser-locale.tcz
cups1311.tcz
dbus-glib.tcz
dbus_python-2.5.2.tcz
dbus-python.tcz
dropbox.tcz
eggdbus.tcz
file-roller-locale.tcz
file-roller.tcz
firefox.tcz
GConf-defaults-service.tcz
GConf-dev.tcz
GConf-locale.tcz
GConf.tcz
gnome-media.tcz
gnome-python.tcz
gst-plugins-good-locale.tcz
gst-plugins-good.tcz
hal-dev.tcz
hal.tcz
hplip_sane.tcz
hplip.tcz
icecat.tcz
libbonobo-locale.tcz
libbonobo.tcz
libgdata-dev.tcz
libgdata-locale.tcz
libgdata.tcz
libgnome-keyring.tcz
libgnome.tcz
libgsf-gnome.tcz
liblazy.tcz
libnotify.tcz
libphonon.tcz
libpolkit-gobject.tcz
libsoup-gnome.tcz
libunique-dev.tcz
libunique.tcz
midori.tcz
namoroka.tcz
obex.tcz
orage-locale.tcz
orage.tcz
parole-locale.tcz
parole.tcz
qjackctl.tcz
rhythmbox.tcz
ristretto-locale.tcz
ristretto.tcz
rygel.tcz
seamonkey.tcz
soprano.tcz
strigi.tcz
suspend.tcz
Terminal-locale.tcz
Terminal.tcz
thunderbird3.tcz
totem-locale.tcz
totem.tcz
wicd-locale.tcz
wicd.tcz
xfce4-appfinder.tcz
Xfce4base-locale.tcz
Xfce4base.tcz
xfce4-cpufreq-plugin.tcz
xfce4-gtk-engine.tcz
xfce4-mixer-locale.tcz
xfce4-mixer.tcz
xfce4-power-manager-locale.tcz
xfce4-power-manager.tcz
xfce4-screenshooter.tcz
xfce4-taskmanager-locale.tcz
xfce4-taskmanager.tcz
xfce4-weather-plugin.tcz
xfwm4-themes.tcz
xulrunner-dev.tcz
xulrunner.tcz
zenity-locale.tcz
zenity.tcz


[Jason W]

Since the list is large, perhaps we could add the machine-id commands to the dbus.tcz startup script to save a lot of trouble.  That way dbus info is there to satisfy many extensions, and save the need to add these lines to all the other startup scripts.  But at the same time we are not starting dbus until we need it if that is the desired goal.