1dbus-daemon(1)              General Commands Manual             dbus-daemon(1)
2
3
4

NAME

6       dbus-daemon - Message bus daemon
7

SYNOPSIS

9       dbus-daemon  dbus-daemon  [--version] [--session] [--system] [--config-
10       file=FILE]  [--print-address[=DESCRIPTOR]]   [--print-pid[=DESCRIPTOR]]
11       [--fork]
12
13

DESCRIPTION

15       dbus-daemon  is  the D-Bus message bus daemon. See http://www.freedesk
16       top.org/software/dbus/ for more information about the big  picture.  D-
17       Bus  is  first a library that provides one-to-one communication between
18       any two applications; dbus-daemon is  an  application  that  uses  this
19       library to implement a message bus daemon. Multiple programs connect to
20       the message bus daemon and can exchange messages with one another.
21
22
23       There are two standard message bus instances:  the  systemwide  message
24       bus  (installed  on  many systems as the "messagebus" init service) and
25       the per-user-login-session message bus (started each time a  user  logs
26       in).   dbus-daemon is used for both of these instances, but with a dif‐
27       ferent configuration file.
28
29
30       The --session option is equivalent  to  "--config-file=/etc/dbus-1/ses‐
31       sion.conf"   and  the  --system  option  is  equivalent  to  "--config-
32       file=/etc/dbus-1/system.conf".  By  creating  additional  configuration
33       files  and  using  the --config-file option, additional special-purpose
34       message bus daemons could be created.
35
36
37       The systemwide daemon is normally launched by  an  init  script,  stan‐
38       dardly called simply "messagebus".
39
40
41       The  systemwide  daemon is largely used for broadcasting system events,
42       such as changes to the printer queue, or adding/removing devices.
43
44
45       The per-session daemon is used for various  interprocess  communication
46       among  desktop applications (however, it is not tied to X or the GUI in
47       any way).
48
49
50       SIGHUP will cause the D-Bus daemon to PARTIALLY reload  its  configura‐
51       tion file and to flush its user/group information caches. Some configu‐
52       ration changes would require kicking all apps off the bus; so they will
53       only  take effect if you restart the daemon. Policy changes should take
54       effect with SIGHUP.
55
56

OPTIONS

58       The following options are supported:
59
60       --config-file=FILE
61              Use the given configuration file.
62
63       --fork Force the message bus to fork and become a daemon, even  if  the
64              configuration  file  does  not  specify that it should.  In most
65              contexts the configuration file already gets this right, though.
66
67       --print-address[=DESCRIPTOR]
68              Print the address of the message bus to standard output,  or  to
69              the  given file descriptor. This is used by programs that launch
70              the message bus.
71
72       --print-pid[=DESCRIPTOR]
73              Print the process ID of the message bus to standard  output,  or
74              to  the  given  file  descriptor.  This is used by programs that
75              launch the message bus.
76
77       --session
78              Use the standard configuration file  for  the  per-login-session
79              message bus.
80
81       --system
82              Use  the  standard configuration file for the systemwide message
83              bus.
84
85       --version
86              Print the version of the daemon.
87
88

CONFIGURATION FILE

