GNOME.org
 

Re: [Tracker] Tracker on Solaris

On 24/01/13 14:37, Frank Lahm wrote:

Hi Martyn,


Hello,


Yes, I do. We have a main service controller process called 'netatalk'
which then starts (forks() and execs() other services) a root dbus
daemon.
I start it with ''--config-file=/PATH/TO/dbus-session.conf" as
arguments. dbus-session.conf contains:

---8<---
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
  "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd";>
<busconfig>
   <!-- Our well-known bus type, don't change this -->
   <type>session</type>

   <!-- If we fork, keep the user's original umask to avoid affecting
        the behavior of child processes. -->
   <keep_umask/>

   <listen>unix:path=/tmp/spotlight.ipc</listen>
<!--
   <allow_anonymous />
-->
   <standard_session_servicedirs />

   <policy context="default">
     <!-- Allow everything to be sent -->
     <allow send_destination="*" eavesdrop="true"/>
     <!-- Allow everything to be received -->
     <allow eavesdrop="true"/>
     <!-- Allow anyone to own anything -->
     <allow own="*"/>
   </policy>

   <!-- raise the service start timeout to 40 seconds as it can timeout
        on the live cd on slow machines -->
   <limit name="service_start_timeout">60000</limit>
   <limit name="reply_timeout">10000</limit>

   <!-- Config files are placed here that among other things,
        further restrict the above policy for specific services. -->
   <includedir>/etc/dbus-1/session.d</includedir>

   <!-- This is included last so local configuration can override
what's
        in this standard file -->
   <include ignore_missing="yes">session-local.conf</include>

   <include if_selinux_enabled="yes"
selinux_root_relative="yes">contexts/dbus_contexts</include>

   <!-- For the session bus, override the default relatively-low limits
        with essentially infinite limits, since the bus is just running
        as the user anyway, using up bus resources is not something we
need
        to worry about. In some cases, we do set the limits lower than
        "all available memory" if exceeding the limit is almost
certainly a bug,
        having the bus enforce a limit is nicer than a huge memory
leak. But the
        intent is that these limits should never be hit. -->

   <!-- the memory limits are 1G instead of say 4G because they can't
exceed 32-bit signed int max -->
   <limit name="max_incoming_bytes">1000000000</limit>
   <limit name="max_outgoing_bytes">1000000000</limit>
   <limit name="max_message_size">1000000000</limit>
   <limit name="service_start_timeout">120000</limit>
   <limit name="auth_timeout">240000</limit>
   <limit name="max_completed_connections">100000</limit>
   <limit name="max_incomplete_connections">10000</limit>
   <limit name="max_connections_per_user">100000</limit>
   <limit name="max_pending_service_starts">10000</limit>
   <limit name="max_names_per_connection">50000</limit>
   <limit name="max_match_rules_per_connection">50000</limit>
   <limit name="max_replies_per_connection">50000</limit>

</busconfig>
---8<---


I didn't see anything out of the obvious wrong with the above.


That should be just boilerplate besived the obvious modificaiton of
the listen directive and the "attempt" to allow anonymous auth. I'm
saying "attempt", because as on Solaris I had to remove/comment out
the directive because the dbus-daemon version on Solaris (1.2.28)
didn't recognize it. Otoh, I have to add it on Linux, otherwise the
dbus IPC doesn't work too.
Well, depending on your distro on Linux you might, but I've never had to set up dbus extensively this way on Linux at least. 


root solaris:~# /opt/tracker/bin/tracker\-control -s

Starting miners?
(tracker-control:15040): Tracker-CRITICAL **: Could not create proxy
on the D-Bus session bus, Error calling StartServiceByName for
org.freedesktop.Tracker1.Miner.Applications:
GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process
/opt/tracker/libexec/tracker-miner-fs exited with status 1
    ? File System (perhaps a disabled plugin?)

(tracker-control:15040): Tracker-CRITICAL **: No D-Bus proxy found for
miner 'org.freedesktop.Tracker1.Miner.Applications'
    ? Applications (perhaps a disabled plugin?)

I've pasted some the results of some debugging to pastie.org:

Using tracker-sandbox:

    <http://pastie.org/private/jvxvvg4ciwg2kibv6nuq1g>

Running libexec/tracker-miner-fs -v 3 -n:

    <http://pastie.org/private/jp8j0cdvy24lskokn4nncg>



Yea, it seems we can't create our session on the bus. This leads me to a few
questions:

1. Was the name taken? - Usually we would get an error for that case, but I
would check anyway.


I would if I knew how... :/


Well, one clue is in the error you reported in the links above:

"""
Could not acquire name:'org.freedesktop.Tracker1.Miner.Applications'. The connection is closed' 
"""
But it's slightly different to what I would expect. Here if it's already running I get: 

"""
Couldn't create new Files miner: 'D-Bus service name:'org.freedesktop.Tracker1.Miner.Files' is already taken, perhaps the application is already running?' 
"""
This could be the difference between DBus or Tracker versions though. The later is much more descriptive. 


2. Does the daemon with that address exist and is it running?


Yes. As mentioned before I either use tracker-sandbox or the netatalk
service controller for running an instance of dbus-daemon and either
way I make sure DBUS_SESSION_BUS_ADDRESS is set correct:
I think I had problems with my sandbox script because if you start the miner-fs and that starts the store, then the dbus-daemon's environment is what is used for the dbus connection. This was problematic for me because one was initiated by me directly and the other by the daemon, the environments meant that the two never connected properly. That sounds likely too here. It's partly why I started my own sandbox script too. 


---8<---
root solaris:~# echo $DBUS_SESSION_BUS_ADDRESS
unix:path=/tmp/spotlight.ipc
root solaris:~# /opt/tracker/bin/tracker-control -S
Store:
24 Jan 2013, 15:32:37:  â     Store                - Idle

Miners:
24 Jan 2013, 15:32:37:  â     Dateisystem          - Not running or is
a disabled plugin
24 Jan 2013, 15:32:37:  â     Anwendungen          - Not running or is
a disabled plugin

root solaris:~# ps auxwww | grep tracker
root      8223  0.1  0.23940019184 ?        S 15:32:03  0:00
/opt/tracker/libexec/tracker-store
root      8269  0.0  0.0 8908 1456 pts/3    S 15:32:57  0:00 grep tracker
---8<---
Note that tracker-store IS running, just not the miners.


Yea. Are you starting the store via the miner-fs instigation? or yourself?


3. Are you able to test other dbus programs with your session and can they
"register"?


I'm really new to dbus, could you give me a hint at an example program?
Yea, you can try the server/client here (might be out of date, and needs Python): 

  http://cgit.freedesktop.org/dbus/dbus-python/tree/examples


A test program to do this should be only a few lines of code.


Well, ok, lets get down and dirty. By chance, can you share a link to
a good online ressource or similar.


Try the above first ;)


The errors look quite endemic of environment or set up issues, but I am
speculating based on experience.


Hm. Thanks for you help so far!
No problem. My script is a bit broken here otherwise I would share it to see if it helps you.
One thing I didn't do is use the same approach that Sam did, i.e. using dbus-launch. Instead I used dbus-daemon and set the environment up around that first. This allowed me more control over the script and processes I started with a consistent environment I found.
If you're still stuck, I can clean it up and share it. I need to add it somewhere anyway :) 

--
Regards,
Martyn

Founder and CEO of Lanedo GmbH.
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]