Re: Process started via udev rule not emitting signals on session bus of UID=1000

On 19/01/16 06:04, Pratyush Sahay wrote:
> When running the service via the udev event, the service returns an
> error on getConnection to SESSION BUS itself, and hence, no signal is
> emitted by the service.

The service started by udev is not in any particular user's session, so
it is inappropriate for it to be communicating on any particular user's
session bus.

> 1) Is there a better way of achieving the flow, without resorting to
> enforced uid?

Please use the system bus, like systemd, NetworkManager, BlueZ and
similar services do. This is what it's for.

You will need to install XML configuration to tell the system bus to
allow your service to connect to the system bus and own its bus name,
and change the client to connect to the system bus instead of the
session bus (or connect to both, if it has some other reason for using
the session bus). Again, this is the same thing that services like
NetworkManager do.

> 2) I thought exporting the terminal's DBUS_SESSION_BUS_ADDRESS in the
> udev rule would be enough to get the service to emit on UID=1000's
> session bus. But that didnt work.

No, because the service is not running as uid 1000, and only uid 1000
may connect to one of uid 1000's session buses.

> 3) doing a : `dbus-launch --sh-syntax` before starting the service in
> the udev rule lets the service get connection to Session Bus. However, I
> think a new session bus is getting created in this case

Yes, dbus-launch always launches a *new* session bus unless the
--autolaunch option is used.

I would recommend avoiding dbus-launch altogether, unless you are
writing the D-Bus <-> X11 integration layer for an OS distribution. It
is frequently misused as a way to start regression tests in an isolated
D-Bus session, but since dbus 1.8, dbus-run-session(1) is a better way
to achieve that.

On Linux distributions with systemd, the user bus (./configure
--enable-user-session) is intended to be a better way to start the
normal, "production" D-Bus sessions that have also traditionally relied
on dbus-launch.

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>

_______________________________________________
dbus mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dbus