1. 01 Feb, 2016 4 commits
  2. 10 Nov, 2015 2 commits
  3. 09 Nov, 2015 1 commit
  4. 06 Nov, 2015 1 commit
  5. 26 Oct, 2015 1 commit
    • Simon McVittie's avatar
      Accept XDG_RUNTIME_DIR/bus as a valid D-Bus session/user bus · ac80e77f
      Simon McVittie authored
      These checks for DBUS_SESSION_BUS_ADDRESS were added to solve
      https://bugzilla.gnome.org/show_bug.cgi?id=526454,
      in which non-X11-session processes (for example a system service),
      or processes under su or similar inside an X11 session, could cause
      a dbus-daemon to be autolaunched via dbus-launch. If there was no
      X11 display to represent the lifetime of a session, the dbus-daemon
      would potentially run forever, causing a "leaked" process;
      additionally, other uses of D-Bus by the same uid would start more
      dbus-daemons.
      
      This becomes potentially problematic on systems with the "user bus"
      model introduced in dbus 1.10: libdbus, GDBus and sd-bus will now
      all try the per-uid socket XDG_RUNTIME_DIR/bus before attempting
      autolaunch, so if those are known to be the only implementations in
      use on a "legacy-free" system, setting DBUS_SESSION_BUS_ADDRESS is
      unnecessary. Check for that socket before giving up.
      
      XDG_RUNTIME_DIR/bus as implemented by dbus 1.10 with systemd avoids
      several of the down sides of autolaunching: it will never start more
      than one session bus per uid, and the socket and bus will automatically
      be cleaned up when the corresponding "systemd --user" exits.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=756420
      ac80e77f
  6. 23 Oct, 2015 1 commit
  7. 16 Oct, 2015 2 commits
  8. 15 Oct, 2015 4 commits
  9. 14 Oct, 2015 2 commits
  10. 13 Oct, 2015 3 commits
  11. 12 Oct, 2015 3 commits
  12. 09 Oct, 2015 2 commits
  13. 08 Oct, 2015 1 commit
  14. 06 Oct, 2015 1 commit
  15. 02 Oct, 2015 2 commits
  16. 30 Sep, 2015 4 commits
    • Debarshi Ray's avatar
      proxy volume monitor: Guard access to the internal caches · b75a1896
      Debarshi Ray authored
      Accesses to the drives, volumes and mounts hash tables should be
      guarded by the proxy_vm mutex.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=755805
      b75a1896
    • Simon McVittie's avatar
      Add a corresponding systemd user service for every D-Bus session service · dc7040d7
      Simon McVittie authored
      When using "systemd --user" in conjunction with "dbus-daemon --session
      --systemd-activation", this ensures that each daemon is correctly placed
      in its own cgroup, instead of being treated as part of dbus.service.
      
      Bug: https://bugzilla.gnome.org/show_bug.cgi?id=755760
      dc7040d7
    • Simon McVittie's avatar
      Use conventional naming for D-Bus session services · 957fff5b
      Simon McVittie authored
      This naming is mandatory for the system bus, but is also recommended
      for the session bus.
      
      The D-Bus maintainers recommend that all activatable session services'
      service files are named according to the bus name, so that any conflict
      is resolved in a deterministic way. If the services are in different
      directories (precedence levels) the result is the same as it is now:
      the higher precedence "wins". If the services are in the same
      directory, either one overwrites the other and consistently "wins",
      or a packaging system like dpkg prevents co-installation.
      
      If the service files were named differently, it would be possible
      to have two implementations for the same name. dbus-daemon resolves
      this by choosing one arbitrarily, not necessarily the same one every
      time. systemd's kdbus support is more strict (or less concerned with
      backwards compatibility), and treats this situation as an error.
      
      Bug: https://bugzilla.gnome.org/show_bug.cgi?id=755760
      957fff5b
    • Alexander Larsson's avatar
      file monitor: Construct synchronously · 7373acf9
      Alexander Larsson authored
      g_file_monitor_file() is a sync call anyway, so doing some sync i/o
      in the constructor doesn't make a difference, and doing so avoids
      races where you would not get change events for operations you do.
      
      We don't actually need to wait for the subscribe event, and proxy
      construction in this case does not do any i/o, so we're really only
      doing sync i/o to look up the connection, and it should be cached from
      the earlier call in g_daemon_file_monitor_file(), so in practice
      this should make little difference.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=749317
      7373acf9
  17. 29 Sep, 2015 1 commit
  18. 27 Sep, 2015 2 commits
  19. 23 Sep, 2015 3 commits