90       A message bus daemon has a configuration file that specializes it for a
91       particular  application.  For example, one configuration file might set
92       up the message bus to be a systemwide message bus, while another  might
93       set it up to be a per-user-login-session bus.
94
95
96       The  configuration  file  also  establishes  resource  limits, security
97       parameters, and so forth.
98
99
100       The configuration file is not part of any  interoperability  specifica‐
101       tion and its backward compatibility is not guaranteed; this document is
102       documentation, not specification.
103
104
105       The standard systemwide and per-session message bus setups are  config‐
106       ured  in  the  files  "/etc/dbus-1/system.conf"  and  "/etc/dbus-1/ses‐
107       sion.conf".  These files normally <include> a system-local.conf or ses‐
108       sion-local.conf;  you  can  put local overrides in those files to avoid
109       modifying the primary configuration files.
110
111
112       The configuration file is an XML document. It must have  the  following
113       doctype declaration:
114
115          <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
116           "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
117
118
119
120       The following elements may be present in the configuration file.
121
122
123       <busconfig>
124
125
126       Root element.
127
128
129       <type>
130
131
132       The  well-known  type  of  the  message bus. Currently known values are
133       "system" and "session"; if other values are set, they should be  either
134       added  to the D-Bus specification, or namespaced.  The last <type> ele‐
135       ment "wins" (previous values are ignored). This element  only  controls
136       which  message  bus specific environment variables are set in activated
137       clients.  Most of the policy that distinguishes a session bus from  the
138       system  bus  is controlled from the other elements in the configuration
139       file.
140
141
142       If the well-known type of  the  message  bus  is  "session",  then  the
143       DBUS_STARTER_BUS_TYPE environment variable will be set to "session" and
144       the DBUS_SESSION_BUS_ADDRESS environment variable will be  set  to  the
145       address  of  the session bus.  Likewise, if the type of the message bus
146       is "system", then the DBUS_STARTER_BUS_TYPE environment  variable  will
147       be  set  to "system" and the DBUS_SESSION_BUS_ADDRESS environment vari‐
148       able will be set to the address of the system bus  (which  is  normally
149       well known anyway).
150
151
152       Example: <type>session</type>
153
154
155       <include>
156
157
158       Include  a file <include>filename.conf</include> at this point.  If the
159       filename is relative, it is located relative to the configuration  file
160       doing the including.
161
162
163       <include>  has  an  optional  attribute "ignore_missing=(yes|no)" which
164       defaults to "no" if not provided. This attribute controls whether  it's
165       a fatal error for the included file to be absent.
166
167
168       <includedir>
169
170
171       Include  all  files  in  <includedir>foo.d</includedir>  at this point.
172       Files in the directory are included in  undefined  order.   Only  files
173       ending in ".conf" are included.
174
175
176       This  is  intended  to  allow extension of the system bus by particular
177       packages. For example, if CUPS wants to be able to send  out  notifica‐
178       tion   of   printer   queue   changes,  it  could  install  a  file  to
179       /etc/dbus-1/system.d that allowed all apps to receive this message  and
180       allowed the printer daemon user to send it.
181
182
183       <user>
184
185
186       The  user  account  the daemon should run as, as either a username or a
187       UID. If the daemon cannot change to this UID on startup, it will  exit.
188       If  this  element  is  not  present, the daemon will not change or care
189       about its UID.
190
191
192       The last <user> entry in the file "wins", the others are ignored.
193
194
195       The user is changed after the bus  has  completed  initialization.   So
196       sockets  etc. will be created before changing user, but no data will be
197       read from clients before changing user. This means that sockets and PID
198       files  can  be  created in a location that requires root privileges for
199       writing.
200
201
202       <fork>
203
204
205       If present, the bus daemon becomes a real daemon (forks into the  back‐
206       ground,  etc.).  This  is generally used rather than the --fork command
207       line option.
208
209
210       <keep_umask>
211
212
213       If present, the bus daemon keeps its original umask when forking.  This
214       may be useful to avoid affecting the behavior of child processes.
215
216
217       <listen>
218
219
220       Add  an  address  that  the bus should listen on. The address is in the
221       standard D-Bus format that contains  a  transport  name  plus  possible
222       parameters/options.
223
224
225       Example: <listen>unix:path=/tmp/foo</listen>
226
227
228       Example: <listen>tcp:host=localhost,port=1234</listen>
229
230
231       If there are multiple <listen> elements, then the bus listens on multi‐
232       ple addresses. The bus will pass its address  to  started  services  or
233       other interested parties with the last address given in <listen> first.
234       That is, apps will try to connect to the last <listen> address first.
235
236
237       tcp sockets can accept IPv4 addresses, IPv6 addresses or hostnames.  If
238       a  hostname resolves to multiple addresses, the server will bind to all
239       of them. The family=ipv4 or family=ipv6 options can be used to force it
240       to bind to a subset of addresses
241
242
243       Example: <listen>tcp:host=localhost,port=0,family=ipv4</listen>
244
245
246       A  special  case is using a port number of zero (or omitting the port),
247       which means to choose an available port selected by the operating  sys‐
248       tem.  The  port  number chosen can be obtained with the --print-address
249       command line parameter and will be present in  other  cases  where  the
250       server  reports  its own address, such as when DBUS_SESSION_BUS_ADDRESS
251       is set.
252
253
254       Example: <listen>tcp:host=localhost,port=0</listen>
255
256
257       tcp addresses also allow a bind=hostname option,  which  will  override
258       the  host  option  specifying what address to bind to, without changing
259       the address reported by the bus. The bind option can also take  a  spe‐
260       cial  name  '*'  to  cause  the  bus  to  listen  on  all local address
261       (INADDR_ANY). The specified host should be a valid name  of  the  local
262       machine or weird stuff will happen.
263
264
265       Example: <listen>tcp:host=localhost,bind=*,port=0</listen>
266
267
268       <auth>
269
270
271       Lists  permitted  authorization  mechanisms.  If  this  element doesn't
272       exist, then all known mechanisms are allowed.  If  there  are  multiple
273       <auth>  elements,  all the listed mechanisms are allowed.  The order in
274       which mechanisms are listed is not meaningful.
275
276
277       Example: <auth>EXTERNAL</auth>
278
279
280       Example: <auth>DBUS_COOKIE_SHA1</auth>
281
282
283       <servicedir>
284
285
286       Adds a directory to scan for .service files.  Directories  are  scanned
287       starting with the last to appear in the config file (the first .service
288       file found that provides a particular service will be used).
289
290
291       Service files tell the bus how to automatically start a program.   They
292       are  primarily  used  with the per-user-session bus, not the systemwide
293       bus.
294
295
296       <standard_session_servicedirs/>
297
298
299       <standard_session_servicedirs/> is equivalent to specifying a series of
300       <servicedir/>  elements  for  each  of the data directories in the "XDG
301       Base Directory Specification" with the subdirectory  "dbus-1/services",
302       so for example "/usr/share/dbus-1/services" would be among the directo‐
303       ries searched.
304
305
306       The "XDG Base Directory Specification" can be found at http://freedesk
307       top.org/wiki/Standards/basedir-spec  if  it hasn't moved, otherwise try
308       your favorite search engine.
309
310
311       The <standard_session_servicedirs/> option is only relevant to the per-
312       user-session bus daemon defined in /etc/dbus-1/session.conf. Putting it
313       in any other configuration file would probably be nonsense.
314
315
316       <standard_system_servicedirs/>
317
318
319       <standard_system_servicedirs/> specifies the standard system-wide acti‐
320       vation  directories  that  should  be searched for service files.  This
321       option defaults to /usr/share/dbus-1/system-services.
322
323
324       The <standard_system_servicedirs/> option is only relevant to the  per-
325       system bus daemon defined in /etc/dbus-1/system.conf. Putting it in any
326       other configuration file would probably be nonsense.
327
328
329       <servicehelper/>
330
331
332       <servicehelper/> specifies the setuid helper that  is  used  to  launch
333       system  daemons  with  an  alternate user. Typically this should be the
334       dbus-daemon-launch-helper executable in located in libexec.
335
336
337       The <servicehelper/> option is only relevant to the per-system bus dae‐
338       mon defined in /etc/dbus-1/system.conf. Putting it in any other config‐
339       uration file would probably be nonsense.
340
341
342       <limit>
343
344
345       <limit> establishes a resource limit. For example:
346         <limit name="max_message_size">64</limit>
347         <limit name="max_completed_connections">512</limit>
348
349
350       The name attribute is mandatory.  Available limit names are:
351             "max_incoming_bytes"         : total size in bytes of messages
352                                            incoming from a single connection
353             "max_outgoing_bytes"         : total size in bytes of messages
354                                            queued up for a single connection
355             "max_message_size"           : max size of a single message in
356                                            bytes
357             "service_start_timeout"      : milliseconds (thousandths) until
358                                            a started service has to connect
359             "auth_timeout"               : milliseconds (thousandths) a
360                                            connection is given to
361                                            authenticate
362             "max_completed_connections"  : max number of authenticated connections
363             "max_incomplete_connections" : max number of unauthenticated
364                                            connections
365             "max_connections_per_user"   : max number of completed connections from
366                                            the same user
367             "max_pending_service_starts" : max number of service launches in
368                                            progress at the same time
369             "max_names_per_connection"   : max number of names a single
370                                            connection can own
371             "max_match_rules_per_connection": max number of match rules for a single
372                                               connection
373             "max_replies_per_connection" : max number of pending method
374                                            replies per connection
375                                            (number of calls-in-progress)
376             "reply_timeout"              : milliseconds (thousandths)
377                                            until a method call times out
378
379
380       The max incoming/outgoing queue sizes allow a new message to be  queued
381       if one byte remains below the max. So you can in fact exceed the max by
382       max_message_size.
383
384
385       max_completed_connections divided by  max_connections_per_user  is  the
386       number  of  users that can work together to denial-of-service all other
387       users by using up all connections on the systemwide bus.
388
389
390       Limits are normally only of interest on the  systemwide  bus,  not  the
391       user session buses.
392
393
394       <policy>
395
396
397       The  <policy> element defines a security policy to be applied to a par‐
398       ticular set of connections to the bus. A policy is made up  of  <allow>
399       and  <deny>  elements.  Policies  are normally used with the systemwide
400       bus; they are analogous to a firewall in that they allow expected traf‐
401       fic and prevent unexpected traffic.
402
403
404       Currently,  the system bus has a default-deny policy for sending method
405       calls and owning bus names.  Everything else, in particular reply  mes‐
406       sages, receive checks, and signals has a default allow policy.
407
408
409       In  general, it is best to keep system services as small, targeted pro‐
410       grams which run in their own process and provide  a  single  bus  name.
411       Then, all that is needed is an <allow> rule for the "own" permission to
412       let the process claim the bus name, and a  "send_destination"  rule  to
413       allow traffic from some or all uids to your service.
414
415
416       The <policy> element has one of four attributes: daemon.1.in
417         context="(default|mandatory)"
418         at_console="(true|false)"
419         user="username or userid"
420         group="group name or gid"
421
422
423       Policies are applied to a connection as follows:
424          - all context="default" policies are applied
425          - all group="connection's user's group" policies are applied
426            in undefined order
427          - all user="connection's auth user" policies are applied
428            in undefined order
429          - all at_console="true" policies are applied
430          - all at_console="false" policies are applied
431          - all context="mandatory" policies are applied
432
433
434       Policies  applied  later  will override those applied earlier, when the
435       policies overlap. Multiple policies with  the  same  user/group/context
436       are applied in the order they appear in the config file.
437
438
439       <deny> <allow>
440
441
442       A  <deny>  element  appears below a <policy> element and prohibits some
443       action. The <allow> element  makes  an  exception  to  previous  <deny>
444       statements, and works just like <deny> but with the inverse meaning.
445
446
447       The possible attributes of these elements are:
448          send_interface="interface_name"
449          send_member="method_or_signal_name"
450          send_error="error_name"
451          send_destination="name"
452          send_type="method_call" | "method_return" | "signal" | "error"
453          send_path="/path/name"
454
455          receive_interface="interface_name"
456          receive_member="method_or_signal_name"
457          receive_error="error_name"
458          receive_sender="name"
459          receive_type="method_call" | "method_return" | "signal" | "error"
460          receive_path="/path/name"
461
462          send_requested_reply="true" | "false"
463          receive_requested_reply="true" | "false"
464
465          eavesdrop="true" | "false"
466
467          own="name"
468          user="username"
469          group="groupname"
470
471
472       Examples:
473          <deny send_interface="org.freedesktop.System" send_member="Reboot"/>
474          <deny receive_interface="org.freedesktop.System" receive_member="Reboot"/>
475          <deny own="org.freedesktop.System"/>
476          <deny send_destination="org.freedesktop.System"/>
477          <deny receive_sender="org.freedesktop.System"/>
478          <deny user="john"/>
479          <deny group="enemies"/>
480
481
482       The  <deny> element's attributes determine whether the deny "matches" a
483       particular action. If it matches, the action is  denied  (unless  later
484       rules in the config file allow it).
485
486
487       send_destination and receive_sender rules mean that messages may not be
488       sent to or received from the *owner* of the given name, not  that  they
489       may  not be sent *to that name*. That is, if a connection owns services
490       A, B, C, and sending to A is denied, sending to B or C  will  not  work
491       either.
492
493
494       The  other  send_* and receive_* attributes are purely textual/by-value
495       matches against the given field in the message header.
496
497
498       "Eavesdropping" occurs when an application receives a message that  was
499       explicitly  addressed  to  a name the application does not own, or is a
500       reply to such a message. Eavesdropping thus only  applies  to  messages
501       that  are  addressed  to services and replies to such messages (i.e. it
502       does not apply to signals).
503
504
505       For <allow>, eavesdrop="true" indicates that the rule matches even when
506       eavesdropping. eavesdrop="false" is the default and means that the rule
507       only allows messages to go to their specified recipient.   For  <deny>,
508       eavesdrop="true"  indicates  that the rule matches only when eavesdrop‐
509       ping. eavesdrop="false" is the default for <deny>  also,  but  here  it
510       means  that  the  rule applies always, even when not eavesdropping. The
511       eavesdrop attribute can only be combined with send  and  receive  rules
512       (with send_* and receive_* attributes).
513
514
515
516       The  [send|receive]_requested_reply  attribute  works  similarly to the
517       eavesdrop attribute. It controls whether the <deny> or <allow>  matches
518       a  reply  that  is expected (corresponds to a previous method call mes‐
519       sage).  This attribute only makes sense for reply messages (errors  and
520       method returns), and is ignored for other message types.
521
522
523       For  <allow>,  [send|receive]_requested_reply="true" is the default and
524       indicates  that  only  requested  replies  are  allowed  by  the  rule.
525       [send|receive]_requested_reply="false"  means  that the rule allows any
526       reply even if unexpected.
527
528
529       For <deny>, [send|receive]_requested_reply="false" is the  default  but
530       indicates  that the rule matches only when the reply was not requested.
531       [send|receive]_requested_reply="true" indicates that the  rule  applies
532       always, regardless of pending reply state.
533
534
535       user  and  group denials mean that the given user or group may not con‐
536       nect to the message bus.
537
538
539       For "name", "username", "groupname", etc.  the  character  "*"  can  be
540       substituted,  meaning  "any."  Complex  globs  like  "foo.bar.*" aren't
541       allowed for now because they'd be work to implement and maybe encourage
542       sloppy security anyway.
543
544
545       It  does not make sense to deny a user or group inside a <policy> for a
546       user or group; user/group denials can only be inside  context="default"
547       or context="mandatory" policies.
548
549
550       A  single  <deny>  rule  may specify combinations of attributes such as
551       send_destination and send_interface and send_type. In  this  case,  the
552       denial  applies only if both attributes match the message being denied.
553       e.g. <deny send_interface="foo.bar" send_destination="foo.blah"/> would
554       deny  messages with the given interface AND the given bus name.  To get
555       an OR effect you specify multiple <deny> rules.
556
557
558       You can't include both send_ and receive_ attributes on the same  rule,
559       since  "whether  the  message  can  be  sent"  and  "whether  it can be
560       received" are evaluated separately.
561
562
563       Be careful with send_interface/receive_interface, because the interface
564       field  in  messages  is  optional.  In particular, do NOT specify <deny
565       send_interface="org.foo.Bar"/>!  This will cause no-interface  messages
566       to  be blocked for all services, which is almost certainly not what you
567       intended.   Always  use  rules   of   the   form:   <deny   send_inter‐
568       face="org.foo.Bar" send_destination="org.foo.Service"/>
569
570
571       <selinux>
572
573
574       The  <selinux>  element  contains settings related to Security Enhanced
575       Linux.  More details below.
576
577
578       <associate>
579
580
581       An <associate> element appears below an <selinux> element and creates a
582       mapping. Right now only one kind of association is possible:
583          <associate own="org.freedesktop.Foobar" context="foo_t"/>
584
585
586       This  means  that  if  a connection asks to own the name "org.freedesk‐
587       top.Foobar" then the source context will be the context of the  connec‐
588       tion  and the target context will be "foo_t" - see the short discussion
589       of SELinux below.
590
591
592       Note, the context here is the target context when  requesting  a  name,
593       NOT the context of the connection owning the name.
594
595
596       There's  currently  no  way to set a default for owning any name, if we
597       add this syntax it will look like:
598          <associate own="*" context="foo_t"/>
599       If you find a reason this is useful, let the  developers  know.   Right
600       now the default will be the security context of the bus itself.
601
602
603       If  two <associate> elements specify the same name, the element appear‐
604       ing later in the configuration file will be used.
605
606

