1DBUS-DAEMON(1) User Commands DBUS-DAEMON(1)
2
6 dbus-daemon - Message bus daemon
7
9 dbus-daemon
10 dbus-daemon [--version] [--session] [--system] [--config-file=FILE]
12 [--print-address [=DESCRIPTOR]] [--print-pid [=DESCRIPTOR]]
13 [--fork]
14
17 dbus-daemon is the D-Bus message bus daemon. See
18 http://www.freedesktop.org/software/dbus/ for more information about
19 the big picture. D-Bus is first a library that provides one-to-one
20 communication between any two applications; dbus-daemon is an
21 application that uses this library to implement a message bus daemon.
22 Multiple programs connect to the message bus daemon and can exchange
23 messages with one another.
24 There are two standard message bus instances: the systemwide message
26 bus (installed on many systems as the "messagebus" init service) and
27 the per-user-login-session message bus (started each time a user logs
28 in). dbus-daemon is used for both of these instances, but with a
29 different configuration file.
30 The --session option is equivalent to
32 "--config-file=/usr/share/dbus-1/session.conf" and the --system option
33 is equivalent to "--config-file=/usr/share/dbus-1/system.conf". By
34 creating additional configuration files and using the --config-file
35 option, additional special-purpose message bus daemons could be
36 created.
37 The systemwide daemon is normally launched by an init script,
39 standardly called simply "messagebus".
40 The systemwide daemon is largely used for broadcasting system events,
42 such as changes to the printer queue, or adding/removing devices.
43 The per-session daemon is used for various interprocess communication
45 among desktop applications (however, it is not tied to X or the GUI in
46 any way).
47 SIGHUP will cause the D-Bus daemon to PARTIALLY reload its
49 configuration file and to flush its user/group information caches. Some
50 configuration changes would require kicking all apps off the bus; so
51 they will only take effect if you restart the daemon. Policy changes
52 should take effect with SIGHUP.
53
55 The following options are supported:
56 --config-file=FILE
58 Use the given configuration file.
59 --fork
61 Force the message bus to fork and become a daemon, even if the
62 configuration file does not specify that it should. In most
63 contexts the configuration file already gets this right, though.
64 This option is not supported on Windows.
65 --nofork
67 Force the message bus not to fork and become a daemon, even if the
68 configuration file specifies that it should. On Windows, the
69 dbus-daemon never forks, so this option is allowed but does
70 nothing.
71 --print-address[=DESCRIPTOR]
73 Print the address of the message bus to standard output, or to the
74 given file descriptor. This is used by programs that launch the
75 message bus.
76 --print-pid[=DESCRIPTOR]
78 Print the process ID of the message bus to standard output, or to
79 the given file descriptor. This is used by programs that launch the
80 message bus.
81 --session
83 Use the standard configuration file for the per-login-session
84 message bus.
85 --system
87 Use the standard configuration file for the systemwide message bus.
88 --version
90 Print the version of the daemon.
91 --introspect
93 Print the introspection information for all D-Bus internal
94 interfaces.
95 --address[=ADDRESS]
97 Set the address to listen on. This option overrides the address
98 configured in the configuration file.
99 --systemd-activation
101 Enable systemd-style service activation. Only useful in conjunction
102 with the systemd system and session manager on Linux.
103 --nopidfile
105 Don't write a PID file even if one is configured in the
106 configuration files.
107
109 A message bus daemon has a configuration file that specializes it for a
110 particular application. For example, one configuration file might set
111 up the message bus to be a systemwide message bus, while another might
112 set it up to be a per-user-login-session bus.
113 The configuration file also establishes resource limits, security
115 parameters, and so forth.
116 The configuration file is not part of any interoperability
118 specification and its backward compatibility is not guaranteed; this
119 document is documentation, not specification.
120 The standard systemwide and per-session message bus setups are
122 configured in the files "/usr/share/dbus-1/system.conf" and
123 "/usr/share/dbus-1/session.conf". These files normally <include> a
124 system-local.conf or session-local.conf in /etc/dbus-1; you can put
125 local overrides in those files to avoid modifying the primary
126 configuration files.
127 The configuration file is an XML document. It must have the following
129 doctype declaration:
130 <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
133 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
134 The following elements may be present in the configuration file.
137 · <busconfig>
139 Root element.
141 · <type>
143 The well-known type of the message bus. Currently known values are
145 "system" and "session"; if other values are set, they should be either
146 added to the D-Bus specification, or namespaced. The last <type>
147 element "wins" (previous values are ignored). This element only
148 controls which message bus specific environment variables are set in
149 activated clients. Most of the policy that distinguishes a session bus
150 from the system bus is controlled from the other elements in the
151 configuration file.
152 If the well-known type of the message bus is "session", then the
154 DBUS_STARTER_BUS_TYPE environment variable will be set to "session" and
155 the DBUS_SESSION_BUS_ADDRESS environment variable will be set to the
156 address of the session bus. Likewise, if the type of the message bus is
157 "system", then the DBUS_STARTER_BUS_TYPE environment variable will be
158 set to "system" and the DBUS_SESSION_BUS_ADDRESS environment variable
159 will be set to the address of the system bus (which is normally well
160 known anyway).
161 Example: <type>session</type>
163 · <include>
165 Include a file <include>filename.conf</include> at this point. If the
167 filename is relative, it is located relative to the configuration file
168 doing the including.
169 <include> has an optional attribute "ignore_missing=(yes|no)" which
171 defaults to "no" if not provided. This attribute controls whether it's
172 a fatal error for the included file to be absent.
173 · <includedir>
175 Include all files in <includedir>foo.d</includedir> at this point.
177 Files in the directory are included in undefined order. Only files
178 ending in ".conf" are included.
179 This is intended to allow extension of the system bus by particular
181 packages. For example, if CUPS wants to be able to send out
182 notification of printer queue changes, it could install a file to
183 /usr/share/dbus-1/system.d or /etc/dbus-1/system.d that allowed all
184 apps to receive this message and allowed the printer daemon user to
185 send it.
186 · <user>
188 The user account the daemon should run as, as either a username or a
190 UID. If the daemon cannot change to this UID on startup, it will exit.
191 If this element is not present, the daemon will not change or care
192 about its UID.
193 The last <user> entry in the file "wins", the others are ignored.
195 The user is changed after the bus has completed initialization. So
197 sockets etc. will be created before changing user, but no data will be
198 read from clients before changing user. This means that sockets and PID
199 files can be created in a location that requires root privileges for
200 writing.
201 · <fork>
203 If present, the bus daemon becomes a real daemon (forks into the
205 background, etc.). This is generally used rather than the --fork
206 command line option.
207 · <keep_umask>
209 If present, the bus daemon keeps its original umask when forking. This
211 may be useful to avoid affecting the behavior of child processes.
212 · <syslog>
214 If present, the bus daemon will log to syslog.
216 · <pidfile>
218 If present, the bus daemon will write its pid to the specified file.
220 The --nopidfile command-line option takes precedence over this setting.
221 · <allow_anonymous>
223 If present, connections that authenticated using the ANONYMOUS
225 mechanism will be authorized to connect. This option has no practical
226 effect unless the ANONYMOUS mechanism has also been enabled using the
227 <auth> element, described below.
228 · <listen>
230 Add an address that the bus should listen on. The address is in the
232 standard D-Bus format that contains a transport name plus possible
233 parameters/options.
234 Example: <listen>unix:path=/tmp/foo</listen>
236 Example: <listen>tcp:host=localhost,port=1234</listen>
238 If there are multiple <listen> elements, then the bus listens on
240 multiple addresses. The bus will pass its address to started services
241 or other interested parties with the last address given in <listen>
242 first. That is, apps will try to connect to the last <listen> address
243 first.
244 tcp sockets can accept IPv4 addresses, IPv6 addresses or hostnames. If
246 a hostname resolves to multiple addresses, the server will bind to all
247 of them. The family=ipv4 or family=ipv6 options can be used to force it
248 to bind to a subset of addresses
249 Example: <listen>tcp:host=localhost,port=0,family=ipv4</listen>
251 A special case is using a port number of zero (or omitting the port),
253 which means to choose an available port selected by the operating
254 system. The port number chosen can be obtained with the --print-address
255 command line parameter and will be present in other cases where the
256 server reports its own address, such as when DBUS_SESSION_BUS_ADDRESS
257 is set.
258 Example: <listen>tcp:host=localhost,port=0</listen>
260 tcp/nonce-tcp addresses also allow a bind=hostname option, used in a
262 listenable address to configure the interface on which the server will
263 listen: either the hostname is the IP address of one of the local
264 machine's interfaces (most commonly 127.0.0.1), a DNS name that
265 resolves to one of those IP addresses, '0.0.0.0' to listen on all IPv4
266 interfaces simultaneously, or '::' to listen on all IPv4 and IPv6
267 interfaces simultaneously (if supported by the OS). If not specified,
268 the default is the same value as "host".
269 Example: <listen>tcp:host=localhost,bind=0.0.0.0,port=0</listen>
271 · <auth>
273 Lists permitted authorization mechanisms. If this element doesn't
275 exist, then all known mechanisms are allowed. If there are multiple
276 <auth> elements, all the listed mechanisms are allowed. The order in
277 which mechanisms are listed is not meaningful.
278 Example: <auth>EXTERNAL</auth>
280 Example: <auth>DBUS_COOKIE_SHA1</auth>
282 · <servicedir>
284 Adds a directory to scan for .service files. Directories are scanned
286 starting with the first to appear in the config file (the first
287 .service file found that provides a particular service will be used).
288 Service files tell the bus how to automatically start a program. They
290 are primarily used with the per-user-session bus, not the systemwide
291 bus.
292 · <standard_session_servicedirs/>
294 <standard_session_servicedirs/> is equivalent to specifying a series of
296 <servicedir/> elements for each of the data directories in the "XDG
297 Base Directory Specification" with the subdirectory "dbus-1/services",
298 so for example "/usr/share/dbus-1/services" would be among the
299 directories searched.
300 The "XDG Base Directory Specification" can be found at
302 http://freedesktop.org/wiki/Standards/basedir-spec if it hasn't moved,
303 otherwise try your favorite search engine.
304 The <standard_session_servicedirs/> option is only relevant to the
306 per-user-session bus daemon defined in /etc/dbus-1/session.conf.
307 Putting it in any other configuration file would probably be nonsense.
308 · <standard_system_servicedirs/>
310 <standard_system_servicedirs/> specifies the standard system-wide
312 activation directories that should be searched for service files. This
313 option defaults to /usr/share/dbus-1/system-services.
314 The <standard_system_servicedirs/> option is only relevant to the
316 per-system bus daemon defined in /usr/share/dbus-1/system.conf. Putting
317 it in any other configuration file would probably be nonsense.
318 · <servicehelper/>
320 <servicehelper/> specifies the setuid helper that is used to launch
322 system daemons with an alternate user. Typically this should be the
323 dbus-daemon-launch-helper executable in located in libexec.
324 The <servicehelper/> option is only relevant to the per-system bus
326 daemon defined in /usr/share/dbus-1/system.conf. Putting it in any
327 other configuration file would probably be nonsense.
328 · <limit>
330 <limit> establishes a resource limit. For example:
332 <limit name="max_message_size">64</limit>
334 <limit name="max_completed_connections">512</limit>
335 The name attribute is mandatory. Available limit names are:
337 "max_incoming_bytes" : total size in bytes of messages
339 incoming from a single connection
340 "max_incoming_unix_fds" : total number of unix fds of messages
341 incoming from a single connection
342 "max_outgoing_bytes" : total size in bytes of messages
343 queued up for a single connection
344 "max_outgoing_unix_fds" : total number of unix fds of messages
345 queued up for a single connection
346 "max_message_size" : max size of a single message in
347 bytes
348 "max_message_unix_fds" : max unix fds of a single message
349 "service_start_timeout" : milliseconds (thousandths) until
350 a started service has to connect
351 "auth_timeout" : milliseconds (thousandths) a
352 connection is given to
353 authenticate
354 "pending_fd_timeout" : milliseconds (thousandths) a
355 fd is given to be transmitted to
356 dbus-daemon before disconnecting the
357 connection
358 "max_completed_connections" : max number of authenticated connections
359 "max_incomplete_connections" : max number of unauthenticated
360 connections
361 "max_connections_per_user" : max number of completed connections from
362 the same user
363 "max_pending_service_starts" : max number of service launches in
364 progress at the same time
365 "max_names_per_connection" : max number of names a single
366 connection can own
367 "max_match_rules_per_connection": max number of match rules for a single
368 connection
369 "max_replies_per_connection" : max number of pending method
370 replies per connection
371 (number of calls-in-progress)
372 "reply_timeout" : milliseconds (thousandths)
373 until a method call times out
374 The max incoming/outgoing queue sizes allow a new message to be queued
376 if one byte remains below the max. So you can in fact exceed the max by
377 max_message_size.
378 max_completed_connections divided by max_connections_per_user is the
380 number of users that can work together to denial-of-service all other
381 users by using up all connections on the systemwide bus.
382 Limits are normally only of interest on the systemwide bus, not the
384 user session buses.
385 · <policy>
387 The <policy> element defines a security policy to be applied to a
389 particular set of connections to the bus. A policy is made up of
390 <allow> and <deny> elements. Policies are normally used with the
391 systemwide bus; they are analogous to a firewall in that they allow
392 expected traffic and prevent unexpected traffic.
393 Currently, the system bus has a default-deny policy for sending method
395 calls and owning bus names. Everything else, in particular reply
396 messages, receive checks, and signals has a default allow policy.
397 In general, it is best to keep system services as small, targeted
399 programs which run in their own process and provide a single bus name.
400 Then, all that is needed is an <allow> rule for the "own" permission to
401 let the process claim the bus name, and a "send_destination" rule to
402 allow traffic from some or all uids to your service.
403 The <policy> element has one of four attributes:
405 context="(default|mandatory)"
407 at_console="(true|false)"
408 user="username or userid"
409 group="group name or gid"
410 Policies are applied to a connection as follows:
412 - all context="default" policies are applied
414 - all group="connection's user's group" policies are applied
415 in undefined order
416 - all user="connection's auth user" policies are applied
417 in undefined order
418 - all at_console="true" policies are applied
419 - all at_console="false" policies are applied
420 - all context="mandatory" policies are applied
421 Policies applied later will override those applied earlier, when the
423 policies overlap. Multiple policies with the same user/group/context
424 are applied in the order they appear in the config file.
425 <deny>
427 <allow>
428 A <deny> element appears below a <policy> element and prohibits some
430 action. The <allow> element makes an exception to previous <deny>
431 statements, and works just like <deny> but with the inverse meaning.
432 The possible attributes of these elements are:
434 send_interface="interface_name"
436 send_member="method_or_signal_name"
437 send_error="error_name"
438 send_destination="name"
439 send_type="method_call" | "method_return" | "signal" | "error"
440 send_path="/path/name"
441 receive_interface="interface_name"
443 receive_member="method_or_signal_name"
444 receive_error="error_name"
445 receive_sender="name"
446 receive_type="method_call" | "method_return" | "signal" | "error"
447 receive_path="/path/name"
448 send_requested_reply="true" | "false"
450 receive_requested_reply="true" | "false"
451 eavesdrop="true" | "false"
453 own="name"
455 own_prefix="name"
456 user="username"
457 group="groupname"
458 Examples:
460 <deny send_destination="org.freedesktop.Service" send_interface="org.freedesktop.System" send_member="Reboot"/>
462 <deny send_destination="org.freedesktop.System"/>
463 <deny receive_sender="org.freedesktop.System"/>
464 <deny user="john"/>
465 <deny group="enemies"/>
466 The <deny> element's attributes determine whether the deny "matches" a
468 particular action. If it matches, the action is denied (unless later
469 rules in the config file allow it).
470 send_destination and receive_sender rules mean that messages may not be
472 sent to or received from the *owner* of the given name, not that they
473 may not be sent *to that name*. That is, if a connection owns services
474 A, B, C, and sending to A is denied, sending to B or C will not work
475 either.
476 The other send_* and receive_* attributes are purely textual/by-value
478 matches against the given field in the message header.
479 "Eavesdropping" occurs when an application receives a message that was
481 explicitly addressed to a name the application does not own, or is a
482 reply to such a message. Eavesdropping thus only applies to messages
483 that are addressed to services and replies to such messages (i.e. it
484 does not apply to signals).
485 For <allow>, eavesdrop="true" indicates that the rule matches even when
487 eavesdropping. eavesdrop="false" is the default and means that the rule
488 only allows messages to go to their specified recipient. For <deny>,
489 eavesdrop="true" indicates that the rule matches only when
490 eavesdropping. eavesdrop="false" is the default for <deny> also, but
491 here it means that the rule applies always, even when not
492 eavesdropping. The eavesdrop attribute can only be combined with send
493 and receive rules (with send_* and receive_* attributes).
494 The [send|receive]_requested_reply attribute works similarly to the
496 eavesdrop attribute. It controls whether the <deny> or <allow> matches
497 a reply that is expected (corresponds to a previous method call
498 message). This attribute only makes sense for reply messages (errors
499 and method returns), and is ignored for other message types.
500 For <allow>, [send|receive]_requested_reply="true" is the default and
502 indicates that only requested replies are allowed by the rule.
503 [send|receive]_requested_reply="false" means that the rule allows any
504 reply even if unexpected.
505 For <deny>, [send|receive]_requested_reply="false" is the default but
507 indicates that the rule matches only when the reply was not requested.
508 [send|receive]_requested_reply="true" indicates that the rule applies
509 always, regardless of pending reply state.
510 user and group denials mean that the given user or group may not
512 connect to the message bus.
513 For "name", "username", "groupname", etc. the character "*" can be
515 substituted, meaning "any." Complex globs like "foo.bar.*" aren't
516 allowed for now because they'd be work to implement and maybe encourage
517 sloppy security anyway.
518 <allow own_prefix="a.b"/> allows you to own the name "a.b" or any name
520 whose first dot-separated elements are "a.b": in particular, you can
521 own "a.b.c" or "a.b.c.d", but not "a.bc" or "a.c". This is useful when
522 services like Telepathy and ReserveDevice define a meaning for subtrees
523 of well-known names, such as
524 org.freedesktop.Telepathy.ConnectionManager.(anything) and
525 org.freedesktop.ReserveDevice1.(anything).
526 It does not make sense to deny a user or group inside a <policy> for a
528 user or group; user/group denials can only be inside context="default"
529 or context="mandatory" policies.
530 A single <deny> rule may specify combinations of attributes such as
532 send_destination and send_interface and send_type. In this case, the
533 denial applies only if both attributes match the message being denied.
534 e.g. <deny send_interface="foo.bar" send_destination="foo.blah"/> would
535 deny messages with the given interface AND the given bus name. To get
536 an OR effect you specify multiple <deny> rules.
537 You can't include both send_ and receive_ attributes on the same rule,
539 since "whether the message can be sent" and "whether it can be
540 received" are evaluated separately.
541 Be careful with send_interface/receive_interface, because the interface
543 field in messages is optional. In particular, do NOT specify <deny
544 send_interface="org.foo.Bar"/>! This will cause no-interface messages
545 to be blocked for all services, which is almost certainly not what you
546 intended. Always use rules of the form: <deny
547 send_interface="org.foo.Bar" send_destination="org.foo.Service"/>
548 · <selinux>
550 The <selinux> element contains settings related to Security Enhanced
552 Linux. More details below.
553 · <associate>
555 An <associate> element appears below an <selinux> element and creates a
557 mapping. Right now only one kind of association is possible:
558 <associate own="org.freedesktop.Foobar" context="foo_t"/>
560 This means that if a connection asks to own the name
562 "org.freedesktop.Foobar" then the source context will be the context of
563 the connection and the target context will be "foo_t" - see the short
564 discussion of SELinux below.
565 Note, the context here is the target context when requesting a name,
567 NOT the context of the connection owning the name.
568 There's currently no way to set a default for owning any name, if we
570 add this syntax it will look like:
571 <associate own="*" context="foo_t"/>
573 If you find a reason this is useful, let the developers know. Right now
575 the default will be the security context of the bus itself.
576 If two <associate> elements specify the same name, the element
578 appearing later in the configuration file will be used.
579 · <apparmor>
581 The <apparmor> element is used to configure AppArmor mediation on the
583 bus. It can contain one attribute that specifies the mediation mode:
584 <apparmor mode="(enabled|disabled|required)"/>
586 The default mode is "enabled". In "enabled" mode, AppArmor mediation
588 will be performed if AppArmor support is available in the kernel. If it
589 is not available, dbus-daemon will start but AppArmor mediation will
590 not occur. In "disabled" mode, AppArmor mediation is disabled. In
591 "required" mode, AppArmor mediation will be enabled if AppArmor support
592 is available, otherwise dbus-daemon will refuse to start.
593 The AppArmor mediation mode of the bus cannot be changed after the bus
595 starts. Modifying the mode in the configuration file and sending a
596 SIGHUP signal to the daemon has no effect on the mediation mode.
597
599 See http://www.nsa.gov/selinux/ for full details on SELinux. Some
600 useful excerpts:
601 Every subject (process) and object (e.g. file, socket, IPC object, etc)
603 in the system is assigned a collection of security attributes, known as
604 a security context. A security context contains all of the security
605 attributes associated with a particular subject or object that are
606 relevant to the security policy.
607 In order to better encapsulate security contexts and to provide greater
609 efficiency, the policy enforcement code of SELinux typically handles
610 security identifiers (SIDs) rather than security contexts. A SID is an
611 integer that is mapped by the security server to a security context at
612 runtime.
613 When a security decision is required, the policy enforcement code
615 passes a pair of SIDs (typically the SID of a subject and the SID of an
616 object, but sometimes a pair of subject SIDs or a pair of object SIDs),
617 and an object security class to the security server. The object
618 security class indicates the kind of object, e.g. a process, a regular
619 file, a directory, a TCP socket, etc.
620 Access decisions specify whether or not a permission is granted for a
622 given pair of SIDs and class. Each object class has a set of associated
623 permissions defined to control operations on objects with that class.
624 D-Bus performs SELinux security checks in two places.
626 First, any time a message is routed from one connection to another
628 connection, the bus daemon will check permissions with the security
629 context of the first connection as source, security context of the
630 second connection as target, object class "dbus" and requested
631 permission "send_msg".
632 If a security context is not available for a connection (impossible
634 when using UNIX domain sockets), then the target context used is the
635 context of the bus daemon itself. There is currently no way to change
636 this default, because we're assuming that only UNIX domain sockets will
637 be used to connect to the systemwide bus. If this changes, we'll
638 probably add a way to set the default connection context.
639 Second, any time a connection asks to own a name, the bus daemon will
641 check permissions with the security context of the connection as
642 source, the security context specified for the name in the config file
643 as target, object class "dbus" and requested permission "acquire_svc".
644 The security context for a bus name is specified with the <associate>
646 element described earlier in this document. If a name has no security
647 context associated in the configuration file, the security context of
648 the bus daemon itself will be used.
649
651 The AppArmor confinement context is stored when applications connect to
652 the bus. The confinement context consists of a label and a confinement
653 mode. When a security decision is required, the daemon uses the
654 confinement context to query the AppArmor policy to determine if the
655 action should be allowed or denied and if the action should be audited.
656 The daemon performs AppArmor security checks in three places.
658 First, any time a message is routed from one connection to another
660 connection, the bus daemon will check permissions with the label of the
661 first connection as source, label and/or connection name of the second
662 connection as target, along with the bus name, the path name, the
663 interface name, and the member name. Reply messages, such as
664 method_return and error messages, are implicitly allowed if they are in
665 response to a message that has already been allowed.
666 Second, any time a connection asks to own a name, the bus daemon will
668 check permissions with the label of the connection as source, the
669 requested name as target, along with the bus name.
670 Third, any time a connection attempts to eavesdrop, the bus daemon will
672 check permissions with the label of the connection as the source, along
673 with the bus name.
674 AppArmor rules for bus mediation are not stored in the bus
676 configuration files. They are stored in the application's AppArmor
677 profile. Please see apparmor.d(5) for more details.
678
680 If you're trying to figure out where your messages are going or why you
681 aren't getting messages, there are several things you can try.
682 Remember that the system bus is heavily locked down and if you haven't
684 installed a security policy file to allow your message through, it
685 won't work. For the session bus, this is not a concern.
686 The simplest way to figure out what's happening on the bus is to run
688 the dbus-monitor program, which comes with the D-Bus package. You can
689 also send test messages with dbus-send. These programs have their own
690 man pages.
691 If you want to know what the daemon itself is doing, you might consider
693 running a separate copy of the daemon to test against. This will allow
694 you to put the daemon under a debugger, or run it with verbose output,
695 without messing up your real session and system daemons.
696 To run a separate test copy of the daemon, for example you might open a
698 terminal and type:
699 DBUS_VERBOSE=1 dbus-daemon --session --print-address
701 The test daemon address will be printed when the daemon starts. You
703 will need to copy-and-paste this address and use it as the value of the
704 DBUS_SESSION_BUS_ADDRESS environment variable when you launch the
705 applications you want to test. This will cause those applications to
706 connect to your test bus instead of the DBUS_SESSION_BUS_ADDRESS of
707 your real session bus.
708 DBUS_VERBOSE=1 will have NO EFFECT unless your copy of D-Bus was
710 compiled with verbose mode enabled. This is not recommended in
711 production builds due to performance impact. You may need to rebuild
712 D-Bus if your copy was not built with debugging in mind. (DBUS_VERBOSE
713 also affects the D-Bus library and thus applications using D-Bus; it
714 may be useful to see verbose output on both the client side and from
715 the daemon.)
716 If you want to get fancy, you can create a custom bus configuration for
718 your test bus (see the session.conf and system.conf files that define
719 the two default configurations for example). This would allow you to
720 specify a different directory for .service files, for example.
721
723 See http://www.freedesktop.org/software/dbus/doc/AUTHORS
724
726 Please send bug reports to the D-Bus mailing list or bug tracker, see
727 http://www.freedesktop.org/software/dbus/
728D-Bus 1.10.24 03/14/2019 DBUS-DAEMON(1)