devel/dbus no longer starts at system poweron

[Kevin Oberman]

On Mon, Mar 2, 2015 at 12:53 PM, Jeffrey Bouquet via freebsd-ports <
freebsd-ports at freebsd.org> wrote:

>
> On 03/02/15 06:57, Beeblebrox wrote:
> >>> Using dbus-1.8.12, /etc/rc.conf has (dbus_enable="YES",
> >>> slim_enable="YES"). This works no more. X.Org starts, but cannot
> >>> login to any Desktop because dbus actually is not running and has
> >>> not started.
> >>>
> >>> Kill Xorg, then manually "service onestart" dbus, and slim.
> >>> I can then start to my desktop managers.
> >> what do dmesg and /var/log/messages say?
> >> Erich
> > This problem was resolved some time back (through an update I believe)
> but is now back. No error message is registered in /var/log/messages or any
> other log. However, combing through the output on TTY0, I found this:
> > Starting dbus
> > Shared object 'libexpat.so.1' not found required by 'dbus-daemon'
> > /etc/rc: WARNING: failed to start dbus
> >
> > After system is booted, form any TTY*, "# service dbus onestart" results
> in normal startup. Not setting any dbus_flags and not using gdm_enable.
> >
> > # pkg info -l expat > expat-2.1.0_2:
> > /usr/local/bin/xmlwf
> > /usr/local/include/expat.h
> > /usr/local/include/expat_external.h
> > /usr/local/lib/libexpat.a
> > /usr/local/lib/libexpat.so
> > /usr/local/lib/libexpat.so.1
> > /usr/local/lib/libexpat.so.1.6.0
> > /usr/local/lib/libexpat.so.6
> > /usr/local/libdata/pkgconfig/expat.pc
> > /usr/local/man/man1/xmlwf.1.gz
> > (files separately confirmed with ls /usr/local/lib/*expat*)
> >
> I've the same problem
> (libexpat and dbus-daemon)
> and posted to the freebsd-current list a few days ago.
> Rebuilt every dependency...  etc.
> One other port also does not start *uuid* ...
>

This is almost certainly  an issue with a circular dependency in the
startup scripts. The immediate problem is that things that require non-base
dependencies are starting before ldconfig is run (started?).

I have noted a circular dependency between dbus and webcamd. I have not had
time to track it down. These are a real pain to track down as you need to
examine the full dependency graph to be sure of finding the issue. You can
check for circular dependencies with the command:
rcorder /etc/rc.d/* /usr/local/etc/rc.d/* > /dev/null
This only reports the errors (if any), not the cause.

To track that down the actual cause, you will likely have to dig through
the full output (no "> /dev/null"). Circular dependencies result in
undefined behavior and the ordering can be changed radically in very
unexpected ways by adding/updating/deleting ports. Minor changes to
rcorder.c could also change these.

I think the best answer is to provide an option to have rcorder print the
full dependency tree for all ports involved in the circular dependency so
it can be more easily tracked. I have no idea how difficult this might be,
but, without examining the code, it looks like it should not be too hard.
(Easily said by someone who can read but not really write decent C code.)
--
Kevin Oberman, Network Engineer, Retired
E-mail: rkoberman at gmail.com