SELinux

608       See http://www.nsa.gov/selinux/ for full details on SELinux. Some  use‐
609       ful excerpts:
610
611
612               Every  subject  (process)  and  object  (e.g. file, socket, IPC
613               object, etc) in the system is assigned a collection of security
614               attributes,  known  as  a  security context. A security context
615               contains all of the security attributes associated with a  par‐
616               ticular  subject  or  object  that are relevant to the security
617               policy.
618
619
620               In order to better encapsulate security contexts and to provide
621               greater efficiency, the policy enforcement code of SELinux typ‐
622               ically handles security identifiers (SIDs) rather than security
623               contexts.  A  SID  is an integer that is mapped by the security
624               server to a security context at runtime.
625
626
627               When a security decision is required,  the  policy  enforcement
628               code  passes a pair of SIDs (typically the SID of a subject and
629               the SID of an object, but sometimes a pair of subject SIDs or a
630               pair of object SIDs), and an object security class to the secu‐
631               rity server. The object security class indicates  the  kind  of
632               object,  e.g.  a  process,  a  regular file, a directory, a TCP
633               socket, etc.
634
635
636               Access decisions specify whether or not a permission is granted
637               for a given pair of SIDs and class. Each object class has a set
638               of associated permissions  defined  to  control  operations  on
639               objects with that class.
640
641
642       D-Bus performs SELinux security checks in two places.
643
644
645       First, any time a message is routed from one connection to another con‐
646       nection, the bus daemon will check permissions with the  security  con‐
647       text  of the first connection as source, security context of the second
648       connection as target, object  class  "dbus"  and  requested  permission
649       "send_msg".
650
651
652       If  a  security  context  is not available for a connection (impossible
653       when using UNIX domain sockets), then the target context  used  is  the
654       context  of the bus daemon itself.  There is currently no way to change
655       this default, because we're assuming that only UNIX domain sockets will
656       be used to connect to the systemwide bus. If this changes, we'll proba‐
657       bly add a way to set the default connection context.
658
659
660       Second, any time a connection asks to own a name, the bus  daemon  will
661       check  permissions  with  the  security  context  of  the connection as
662       source, the security context specified for the name in the config  file
663       as target, object class "dbus" and requested permission "acquire_svc".
664
665
666       The  security  context for a bus name is specified with the <associate>
667       element described earlier in this document.  If a name has no  security
668       context  associated  in the configuration file, the security context of
669       the bus daemon itself will be used.
670
671

