dbus issueshttps://gitlab.freedesktop.org/dbus/dbus/-/issues2018-10-12T21:16:11Zhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/85[PATCH] two small fixes for dbus hash: remove dead code, fix comments and rem...2018-10-12T21:16:11ZBugzilla Migration User[PATCH] two small fixes for dbus hash: remove dead code, fix comments and remove redundant AND operation## Submitted by Chengwei Yang `@chengwei`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#66576)](https://bugs.freedesktop.org/show_bug.cgi?id=66576)**
## Description
Version: 1.5## Submitted by Chengwei Yang `@chengwei`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#66576)](https://bugs.freedesktop.org/show_bug.cgi?id=66576)**
## Description
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/84change spec so unknown match rule keys are ignored2018-10-15T14:29:57ZBugzilla Migration Userchange spec so unknown match rule keys are ignored## Submitted by Chengwei Yang `@chengwei`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#66114)](https://bugs.freedesktop.org/show_bug.cgi?id=66114)**
## Description
unknown key in match rule just like unknown field i...## Submitted by Chengwei Yang `@chengwei`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#66114)](https://bugs.freedesktop.org/show_bug.cgi?id=66114)**
## Description
unknown key in match rule just like unknown field in message header, to avoid compatibility issue if new key/field introduced in future, the dbus specification says "Again, if an implementation sees a header field code that it does not expect, it must ignore that field, as it will be part of a new (but compatible) version of this specification."
I think this is applicable to unknown key in match rule situation.
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/83Callback for dbus_connection_send_with_reply never is called if service answe...2018-10-12T21:16:01ZBugzilla Migration UserCallback for dbus_connection_send_with_reply never is called if service answers incorrectly## Submitted by Philip Rauwolf
Assigned to **D-Bus Maintainers**
**[Link to original bug (#65134)](https://bugs.freedesktop.org/show_bug.cgi?id=65134)**
## Description
Created attachment 79978
Possible fix for dbus-1.6.11
If the ...## Submitted by Philip Rauwolf
Assigned to **D-Bus Maintainers**
**[Link to original bug (#65134)](https://bugs.freedesktop.org/show_bug.cgi?id=65134)**
## Description
Created attachment 79978
Possible fix for dbus-1.6.11
If the dbus iteration is done via "dbus_connection_read_write_dispatch",
and any asynchronous method call message with timeout was sent (via "dbus_connection_send_with_reply"), but the target service does not answer properly (i.e. by returning "DBUS_HANDLER_RESULT_HANDLED" despite not sending a reply), the asynchronous call does NEVER return, not even when the timeout expires. Reason is that during the iteration those timeouts are never checked again.
We tested this for dbus 1.4.16 and for 1.6.11, both builds showed the same behavior.
The patch appended to this bug report is a possible fix for this bug, though it is not the optimal solution. Optimal in our opinion would be the extension of the DBusPendingCall by a member variable that remembers the time the call was issued, and to check the current time against this value plus the timeout interval, instead of relying on the timeout appended to a DBusPendingCall firing only once and using the "interval" member variable of this timeout object for the very same purpose.
The following code reliably reproduces the error (the test uses the google test framework, https://code.google.com/p/googletest/):
#include <gtest/gtest.h>
#include <dbus/dbus.h>
class LibdbusTest: public ::testing::Test {
protected:
virtual void SetUp() {
}
virtual void TearDown() {
}
};
::DBusHandlerResult onLibdbusObjectPathMessageThunk(::DBusConnection* libdbusConnection,
::DBusMessage* libdbusMessage,
void* userData) {
return ::DBusHandlerResult::DBUS_HANDLER_RESULT_HANDLED;
}
DBusObjectPathVTable libdbusObjectPathVTable = {
NULL,
&onLibdbusObjectPathMessageThunk
};
::DBusConnection* createConnection() {
const ::DBusBusType libdbusType = ::DBusBusType::DBUS_BUS_SESSION;
::DBusConnection* libdbusConnection = dbus_bus_get_private(libdbusType, NULL);
dbus_connection_ref(libdbusConnection);
dbus_connection_set_exit_on_disconnect(libdbusConnection, false);
return libdbusConnection;
}
static void onLibdbusPendingCallNotifyThunk(::DBusPendingCall* libdbusPendingCall, void *userData) {
replyArrived = true;
::DBusMessage* libdbusMessage = dbus_pending_call_steal_reply(libdbusPendingCall);
ASSERT_TRUE(libdbusMessage);
dbus_pending_call_unref(libdbusPendingCall);
}
TEST_F(LibdbusTest, NonreplyingLibdbusConnectionsAreHandled) {
const char* problemServiceName = "problem.service";
replyArrived = false;
bool running = true;
dbus_threads_init_default();
::DBusConnection* serviceConnection = createConnection();
::DBusConnection* clientConnection = createConnection();
dbus_bus_request_name(serviceConnection,
problemServiceName,
DBUS_NAME_FLAG_DO_NOT_QUEUE,
NULL);
dbus_connection_try_register_object_path(serviceConnection,
"/",
&libdbusObjectPathVTable,
NULL,
NULL);
std::thread([&, this] {
while(running) {
dbus_connection_read_write_dispatch(serviceConnection, 10);
}
}).detach();
usleep(100000);
::DBusMessage* message = dbus_message_new_method_call(problemServiceName, "/", NULL, "someMethod");
::DBusPendingCall* libdbusPendingCall;
dbus_connection_send_with_reply(
clientConnection,
message,
&libdbusPendingCall,
3000);
dbus_pending_call_set_notify(
libdbusPendingCall,
onLibdbusPendingCallNotifyThunk,
NULL,
NULL);
//100*50 = 5000 (ms) ==> 3 seconds timeout pending call *should* have arrived by now.
for (unsigned int i = 0; i < 100 && (!replyArrived); i++) {
dbus_connection_read_write_dispatch(clientConnection, 50);
}
EXPECT_TRUE(replyArrived);
running = false;
usleep(100000);
dbus_connection_close(serviceConnection);
dbus_connection_unref(serviceConnection);
dbus_connection_close(clientConnection);
dbus_connection_unref(clientConnection);
}
**Patch 79978**, "Possible fix for dbus-1.6.11":
[dbus-v1.6.11-DBusConnection-fix-asynchronous-call-timeouts.patch](/uploads/1c64bba1e1c08dd1de61f05eede11a69/dbus-v1.6.11-DBusConnection-fix-asynchronous-call-timeouts.patch)
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/82Terminate autolaunched X11 session bus when no longer needed2022-05-02T10:16:37ZBugzilla Migration UserTerminate autolaunched X11 session bus when no longer needed## Submitted by swo..@..ol.com
Assigned to **D-Bus Maintainers**
**[Link to original bug (#64734)](https://bugs.freedesktop.org/show_bug.cgi?id=64734)**
## Description
Just a little notice before: I'm using dbus 1.6.10 but the bug...## Submitted by swo..@..ol.com
Assigned to **D-Bus Maintainers**
**[Link to original bug (#64734)](https://bugs.freedesktop.org/show_bug.cgi?id=64734)**
## Description
Just a little notice before: I'm using dbus 1.6.10 but the bugtracker doesn't provide a selection for version 1.6. Now to the issue:
I'm using Ubuntu and I'm noticing that due to dbus some dbus-related-processes are spawned if I'm opening a major process (for example a text editor with root permissions). There are 2 types:
1. dbus itself: On opening the application with root permissions dbus starts 2 major processes for root which hasn't existed before for him: dbus-launch and dbus-daemon.
2. External applications that are defined in service files: I'm very often seeing that a major process is triggering the spawning of processes defined in these service files.
Now to the problem and my feature request: If I'm closing all major processes the user-dependend dbus-processes from #1 and the external processes from #2 will still remain. Over time this will bloat up my system with processes that could be safely closed. dbus should track this and if all related major processes are closed dbus should remove the processes from #1 and #2. To prevent in this case a lot of forking there could be maybe an idle timeout (which would be ideally configurable).
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/81cmake xmldoc target dependency fixes2018-10-12T21:15:47ZBugzilla Migration Usercmake xmldoc target dependency fixes## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#64058)](https://bugs.freedesktop.org/show_bug.cgi?id=64058)**
## Description
Created attachment 78610
Fix of cmake xmldoc depen...## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#64058)](https://bugs.freedesktop.org/show_bug.cgi?id=64058)**
## Description
Created attachment 78610
Fix of cmake xmldoc dependencies chain.
dbus xml docs are build unconditional on every make run. This patch adds real build dependency checking for building xml docs.
~~**Patch 78610**~~, "Fix of cmake xmldoc dependencies chain.":
[0001-Fix-of-cmake-xmldoc-dependencies-chain.patch](/uploads/411d44d448fdae781e9de3bee45d2cf9/0001-Fix-of-cmake-xmldoc-dependencies-chain.patch)
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/80activation: better support for services with multiple names2018-10-12T21:15:43ZBugzilla Migration Useractivation: better support for services with multiple names## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#62861)](https://bugs.freedesktop.org/show_bug.cgi?id=62861)**
## Description
+++ This bug was initially created as a clone of Bug #35750 ++...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#62861)](https://bugs.freedesktop.org/show_bug.cgi?id=62861)**
## Description
+++ This bug was initially created as a clone of Bug #35750 +++
On Bug #35750, Will wrote:
> > I think that would be nice (in the future) to index
> > activation->pending_activations on the name of the .service file, not on the
> > bus name: then one .service file could list n service names and guarantee that
> > it'll be run at most once at a time.
and I replied:
> I disagree on the specific mechanics for this: on the session bus,
> best-practice (iirc) is for the .service file to be named after the bus
> name, and on the system bus, it's mandatory for the name to be the same. I
> believe the reason is something to do with the setuid helper.
>
> One way to get the same effect would be to introduce a way for the "aliases"
> to omit the Exec= and say "InsteadActivate=com.example.RealName". Another
> would be to introduce a way for ...RealName.service file to say
> "AlsoActivateFor=com.example.Alias;com.example.Pseudonym;" or something. In
> either case, we'd want to only invoke the setuid system-bus helper for
> ...RealName, and track pending activations in terms of ...RealName.
>
> I believe we used to do something similar for Mission Control (the reference
> implementation of the Telepathy AccountManager and ChannelDispatcher
> services) on Maemo, where ...AccountManager.service and
> ...ChannelDispatcher.service used dbus-send to send Ping to
> ...MissionControl5, and ...MissionControl5.service did the actual launching?
This has been brought up again in a recent mailing list thread, where I said basically the same thing.
Version: 1.5
### Depends on
* [Bug 35750](https://bugs.freedesktop.org/show_bug.cgi?id=35750)https://gitlab.freedesktop.org/dbus/dbus/-/issues/79dbus-daemon: optionally capture all packets in pcap format2018-10-12T21:15:26ZBugzilla Migration Userdbus-daemon: optionally capture all packets in pcap format## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#60859)](https://bugs.freedesktop.org/show_bug.cgi?id=60859)**
## Description
When profiling a boot or login process, it's useful to capture th...## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#60859)](https://bugs.freedesktop.org/show_bug.cgi?id=60859)**
## Description
When profiling a boot or login process, it's useful to capture the entire message stream. Connecting dbus-monitor or bustle-pcap after the dbus-daemon starts is not enough: this would race with any other services that are connecting to the socket at the same time, whose messages might be dispatched before the dbus-monitor or bustle-pcap is ready to eavesdrop on them.
One possible solution is for development builds of dbus-daemon to support a way to write out the message stream. I think this should be in pcap format, because that's what Bustle already uses, it would be trivial to adapt dbus-monitor to read pcap format, and it supports packet truncation if we ever need it.
I know Colin ideally wants to have a "management socket" which speaks the full D-Bus protocol and can eavesdrop, receive control messages and other nice things, but that's pretty complicated. This implementation is much simpler: an optional <pcap_recipient/> in the configuration file contains a shell command, usually of the form "cat > $LOCATION". It receives pcap on its stdin, and... er... that's it.
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/78Platform related overhaul of dbus documentation2018-10-12T21:15:23ZBugzilla Migration UserPlatform related overhaul of dbus documentation## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#59808)](https://bugs.freedesktop.org/show_bug.cgi?id=59808)**
## Description
Here required changes of the platform related doc ...## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#59808)](https://bugs.freedesktop.org/show_bug.cgi?id=59808)**
## Description
Here required changes of the platform related doc changes may be collected.
from [bug 42441](https://bugs.freedesktop.org/show_bug.cgi?id=42441):
How about this for some installation-neutral wording which could go in the man page, avoiding having to do the dbus-daemon.1.in -> dbus-daemon.1 dance?
"""
The --session option is equivalent to using --config-file to select the standard configuration file session.conf provided with D-Bus. Similarly, the --system option is equivalent to using --config-file to select system.conf. These files are typically found in /etc/dbus-1 on Unix systems, or in the etc/dbus-1 subdirectory of the installation root on Windows systems.
"""
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/77on service crash, dbus daemon sends timeout messages in wrong order2018-10-12T21:15:20ZBugzilla Migration Useron service crash, dbus daemon sends timeout messages in wrong order## Submitted by Allison Lortie `@desrt`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#59780)](https://bugs.freedesktop.org/show_bug.cgi?id=59780)**
## Description
If you write a service in a serial way (ie: non-threa...## Submitted by Allison Lortie `@desrt`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#59780)](https://bugs.freedesktop.org/show_bug.cgi?id=59780)**
## Description
If you write a service in a serial way (ie: non-threaded) then by the usual well-ordering guarantees of D-Bus, all users of that service can assume that they will receive replies to their method calls in the same order that they sent the method calls.
One exception to this case is when the service crashes. In that case, D-Bus sends error messages back to the client _in reverse order_.
See https://bugzilla.gnome.org/show_bug.cgi?id=687120 for a report of an assertion failure caused by the above assumption being violated by this behaviour.
Probably it would be relatively easy to fix this.
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/76Allow escaped commas in argument arrays for dbus-send2018-10-12T21:15:18ZBugzilla Migration UserAllow escaped commas in argument arrays for dbus-send## Submitted by Glenn Hartmann
Assigned to **D-Bus Maintainers**
**[Link to original bug (#59139)](https://bugs.freedesktop.org/show_bug.cgi?id=59139)**
## Description
Created attachment 72684
Proposed patch to allow escaped comma...## Submitted by Glenn Hartmann
Assigned to **D-Bus Maintainers**
**[Link to original bug (#59139)](https://bugs.freedesktop.org/show_bug.cgi?id=59139)**
## Description
Created attachment 72684
Proposed patch to allow escaped commas
Currently every comma in any argument is automatically treated as a delimiter, no matter what. This can be problematic if an argument string actually should have a comma in it.
This patch allows one to escape a comma with a backslash to get around this problem.
I'd like to write a test for this code, but doing so may require some restructuring of dbus-send.c. I'm new here, so are there any suggestions for how (and where) to add tests for this properly?
**Attachment 72684**, "Proposed patch to allow escaped commas":
[0001-dbus-send.c-allow-escaped-commas-in-argument-strings.patch](/uploads/5da05659baa285dd5785ee3b619f35ee/0001-dbus-send.c-allow-escaped-commas-in-argument-strings.patch)
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/75Formal spec for launchd2018-10-12T21:15:14ZBugzilla Migration UserFormal spec for launchd## Submitted by Daniel Macks
Assigned to **D-Bus Maintainers**
**[Link to original bug (#58601)](https://bugs.freedesktop.org/show_bug.cgi?id=58601)**
## Description
Bug #14259 was closed when launchd support got committed (yay th...## Submitted by Daniel Macks
Assigned to **D-Bus Maintainers**
**[Link to original bug (#58601)](https://bugs.freedesktop.org/show_bug.cgi?id=58601)**
## Description
Bug #14259 was closed when launchd support got committed (yay thank you!!!). However, the underlying methodology it uses was never added to the formal dbus spec. So I'm raising Comment 87 from there here as a specific request: please document it.
In particular, there's a glib feature-request waiting for it, whose
https://bugzilla.gnome.org/show_bug.cgi?id=690523 notes:
>We need to get it into the spec in the "Well-known
>Message Bus Instances" chapter, this one
>
> http://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-types
>
>E.g. the same way there's an "X Windowing System" chapter explaining what atoms
>to look at (the stuff involving _DBUS_SESSION_BUS_SELECTION_), there needs to
>be a "Max OS X" chapter explaining exactly how to get the address.https://gitlab.freedesktop.org/dbus/dbus/-/issues/74improve documentation on running clients with Valgrind2018-10-12T21:15:09ZBugzilla Migration Userimprove documentation on running clients with Valgrind## Submitted by Arun Raghavan `@arun`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#55933)](https://bugs.freedesktop.org/show_bug.cgi?id=55933)**
## Description
I've also added this information to the wiki at:
www.f...## Submitted by Arun Raghavan `@arun`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#55933)](https://bugs.freedesktop.org/show_bug.cgi?id=55933)**
## Description
I've also added this information to the wiki at:
www.freedesktop.org/wiki/Software/dbus/RunningClientsWithValgrind
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/73Please make libdbus thread-safe by default2018-10-12T21:14:27ZBugzilla Migration UserPlease make libdbus thread-safe by default## Submitted by Chow Loong Jin
Assigned to **Simon McVittie**
**[Link to original bug (#54972)](https://bugs.freedesktop.org/show_bug.cgi?id=54972)**
## Description
When an application uses libraries which use libdbus in a threade...## Submitted by Chow Loong Jin
Assigned to **Simon McVittie**
**[Link to original bug (#54972)](https://bugs.freedesktop.org/show_bug.cgi?id=54972)**
## Description
When an application uses libraries which use libdbus in a threaded manner, an explicit dependency on libdbus is required in order to call dbus_g_threads_init(), or things start crashing in libdbus, as seen in https://bugzilla.gnome.org/show_bug.cgi?id=683830, https://bugzilla.gnome.org/show_bug.cgi?id=659756, and https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/1048341.
This is rather suboptimal, as in the case of gconf, the libdbus usage is a transport that should be abstracted within the implementation details of libgconf.
There should be little, if any backward compatibility breakages involved with this changed, as explained in https://bugzilla.gnome.org/show_bug.cgi?id=683830#c10.
Version: 1.5
### Blocking
* [Bug 54770](https://bugs.freedesktop.org/show_bug.cgi?id=54770)https://gitlab.freedesktop.org/dbus/dbus/-/issues/72dbus-daemon drops messages if sender exits during service activation2021-02-16T14:02:37ZBugzilla Migration Userdbus-daemon drops messages if sender exits during service activation## Submitted by Kerrick Staley
Assigned to **D-Bus Maintainers**
**[Link to original bug (#52372)](https://bugs.freedesktop.org/show_bug.cgi?id=52372)**
## Description
If you pass the --print-reply flag to dbus-send, it results in...## Submitted by Kerrick Staley
Assigned to **D-Bus Maintainers**
**[Link to original bug (#52372)](https://bugs.freedesktop.org/show_bug.cgi?id=52372)**
## Description
If you pass the --print-reply flag to dbus-send, it results in a "method call". Without the flag, it sends a "signal". The dbus-send manpage says
--print-reply
Block for a reply to the message sent, and print any reply received in a human-readable form.
so it seems that --print-reply should only change the output of dbus-send (similar to a --verbose flag).
I encountered this bug because the command
dbus-send --dest=org.gnome.Shell /org/gnome/Shell org.freedesktop.DBus.Properties.Set string:org.gnome.Shell string:OverviewActive variant:boolean:true
has no effect unless you pass the --print-reply flag.
This bug is in dbus 1.6.4, but the "Version" field of the bug report doesn't contain that option (it only goes up to 1.5).
Version: 1.5
### Depends on
* [Bug 896](https://bugs.freedesktop.org/show_bug.cgi?id=896)https://gitlab.freedesktop.org/dbus/dbus/-/issues/71document that setuid executables must clear their environment before using li...2018-10-12T21:14:06ZBugzilla Migration Userdocument that setuid executables must clear their environment before using libdbus## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#52202)](https://bugs.freedesktop.org/show_bug.cgi?id=52202)**
## Description
(This issue was raised and made public on oss-sec, but for som...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#52202)](https://bugs.freedesktop.org/show_bug.cgi?id=52202)**
## Description
(This issue was raised and made public on oss-sec, but for some reason not upstream. By coincidence, I was subscribed to oss-sec as a result of helping to deal with ioquake3 security.)
libdbus obeys various environment variables retrieved using getenv(). This is a potential vulnerability if a set*id application links libdbus, uses libdbus in a way that obeys environment variables, and trusts that the values of those environment variables, or the D-Bus addresses to which they point, are trustworthy.
The example cited in the Novell bug is Xorg, which is apparently setuid on SUSE, linking libhal (under at least some configurations), which uses the system bus. If Xorg makes policy decisions using PolicyKit or by calling GetConnectionUnixUser or equivalent on dbus-daemon, then a malicious user could run Xorg with DBUS_SYSTEM_BUS_ADDRESS in its environment, connecting it to a bus that answers GetConnectionUnixUser dishonestly or contains a dishonest PolicyKit implementation, which induces it to make wrong policy decisions.
When I say "set*id" I mean setuid, setgid, or any analogous executable-based privileges that allow a caller to provide the initial environment while escalating privileges (e.g. Linux VFS capabilities).
Mitigations include:
* Most system services don't use the system bus.
* System services started by service activation (like PolicyKit itself)
never need to be setuid, because dbus-daemon-launch-helper starts them
with appropriate privileges anyway.
* System services started by init (sysvinit, systemd, Upstart or
equivalent) never need to be setuid, because their init scripts
(or equivalent) are fully-privileged anyway.
References:
https://bugzilla.novell.com/show_bug.cgi?id=697105
http://seclists.org/oss-sec/2012/q3/29
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/70Need to provide standardized way to disable services started by dbus2022-05-13T01:35:52ZBugzilla Migration UserNeed to provide standardized way to disable services started by dbus## Submitted by bas..@..oo.com
Assigned to **D-Bus Maintainers**
**[Link to original bug (#50955)](https://bugs.freedesktop.org/show_bug.cgi?id=50955)**
## Description
Currently there does not appear to be any official, documented...## Submitted by bas..@..oo.com
Assigned to **D-Bus Maintainers**
**[Link to original bug (#50955)](https://bugs.freedesktop.org/show_bug.cgi?id=50955)**
## Description
Currently there does not appear to be any official, documented way to control which services dbus starts at launch. The only methods to disable a service right now are fairly hackish and don't survive a package upgrade/reinstall. These methods are to rename, or remove the .service file (normally located at /usr/share/dbus-1/services). Also, when removing the file, any future frontend for controlling dbus services won't be able to suggest the service for re-enabling, as the .service file is no longer there.
I suggest adding an extra key to the service file 'Enabled=' with possible values 'Yes' or 'No'. The key should be optional and default to Yes if not found, so existing .service files will still work. Obviously dbus needs to be changed to parse this key, and respect its value.
I also suggest an optional key 'Description=' so service providers can describe what the service does. This description could then be read by a possible frontend and shown to users considering disabling a service.
Thanks,
Bas Timmer
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/69configuration: add <listen_if_possible> option2018-10-12T21:13:59ZBugzilla Migration Userconfiguration: add <listen_if_possible> option## Submitted by Alban Crequy
Assigned to **D-Bus Maintainers**
**[Link to original bug (#50418)](https://bugs.freedesktop.org/show_bug.cgi?id=50418)**
## Description
Introduce a `<listen_if_possible>` so the dbus-daemon won't just...## Submitted by Alban Crequy
Assigned to **D-Bus Maintainers**
**[Link to original bug (#50418)](https://bugs.freedesktop.org/show_bug.cgi?id=50418)**
## Description
Introduce a `<listen_if_possible>` so the dbus-daemon won't just crash out if run on a kernel without support for the socket type we would like.
I will add an implementation soon.
Example of D-Bus configuration file:
`<listen>`tcp:port=1234`</listen>`
`<listen_if_possible>`tcp:port=1235`</listen_if_possible>`
`<listen_if_possible>`pigeon:port=carrier,speed=110mph`</listen_if_possible>`
If the daemon cannot bind on port 1234, it will fail. But if it cannot bind on port 1235, or if it does not understand the last address, it will just ignore the error.
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/68usb + memory leak2018-10-12T21:13:56ZBugzilla Migration Userusb + memory leak## Submitted by MonoBOY
Assigned to **Havoc Pennington**
**[Link to original bug (#50042)](https://bugs.freedesktop.org/show_bug.cgi?id=50042)**
## Description
I have Gentoo amd 64, using gnome 2.32, dbus 1.5.12. When starting to ...## Submitted by MonoBOY
Assigned to **Havoc Pennington**
**[Link to original bug (#50042)](https://bugs.freedesktop.org/show_bug.cgi?id=50042)**
## Description
I have Gentoo amd 64, using gnome 2.32, dbus 1.5.12. When starting to write / delete on a flash drive or external hard drive dbus-daemon begins memory leak. As soon as the write / delete, memory leak stops.
Kernel 2.6.38
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/67connection lost: pending method calls not notified2018-10-12T21:13:52ZBugzilla Migration Userconnection lost: pending method calls not notified## Submitted by Patrick Ohly `@pohly`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#49728)](https://bugs.freedesktop.org/show_bug.cgi?id=49728)**
## Description
SyncEvolution started to use D-Bus as IPC mechanism bet...## Submitted by Patrick Ohly `@pohly`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#49728)](https://bugs.freedesktop.org/show_bug.cgi?id=49728)**
## Description
SyncEvolution started to use D-Bus as IPC mechanism between processes, using a direct D-Bus connection. One of my tests fails when using libdbus: when the peer goes down and the connection is closed, the surviving processes doesn't get an error callback for its pending method calls on that connection.
This only matters when "exit on connection loss" is disabled. SyncEvolution disables that because it needs to clean up resp. continue syncing when possible without the peer.
It works when using GIO D-Bus, which is the long-term solution for SyncEvolution - except on systems which only have libdbus.
I tracked it down to the following sequence of events (1.4 branch):
- connection loss is noticed
- connection_timeout_and_complete_all_pending_calls_unlocked() queues
pre-generated error messages ("timeout_link") and removes the pending
method call.
- dbus_connection_dispatch() is called and processes the queued
error messages. Because there is no pending method call matching
the reply anymore (it was removed in the previous step), the message
is dropped as "not handled".
I'm not sure what the right solution is. Keep canceled method calls? Perhaps in a separate list?
Can anyone think of a workaround? I'd like to get SyncEvolution working on legacy Linux distros which won't get libdbus updates.
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/66Possible race condition in dbus_watch_handle and dbus_message_unref2018-10-12T21:13:49ZBugzilla Migration UserPossible race condition in dbus_watch_handle and dbus_message_unref## Submitted by mep..@..il.com
Assigned to **Havoc Pennington**
**[Link to original bug (#48100)](https://bugs.freedesktop.org/show_bug.cgi?id=48100)**
## Description
Hello,
My code receives incoming messages in one thread and se...## Submitted by mep..@..il.com
Assigned to **Havoc Pennington**
**[Link to original bug (#48100)](https://bugs.freedesktop.org/show_bug.cgi?id=48100)**
## Description
Hello,
My code receives incoming messages in one thread and sends outgoing messages from other threads. It works fine, but Helgrind issues the following warning from time to time:
==5039== Possible data race during read of size 4 at 0x45CA46C by thread #4
==5039== Locks held: 1, at address 0x45CA760
==5039== at 0x408BCB4: _dbus_counter_get_value (dbus-resources.c:170)
==5039== by 0x4094532: check_read_watch (dbus-transport-socket.c:195)
==5039== by 0x40949F6: do_reading.part.2 (dbus-transport-socket.c:687)
==5039== by 0x409535E: socket_handle_watch (dbus-transport-socket.c:677)
==5039== by 0x4093908: _dbus_transport_handle_watch (dbus-transport.c:865)
==5039== by 0x4073F0E: _dbus_connection_handle_watch (dbus-connection.c:1447)
==5039== by 0x40968BE: dbus_watch_handle (dbus-watch.c:669)
==5039== by 0x404D7F6: DBus::Watch::handle(int) (in ~/gcc-4.4.5-dbus-c++-0.5.0-0.12.20090203git13281b3.fc15/lib/libdbus-c++-1.so.0.0.0)
==5039== by 0x4055914: DBus::Glib::BusWatch::watch_handler(void*) (in ~/gcc-4.4.5-dbus-c++-0.5.0-0.12.20090203git13281b3.fc15/lib/libdbus-c++-1.so.0.0.0)
==5039== by 0x40551CB: watch_dispatch(_GSource*, int (*)(void*), void*) (in ~/gcc-4.4.5-dbus-c++-0.5.0-0.12.20090203git13281b3.fc15/lib/libdbus-c++-1.so.0.0.0)
==5039== by 0x41465E4: g_main_context_dispatch (gmain.c:1960)
==5039== by 0x414A2D7: g_main_context_iterate (gmain.c:2591)
==5039==
==5039== This conflicts with a previous write of size 4 by thread #3
==5039== Locks held: none
==5039== at 0x408BC6D: _dbus_counter_adjust (dbus-resources.c:146)
==5039== by 0x4081BCE: free_size_counter (dbus-message.c:504)
==5039== by 0x4099D10: _dbus_list_foreach (dbus-list.c:800)
==5039== by 0x408218D: dbus_message_unref (dbus-message.c:527)
==5039== by 0x40507AC: DBus::Message::~Message() (in ~/gcc-4.4.5-dbus-c++-0.5.0-0.12.20090203git13281b3.fc15/lib/libdbus-c++-1.so.0.0.0)
==5039== by 0x42B19E4: rmc::ResolverC::resolve(int, rmc::ClientManager&, std::string const&) (ResolverC.cpp:41)
==5039== by 0x42B1AFD: rmc::ResolverC::resolve(std::string const&) (ResolverC.cpp:49)
==5039== by 0x42A9D3C: rmc::ClientManager::get(std::string const&) (ClientManager.cpp:41)
==5039==
==5039== Address 0x45CA46C is 4 bytes inside a block of size 20 alloc'd
==5039== at 0x4026CAC: malloc (vg_replace_malloc.c:263)
==5039== by 0x409BA10: dbus_malloc (dbus-memory.c:471)
==5039== by 0x408BB3A: _dbus_counter_new (dbus-resources.c:81)
==5039== by 0x40927C5: _dbus_transport_init_base (dbus-transport.c:118)
==5039== by 0x4095595: _dbus_transport_new_for_socket (dbus-transport-socket.c:1203)
==5039== by 0x409577D: _dbus_transport_new_for_tcp_socket (dbus-transport-socket.c:1290)
I have taken a look at the D-Bus code and found out that DBusMessages are linked to transport->live_messages counters, that are not thread-safe. When DBusMessage is destroyed, the counter is updated by _dbus_counter_adjust(). When this coincides with watch bookkeeping, _dbus_counter_get_value() may randomly return either old or new value - I'm not sure whether this may lead to failures.
However, I could imagine that if two different threads send two different messages through the same connection at the same time, counter value might become wrong.
Version: 1.5