DEBUGGING

673       If you're trying to figure out where your messages are going or why you
674       aren't getting messages, there are several things you can try.
675
676
677       Remember  that the system bus is heavily locked down and if you haven't
678       installed a security policy file to  allow  your  message  through,  it
679       won't work. For the session bus, this is not a concern.
680
681
682       The  simplest  way  to figure out what's happening on the bus is to run
683       the dbus-monitor program, which comes with the D-Bus package.  You  can
684       also  send  test messages with dbus-send. These programs have their own
685       man pages.
686
687
688       If you want to know what the daemon itself is doing, you might consider
689       running  a separate copy of the daemon to test against. This will allow
690       you to put the daemon under a debugger, or run it with verbose  output,
691       without messing up your real session and system daemons.
692
693
694       To run a separate test copy of the daemon, for example you might open a
695       terminal and type:
696         DBUS_VERBOSE=1 dbus-daemon --session --print-address
697
698
699       The test daemon address will be printed when  the  daemon  starts.  You
700       will need to copy-and-paste this address and use it as the value of the
701       DBUS_SESSION_BUS_ADDRESS  environment  variable  when  you  launch  the
702       applications  you  want  to test. This will cause those applications to
703       connect to your test bus instead  of  the  DBUS_SESSION_BUS_ADDRESS  of
704       your real session bus.
705
706
707       DBUS_VERBOSE=1  will  have NO EFFECT unless your copy of D-Bus was com‐
708       piled with verbose mode enabled. This is not recommended in  production
709       builds due to performance impact. You may need to rebuild D-Bus if your
710       copy was not built with debugging in mind. (DBUS_VERBOSE  also  affects
711       the  D-Bus  library and thus applications using D-Bus; it may be useful
712       to see verbose output on both the client side and from the daemon.)
713
714
715       If you want to get fancy, you can create a custom bus configuration for
716       your  test  bus (see the session.conf and system.conf files that define
717       the two default configurations for example). This would  allow  you  to
718       specify a different directory for .service files, for example.
719
720
721

AUTHOR

723       See http://www.freedesktop.org/software/dbus/doc/AUTHORS
724
725

BUGS

727       Please  send  bug reports to the D-Bus mailing list or bug tracker, see
728       http://www.freedesktop.org/software/dbus/
729
730
731
732                                                                dbus-daemon(1)
Impressum